Log in

No account? Create an account

Previous Entry | Next Entry

OLS: Day One

Day One, yesterday, started with a heavily-attended talk on the 2.6 kernel development process, as well as the previous process and plans for the future. In the past, there were even-numbered releases that were stable, and there were odd-numbered releases that were developmental. The 2.6 kernel started this way. But there were problems: the development cycle was so long that new features would sit for years. The feature freezes never held. "Stable" kernels stabilized only slowly, and development would stop for long periods. To get new features in, distributors would backport them, adding to the overall complexity. Enter Andrew Morton, Linus' new sidekick. Enter BitKeeper: no more dropped patches. In fact, patches get into the mainline more quickly than ever before.

Now, Linus' 2.6.x releases are the stable series, and Andrew Morton's -mm is the stable tree. Andrew has introduced more professionalism to the kernel development process.

But there are still problems:
  • not enough testing of -rc kernels
  • too many late additions
  • little formal bug tracking
  • the mainline kernels don't always stabilize well
And one more problem: BitKeeper decided to turn commercial-only. Linus responded by rolling his own content tracker, git.
"I'm an egotistical bastard, so I name all my projects after myself. First Linux, now git." - Linus Torvalds
The second talk I attended was on the Novell Linux Kernel Debugger. Maybe the presenter had a head cold; anyway, he sounded bleary, and the slides were hard to read. I left partway through the presentation. I'm wondering how a kernel debugger differs from an ordinary debugger.

Next up: Hot Keys, Video Control, Suspend/Resume, Oh My! -- Recent Advances and Current Challenges in Linux/ACPI. The ACPI 3.0 Spec was released last year, and I suppose progress is being made, but the usual raise-your-hand-if-you've-got-suspend-working-on-your-laptop poll results weren't dramatically different from last year. One interesting bit of information we learned is that a blackened (LCD, presumably) screen consumes more power than an all-white screen. I had no idea.

After that, I attended a talk on TWIN: An Even Smaller Window System for Even Smaller Devices. Keith Packard is a great speaker, in a low-key kind of way. The motivation behind TWIN is that X takes a lot of CPU and memory, which takes a lot of power, which doesn't work on small devices. So he wrote a tiny new window system that spends more CPU time in order to save memory ("different compromises for different environments"). He found all kinds of shortcuts. Really, to me the idea of writing a window system is mind-boggling enough, but to write one that sports overlapping translucent windows, anti-aliased graphics and scalable fonts in a total memory budget of 100 kilobytes? Remarkable.

Next was Automated BoardFarm: Only Better with Bacon. The BoardFarm is a system that lets developers get remote access to embedded systems boards and to run their tests automatically. It would be nice to have something like that at work, where our testbed environments allow some remote access but where manual intervention is often needed. I'm mainly doing testing of flight software at work now, and I've spent what seems like a lot of time lately going up to our lab and suiting up in anti-electrostatic-discharge gear just to flip a switch. For the most part, I'm so new to it all that I assume there are good reasons for things to be set up the way they are.

clahey showed me a presentation he made just a few days ago at the Desktop Developers' Conference, on GOffice, and more specifically on present, the slim-and-fast Powerpoint viewer he's adapting from slow-and-bloated OpenOffice. I'm betting I can get him a Powerpoint file that it can't handle. :) It's all in the interests of improving the software, of course.

Dinner was delicious Indian food at Café Shafali with ostraya, clahey, DrSuzi, and hpa. Afterward, free alcohol and snacks at the welcome reception. I've learned that unless the reception speaker is really interesting, he is largely ignored. This reception started with an Intel marketroid (they sponsored the event), and it was hard enough to hear the proceeding speaker above the cocktail-hour din or see his packed-with-text slides that we gave up early on. We passed around clahey's newly-acquired tavern puzzle, watched DrSuzi spin yarn out of some amazingly soft linen hemp, and chatted about weird forms of neurotrauma (DrSuzi's a clinical psychologist, which seems weird because she's, like, our age).

Thus ended Day One of the Ottawa Linux Symposium.



( 3 comments — Leave a comment )
Jul. 22nd, 2005 05:01 am (UTC)
I see that Dr. Suzi's campaign to get people to call her that is working out!
Jul. 22nd, 2005 06:25 am (UTC)
ACPI is a particular interest of mine -- it's had a lot of features broken in it since the changes in 2.4.23 to 2.4.24. (I can't tell you how many boxes of mine that screwed up.) I am really hoping that things improve on that front soonish; I don't have suspend working on my laptop either, and would like to.

Sounds like you're having an awesome time out there!
Jul. 22nd, 2005 06:47 pm (UTC)
A kernel debugger is different from a regular debugger in that it can debug kernel-level code. Typically it is done remotely (usually via serial port, but other mechanisms can work, like ethernet), since it's hard to reliably debug a system when you're freezing its kernel. A kernel debugger has weird requirements, like support for attaching to a remote system on bootup via serial port, and typically is more complicated, since it has to support tying in at as low a level as possible.

For the most part it is the same as a normal debugger, though... still does breakpoints, code stepping, etc.
( 3 comments — Leave a comment )