July, 2006

OSCON 2006 Day One

July 25th, 2006

The first two days of OSCON are dedicated to long tutorial sessions lasting at half a day each. Even though it’s total information overload, there’s definitely a less wacky atmosphere than later in the week, and less topics covered per-hour.

I checked out Javascript Bootcamp. Amy Hoy gave a super comprehensive overview of Javascript. It wasn’t so much a tutorial on how to construct Javascript, but more of a deconstruction that catogorized almost any Javascript part you could think of. Her slides will be on her blog at some point. There was a part of me that would have dug it if she “tied it all together” in a different way, but she was extremely familiar with Javascript, and great at relating it to other languages. So it was cool get such specific definitions of everything.

Also: props to Amy for great design on her slides. Everything… from the font size, to the colors, made them the easiest to read slides I’ve seen so far at this conference.

The other tutorial from Day One I checked out was Damian Conway’s Mastering Vim. Damian is a very engaging speaker, so any talk by him is going to be fun. But he gave a great “tricks” style talk about vim which really spoke to how people use editors, instead of just an item-by-item list. For now slides don’t seem to be digitally available :(

TECHNORATI TAGS: oscon,
oscon2006, javascript, conference, Amy Hoy, Damian Conway

These Links Matter to You. Wednesday, July 19, 2006

July 19th, 2006

The Right Chip For The Job

July 19th, 2006

From an interview with Sun CIO Bill Vass… I’m quoting an interesting part on how he differentiates between different server architectures, and the best application for them:

Because each server is capable of running the same applications, it can be confusing how to choose one over the other. Since I really like cars, I think of the servers in terms of capacity and speed. For mass transit– such as an application, portal, Web, directory or proxy server–you might need as many as 32 threads at once. That’s what the CoolThreads server offers. It is like a bus.

When you need to share memory quickly, in a large database or an ERP [Enterprise Resource Planning] system, you’d use an UltraSparc. There aren’t as many threads, but it shares memory well from chip to chip, and it is pretty fast. I think of it like a BMW M5 sedan that can carry a whole family, with room for luggage.

Finally, the x64 Opteron–AMD’s chip–runs very fast on two- and four-threaded applications. That’s the two-seater Ferrari.

People are used to the idea of a general-purpose chip to do everything in the IT space. We’re working on an application profiler where CIOs can enter information and generate a recommendation for how much memory-sharing they need and which chip is best for any given application.

Portland Nerd Summer

July 17th, 2006

Ubuntu’s Classroom

July 15th, 2006

Starting in August, there’ll be regular biweekly, real-time IRC-based Ubuntu classes. Topics will range from newbie (email clients), to advanced (kernel stuff, encryption). To see the full schedule, visit the Ubuntu wiki page:

These Links Matter to You. Friday, July 14, 2006

July 14th, 2006

These Links Matter to You. Thursday, July 12, 2006

July 13th, 2006

The Ubuntu Title Font: Free For All Operating Systems

July 12th, 2006

More like the quick brown awesome.

via Ubuntu Blog

...$sudo apt-get install ttf-ubuntu-title
will install the font and make it available to GIMP, OpenOffice and everywhere else that you can use fonts.

If you only want the font, to install it on another OS or such, you can get it here. The font is an OpenType Font, which installs just like a TrueType font. The font is licensed using the LGPL…

TECHNORATI TAGS: font, free, lgpl, sysadmin, ubuntu, linux, desgin, resource

These Links Matter to You. Wednesday, July 12, 2006

July 12th, 2006

Operational Competency. Tim O’Reilly, You Like Totes Read My Mind!

July 11th, 2006


Growing Pains, Operations, and Massages

My friends and I have parts of our digital lives spread out over various hosts and service providers. In both personal and professional use, it hasn’t gone unnoticed that many places are struggling to keep up with operational issues. Even the posterchild of scalability, Flickr, is regularly down for maintenance. (With Flickr it’s not that disruptive, because they usually give tons of notice, and have a cute message up during downtime. ) But it’s indicative of the state of things when the people who literally wrote the book on the subject, are regularly down.

I don’t mean to attack Flickr. They probably handle operational issues better than anybody else. But what’s going right now is that it’s easier to create a tool than it is to master its implementation. And tools and services are getting adopted and integrated into our lives faster than we’re learning how to use them, support them,… or live without them.

RUBY ON RAILS
I know of one web-hosting provider who is a leader in Ruby-on-Rails hosting. Though very technically sophisticated and literate, their service-level lately has been horrible for all web-related services, not just RoR. They do concede a change in performance and availability, but blame this on their users not using Ruby on Rails “correctly,” hijacking resources from everybody else! This explanation is acceptable with a one-off fluke runaway process. But when the service-level for users and servers has been suffering for months on end, it’s time to re-think what’s going on! If it’s clear that certain Ruby on Rails tacts can kill a server, then tailor adminstration for such occurences. Clear-cut = controllable. But it’s not clearcut. It’s not predictable, and in the case of this service provider, they should admit that the “right” way to use Ruby on Rails, for both developer and administrator, is still being worked out.

I’m not suggesting Ruby On Rails is a bad tool, simply that the pace of development with the tool has lapped the pace of admistration of the tool.

OPERATIONS: THE NEW SECRET SAUCE
This week, Tim O’Reilly wrote a great post about operational/ deployment challenges of web services, and how operational performance could end up being a market differentiator.

One of his primary angles was comparing open source software to commercial software, in terms of operational options/ tools/ culture. He left the post undecided on whether any differences truly existed. But I was more interested in his phrase, “operational competency,” a deceptively simple idea.

Whether software is for free, or for pay; the time, energy, and experience it takes to wire it for your needs is a crucial part of its utility to you. When we start to use and play with tools and services before we achieve operational competency, we need to understand the consquences. I guess this is typical early-adopter risks kind of stuff.

What can we do about these lopsided production: operational-competency relationships?

Related links:

TECHNORATI TAGS: scaling, performance, operations, sysadmin, oreilly, service, servers, deployment, Tim OReilly