The Free Agent is back in shape and working with the latest Ubuntu Linux. Also, Canonical launches the Ubuntu Partnership Programme.
Computing with the Breezy Badger; Partnership Programme
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
A few comments about the article:
First, I thought that the menu editor introduced in GNOME 2.12 was Smeg, yet the author suggests looking at Smeg if you can’t stand the menu editor included in Breezy. Not having a Breezy or GNOME 2.12 install available to me, I wonder if the menu editor in Breezy is not that same as in vanilla GNOME 2.12, or if GNOME 2.12 uses a completely different menu editor than Smeg.
Next, about wireless networks. After a couple of minutes spent battling with Gentoo’s /etc/conf.d/wireless file, I recently found the networking tool included with GNOME 2.10 in Desktop->Administration. After selecting my wireless interface and clicking Properties, three available wireless networks appeared in a dropdown menu (including my own), I entered the WEP key and clicked Connect. I have to say that was the most enjoyable experience I’ve ever had configuring anything using a GUI tool. Then I updated to GNOME 2.10.2 and somehow the tool disappeared from the Desktop menu. I’d like to chalk that one up to a problem with the ebuild, but I haven’t really looked into that too much (I figured out the /etc/conf.d/wireless config). It would be a shame if the GNOME network administration tool were removed in GNOME 2.12 and/or Breezy, as the author seems to imply.
Finally, about dealing with config files across package updates. The author mentions his X configuration getting busted after doing a dist-upgrade from Hoary to Breezy. This is a very important issue that should not be ignored. How do we properly preserve/update/merge configuration files when packages are updated? RPM and Pacman (don’t know about APT) use a simplistic approach to maintaining config files. They compare the old package’s default configuration files, the current configuration files, and the new package’s default configurations. Based on which (if any) are the same, they conservatively arbitrate what to do with the active configuration files and save any new/old configuration files with an extension.
There is an obvious improvement that could be made to this system: strip all comments, version tags, and extraneous whitespace from the files before doing the comparison. In the parlance of RPM, the system misidentifies effective XYX situations as XYZ because of version tags and other meaningless text. Therefore, it decides to replace a custom configuration file with the new defaults even though the defaults haven’t really changed.
Even at that point, though, the XYZ case (where the original, current, and new versions of the config file are all different) is still problematic for the user. The user wants to keep changes made to values of keys that remain valid in the new version of the package, discard keys that are no longer valid, and add keys (with their default values) that are introduced in the new version of the package. Unfortunately, this is hard to do with plaintext configuration files. Even if you make a valiant effort to parse config files into key/value pairs, there will be packages (with strange configuration file formats) that will baffle the system. Suddenly, the Windows registry does seem half bad (in theory).
Challenging the UNIX establishment and its longstanding use of human-readable-editable ASCI text files is not a good idea. However, I think that the world would be a better place if the free software community would create and embrace an open standard for configuration files. We want a format that is human-readable-editable, yet can be parsed into key/value pairs efficiently and precisely by computer programs. Perhaps an XML format would be a good idea, but I think there are better options. I’ve been working with a software package that uses Tcl scripts for configuration. At first I was a little skeptical, but it has actually been a pleasure to work with. Configurations keys can be organized into heirarchical namespaces, and values can have a variety of dynamic types. We could do the same type of thing with Python or a subset thereof.
Sure, it adds a runtime dependency to your package. However, you can throw out your config file parsing code and simply import a Tcl/Python/etc. namespace. And finally, if the package manager does the same, it can intelligently merge configuration changes when the user updates the package.
I think that the world would be a better place if the free software community would create and embrace an open standard for configuration files. We want a format that is human-readable-editable, yet can be parsed into key/value pairs efficiently and precisely by computer programs.
I agree, But it’s not going to happen.
Programers can’t even agree on where their programs should go in the directory structure. Which already is already defined as a standard.
But we can always dream.
– Jesse McNelis
The author mentions his X configuration getting busted after doing a dist-upgrade from Hoary to Breezy.
I don’t think that’s what happened. The Xorg in Breezy has been modularized and lots of changes have happened (e.g. the default fonts are now in a different location). Most likely, the upgrade didn’t touch xorg.conf at all.
dpkg (by default) won’t overwrite a config file that has been changed. So, if you make changes they won’t be overwritten, but you won’t get any of the updates in the config files.
Many packages (e.g. xserver-xorg) use debconf to handle config files ( http://apw.xs4all.nl/cgi-bin/man2html?debconf-devel+8#lbAP ). At least to some extent it can do what you describe (but not exactly like that).
I dist-upgraded last friday. Every time apt found a modified config file, asked me what to do and showed me the differences. I didn’t touch xorg.conf, though it didn’t give me the same results as before.
The most problematic thing was that it lost my gateway (I use a fixed IP)… and didn’t realize for a loong time. I was worried that apt hosed my system or that I removed an important package… until I was pointed to the obvious.
http://shots.osdir.com/slideshows/slideshow.php?release=430&slide=3…
… where was our ubuntu’s news of the day?
Here it is!
We are “sepost” to get DSL in the area soon, if that happens I will download Kubuntu. SuSE 8.1 is getting old, & I want the easier to install .deb files. APT-Get sound good to.