By mkupfer on Oct 04, 2005
I discovered 150g of Chinese green tea on my desk this morning, courtesy of some anonymous benefactor. It's very nice tea, so thank you, whoever you are.
One of the tools that my new job requires me to use is written
in Python. I didn't know
much about Python previously,
so I've been making my way through the
Python tutorial. It
seems like an interesting enough language. Maybe I'll end up
liking it better than my current choices
Perl, depending on the
task at hand).
Still, I do sometimes wonder whether
the world really needs yet another scripting language.
When I first started at Sun, Sun's standard windowing environment was OpenWindows. Sun eventually EOL'd OpenWindows and moved to CDE/Motif. This meant someone had to rewrite the deskset tools (calendar, mail, etc.) to use the new toolkit. A similar migration is needed as Sun moves from CDE to GNOME. I wonder if users see this as real improvement or needless churning. The CDE mail program generated MIME attachments, whereas the OpenWindows mail program used a Sun-specific format for attachments. That's a clear improvement. But the calendar manager improvements were pretty minor.
GNOME provides real improvement over CDE by providing broad support for people with physical disabilities (e.g., impaired vision). It's also just a lot more pleasant to use. I was delighted when I discovered how easy it was to drop in my own background image, or to change the contents of a panel. Doing either of these tasks in CDE required editing one or more magic files in some non-obvious way. (There were some changes you could make to the panel by direct manipulation. But getting rid of the ugly clock that Sun shipped in its later releases of CDE did not appear to be one of them.)
When I first started using GNOME, my reaction was ``this is what CDE wanted to be.'' Which of course led me to wonder why CDE didn't evolve into something as user-friendly as GNOME.
I expect attitude was part of the problem. CDE was born back when there were several Unix vendors, all squabbling amongst themselves. When they realized that Windows was going to pose a threat, they tried to band together, hence the name: Common Desktop Environment. But I never got the impression (from my seat on the sidelines) that the cooperation was all that whole-hearted. And why bother working on improvements if you think it's going to be a hassle getting them incorporated?
The GNOME project, in comparison, seems to have been motivated more by a desire to go do something cool. That seems more likely to foster continued improvements and innovations. And of course, the GNOME project has the advantage of being Open Source. Anyone with time and interest can contribute. Perhaps we (the technical community) understand how to do collaborative development better now than we did then, too.
So how does this relate to me and my work on OpenSolaris?
First, continued innovation--doing cool stuff and being able to use the cool stuff that others create--is what keeps work fun. But what makes the work feel really satisfying is knowing that I've made a meaningful difference for someone else. Otherwise, work starts to feel like an empty game.
Second, the world changes. People learn how to do things better. New standards and tools come out. Expectations change. You can't ignore the changes, and you can't rush in to adopt every new trend, either. You have to find the sweet spot in between.
So all in all, I actually like having a Python in my soup. It's one of the reasons I got involved with OpenSolaris in the first place.
I had lunch with Jim Grisanzio on Friday, and he mentioned I should start a blog. It's something I'd already been thinking about doing. In my previous job at Sun, working on NFS, it seemed like there was always something more pressing to do. But now that I'm working on OpenSolaris, community participation is an important part of my job. So here I am. :-)
At the moment I'm primarily involved with resolving copyright issues. Solaris has acquired code from a lot of sources over the years, and we need to make sure that when we make code publicly available, we aren't releasing something we're not allowed to.
Some of the initial analysis looks like it will be pretty tedious. But I'm looking forward to getting exposed to more of the code than I have in the past. A lot of bugs get filed against NFS even if the problem is elsewhere, so after 12 years of hacking NFS I've been exposed to many things besides just NFS. But there's still a lot more of the code that will be new to me.
I'm writing this at the Stanford/USC football game. I'll upload the text Sunday or Monday. I belong to the Silicon Valley Bicycle Coalition (a local bicycle advocacy group), and we provide guarded bicycle parking at the Stanford home games. Stanford just scored, but USC's still on top, 10-7. I hear USC is rated number 1 in the country, so Stanford's got its work cut out for it. We've got 99 bikes in our corral.
At the moment, I'm one of the few engineers who's dedicated to OpenSolaris. There will eventually be more folks working on this, particularly to help with the copyright analysis. But right now there's still a lot of work needed to fix bugs in Solaris 10 before it ships.
There's also some meta-engineering work that will need to be done. The Solaris organization has a set of processes that are designed to quickly detect and repair breakage, keep changes in one area of the code from breaking something else, etc. We'll need to figure out what changes to make so that non-Sun employees can participate, without losing the benefits of our current system. I'm not sure how much I'll be involved with that. It'll be done in multiple phases, I'm sure.
Halftime. Stanford's on top, 28-17. The USC fans are in shock.
The other thing I'm working on is updating the version of XEmacs (and the Lisp libraries) that ships on the Solaris Companion CD. Once that's done, I've got a couple other XEmacs things I can work on (when I'm not busy with OpenSolaris stuff). One thing is that we don't currently ship the MULE (multilingual) build of XEmacs on the Companion CD. I should fix that. The other thing is that the Solaris audio support in XEmacs uses the old OpenWindows audio demo library. We stopped shipping that library in Solaris 9. Someone has given me a patch that uses the newer audio ioctl's that replaced the old library, but the patch doesn't work on Solaris x86. It's probably just byte order issues and I just have to find the time to make it work.
It's sunset now. The clouds are gorgeous, but it's getting cold. I brought a sweatshirt, but I should have brought something heavier. If it were later in the season, I'd have brought a thermos of tea. Fortunately, Roger, who is the other person staffing this bike corral, has brought a thermos of coffee and an extra cup.
The game's over. USC won: 31-28. Most of the bicyclists don't have lights. I hope they get home safely.
Random information that I hope will be interesting to Oracle's technical community. The views expressed on this blog are my own and do not necessarily reflect the views of Oracle.