lca2008 — why don’t big corporations love debian miniconf

I was kinda disappointed with this talk. The first speaker basically just said, “big companies! give debian money!”, and as the audience tried to understand why, he couldn’t really give good reasons. The question “what, exactly, are your goals as regard to corporations — what do you want?” was posed several times in different forms, and the answer was basically, “we want more resources”. Ok, right. On the plus side, he did plug HP several times, although he seemed to think that HP only ships debian on embedded systems. Not true — we ship ia64 debian for telcos and proliant debian too.

The second speaker was slightly better. He explained what it would take for a corporation to support debian, and basically, it came down to: “they would have to reproduce the effort that Red Hat and Novell are already doing”. Duh. Enterprise linux is simply a different ballgame than consumer linux, and after the explanation on why, I came away believing that no sane corporation would ever want to truly make debian a first class supported distro, at least not in the general case.

The reason why debian is great is exactly the reason why it will never be a good fit for corporate America. Because no one is really in charge, any investment a company might put into debian is going to have a very low ROI due to lack of control. This is not an aspersion; it’s simply the way things work.

The speaker asked for magic solutions, and YT spoke up and suggested that the problem was not going to be solved by debian developers begging corporations for support, but by lobbying ISVs to code to debian as a reference platform. My point was: no business customer buys a distro for the sake of the distro; they purchase it on the basis of the applications. A CxO does not care that his sysadmin loves debian because it’s so easy to administrate if Oracle and friends won’t run on it. The speaker did not seem to agree with me, but I had some good air cover from the rest of the peanut gallery (thanks ggg for immediately grokking my point!).

In any case, my heart will always be with debian, but I walked away from this talk thinking that the future of corporate debian isn’t so great (at least not in the near term).

lca2008 — state of the fedora kernel miniconf

Presented by Dave Jones, another good talk. Some notes:

  • Fedora is going to start providing a vanilla upstream kernel in their yum repos to make reproducing bugs easier. This solves the problem of, “oh, you saw a problem in fedora? does it reproduce upstream?” Any distro that maintains custom patches should implement this solution.
  • Fedora 9 is tentatively aimed for May release, which is approximately the 2.6.25 timeframe. Woo!
  • One of the most anticipated features for F9 will be the stabilization of the on-disk format for ext4. This is a big deal for early adopters, since it would really suck if they started using ext4 and all of a sudden the format changes. Oops!
  • Starting to change thinking about drivers that are not yet accepted upstream. Fedora is going to start shipping them because “a crappy driver is better than no driver”. Doesn’t mean it’s a free-for-all — there are still baseline requirements, like there needs to be an active maintainer, etc. Still, this is a good sign for the users.
  • Xen continues to be a headache. (Does anyone like xen?) Parts of Xen have finally been accepted upstream (after 3 years), but what’s currently shipping in F8 today is actually more featureful than what’s upstream, as the Fedora guys maintain their own bunch of backports and patches. This is the case for almost every distro, I think. There might be a nice way out of it — running a xen domu on top of kvm. Clever and clean, in my opinion.
  • gonna start supporting kernel mode setting. This provides a way for the kernel to change / modify the graphics display (yes, X will need to change to support this). Why would you want this? In case you get a kernel panic while in X — instead of just seeing your screen lock up without reason, the kernel can now dump panic info to your graphical console. Booya.
  • better kgdb / kdump integration. akpm is already carrying kgdb patches in -mm, davej wants to see these merged. Anything that makes debugging easier is good. kdump is pretty cool and shipping in F8 today (modulo whatever setup that needs to happen). The scripts could use some improvement, and my impression was that there’s going to be something better for F9.
  • RHEL6 may or may not be based on F9. Seems like internally, they’re treating it as if it were to be so, which is a pretty good hedge. At worst, all it means is that F9 will be really good. Still, there’s a chance it’ll be based on F10, but in any case, pretending that F9 is the new base of RHEL6 would seem a prudent course of action.
  • Big problem is gathering enough debug information. One of the problems is that Fedora adds the “quiet” argument to the kernel cmdline, so users can’t tell where their kernel might hang. Educating them on how to modify /etc/grub/menu.lst and turn that off, etc. etc. is hard. Yours truly suggested providing a “debug mode” (similar to safe mode) which turns quiet off and boots a debug kernel as a grub menu option, but davej said that the Fedora grub guys are pretty resistant to adding new options (don’t want to confuse the users). They’ve got a point, but there must be a way to hide that sort of magic normally until a developer asks you to press the magic key combination. Someone else suggested just making safe mode do exactly that, which is a good idea too. Real time open source, brosephs!
  • Other bug related things — installing Arjan’s oops daemon to help get more info, setting up a netconsole, and perhaps something like bug-triage day. Good ideas, all.

Yowza, that was a lot.

Edit: hrm, better update this entry so people who did not come here via a link from Dave Jones’ LCA entryget the right ext4 information. Dave writes:

(The bit about ext4 is somewhat optimistic. There’s a ton of stuff left to do for ext4 before it loses its ext4dev moniker. I possibly misled people into believing we’re shipping this in F9 regardless of it state due to the pending changes for .25 The reality is that until the ‘dev’ goes away, I’m paranoid about more last minute on-disk format changes.)

lca2008 — state of debian miniconf

Martin Krafft gave this talk, and I found it to be pretty good. Among the things he presented that I found interesting:

  • debtags — I guess this has been around for a while now, but I never knew about it. Basically, it allows people to add tags to the zillions of debian packages. The canonical example given was that people have a hard time finding the Gimp because they ask apt-cache to search for “image editor” but the Gimp is an “image manipulation” program. Oops. debtags lets other people tag any given package with whatever they want, so hopefully the collective mind will eventually figure out the proper description for a package so that mere mortals can find it.
  • etch-and-a-half — kernel update for etch. The cool thing is they’re adding a new kernel (2.6.24) to the repo, but not removing the old (2.6.18), so a sysadmin can try out the new kernel and easily revert back to the old one if needed. Good idea, and good job, guys.
  • debian maintainers — a new classification in the debian hierarchy. Now, you don’t need to find an existing debian developer (DD) to sponsor you if all you want to do is upload packages to the repo. You can get maintainer status, which is a lot lower overhead (although it comes with fewer privileges, which is fine). This is also a great idea.
  • dpkg symbol resolution — dpkg will now actually look at the symbols in a package to help calculate and resolve dependencies. No longer does it rely on hard-coded version strings. Yikes! Sounds so easy when you think about it, and one wonders why it hasn’t been done before (there must be a good reason, although I don’t know it). Another great idea, and one that’s been a long time coming.
  • debcheckout — there’s a lot of movement afoot to try and get a handle on the bazillions of source control management systems out there. debcheckout will abstract that out so the poor developer doesn’t have to learn svn, cvs, git, hg, bzr, darcs, etc. etc. etc. whew!
  • lca2008 first impressions

    So, the first day of LCA 2008 is winding down, and the first day has been somewhat hectic, between registration (nice schwag bag!), figuring out what mini-confs to go to, and trying to find other HP folks, it’s been an action packed Monday.

    We’ve had a little snafu with the wireless, with some rooms presenting the ESSID in ad-hoc mode, but luckily, wireless in the room where the Debian mini-conf is works just great.

    Never seen so many Linux nerds in one spot, and it’s nice to be with my fellow penguinistas.