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.

So I went to the BLU – Boston Linux User Group – meeting tonight. I hadn’t been in a long time, but the talk was by a guy (Greg Milette) writing actual Android apps that have sold in the app. Market, so I thought it might be fun. It certainly was interesting to hear about practical app. development, not just listening to the same folks bitching again about how Google might or might not have modified the kernel and other bits to provide their desired user experience. Greg demonstrated writing an app, building, and testing, it, and I certainly got the feeling that my intention to have a small app that updates my GPS location on a server periodically (in order to allow me to have my Asterisk and IRC servers automatically route calls/set me away, etc.) would not be too tricky to pull off in a reasonable amount of time. I upgraded my Nexus One to CyanogenMod 6.0 recently and think I’ll find some time to play sometime.

Linux User Groups used to be very hard core affairs, where you’d have some pretty meaty stuff. These days, I generally avoid them because they’re catering to a different audience – not a wrong audience, but just not my cup of coffee. These days it’s often about pretty GUI stuff I don’t care about, and very “high level” discussion. And everyone has a laptop or netbook open and is reading email rather than paying attention. Tonight wasn’t too bad, although there was a guy in front who had discovered a “cow” application that could be run on the command line and would display a picture of a cow with a speech bubble full of whatever text he passed to it. That guy sat there for about 20 minutes (at least) playing with this, typing in various text, laughing to himself, and reminding me why I stopped going to LUGs at least 5 years ago (or maybe that was when he was on YouTube and found a video of dancing cows to complete the theme for his evening). Of course, all of this was on a laptop running Ubuntu. As was everyone else. Nobody there was running anything other than Ubuntu. Not a Fedora in sight. I have opinions on pragmatism that I believe explain precisely why nobody was running Fedora, but nobody is interested in hearing those anyway.

Jon.