jcm's blog

So it used to be (back in the day), that you would start an application, it would read some configuration, and you would be done. The application would pretty much be self contained, and so would its configuration (none of this windows registry nonsense). Heck, you could even read the configuration with a text editor and make useful changes without devoting time and effort to knowing all of the pieces of an entire stack that keeps changing over time.

These days we have many bits and pieces that are needed just to get my rhythmbox application to run. Tonight’s irritation was caused by gnome-settings-daemon, which seems to have been designed with only local desktop/laptop users in mind, or at least completely fails to handle NFS shares that have gone away. A bit of digging determined the problem, but debugging this is beyond most users. Most users, who start to find applications won’t run or buttons won’t do stuff will just assume the world has imploded and do the windows thing, rebooting their computers. I would love it if we would have either fewer of these random components or a lot more collective knowledge about their design and interaction (documentation, less frequently changing core pieces, whatever). That way, Google wouldn’t lead me only to pages from clueless users having the same problem telling each other to reboot their Linux computers. This is a problem. It is not a good future when everything is so tenuous that users have to reboot their computers to make things work right again.

Jon.

One of the things that bothers me about Fedora development is that things automatically end up anywhere after being built. I’m a big believer in having to do something to put software in the hands of users, even if they are running a development distribution, and even if they should “be able to fix whatever breaks”. Today, if you build something in rawhide, it’ll land on user machines tomorrow (in the default case). This applies especially if you do a “known good” build and then do “just one more” before the early morning hours when the mirrors get updated with today’s version.

In my opinion, rawhide isn’t a playpen. It’s supposed to be a place where things bake, but it should not be the place where random crap is shoved that might (or might not) randomly break things because it hasn’t even been tested on a local machine somewhere first. I think packages should always at least pass a boot/login test (or whatever appropriately similar activity) on a local system before they are made available in rawhide, and there should be some minimal activity involved to indicate that a package is intended for pushing (not just a build that wasn’t done as a scratch or that needs to be tested, etc.). It doesn’t have to require any proventester, any specific QE, any whatever, but it should require that the packager type something that indicates they built this package intending for it to be used by a lot of rawhide users. Again, rawhide is for fun, but it’s not a playpen.

Jon.

So, I was sitting in a hotel room earlier looking at their (simple) instructions for folks to configure their windows laptops. The instructions say exactly what menu options to select, where to find them, etc. Those menu items are always in the same place, with the same names, and have the same functionality across all updates.

I’ve been thinking a lot recently about how Linux is increasingly defining inter-operability based on the random decisions of engineers hacking on projects, and not on industry standards. Engineers who run the latest and greatest software at all times are absolutely the last people who should ever get to make such decisions because they will never notice when someone with a three-year-old distro runs into trouble. Conversely, the groaning starts the moment something is more than ten minutes old. In the real world (a place where people don’t run rawhide, and might be on F-12 by now…maybe – trust me, I talk to computer people who use Linux but aren’t hard core Linux kernel/distro hackers every day), people don’t upgrade every day, don’t run the latest software, and compatible standards matter.

Not only should we not re-invent the wheel as often as does happen (for no gain other than to make it impossible to have a simple “Linux way” to do something – sure your whizz-bang solution boots faster and looks prettier but I never asked you for it and what I had was probably good enough), but we should actually use industry bodies to produce standards, or at least make a bigger effort to standardize. I want, in the future to walk into a hotel room and see “this is how you do this in Linux” instructions, not instructions for Fedora, Ubuntu, blah blah. Because in the latter case nobody is going to care enough to do it and Linux will continue to be a mere afterthought.

Two steps to fix this problem:

• 1). Every project should have architects who set direction and whose opinion counts as gospel on decisions that will impact user experience. They can veto the silly wheel re-invention exercises. People who don’t like that can go hack on Linux From Scratch in their basement.
• 2). Every project should work with independent industry bodies to standardize the moment some new feature comes along. So that there is one “Linux way” to do it, and not ten different but similar ways to do the same thing.

That’s my two cents (sense) on a Friday. If those things happened, users would be the better for it. You may now arrogantly tell me how wrong I am and how much better the world would be if none of that happened.

Jon.