“You can have freedom without choice.”

That someone could even come up with this one is just amazing to me. Note that this is not an exact quote, but it is the summary of Friday’s topic. For example, this summary comes from the idea that Canonical is bad for considering making mainstream non-free software available for Ubuntu based on user preferences. It does not matter who came up with it, of course, but the important thing is that it be called what it is: patently absurd. The ability to choose is a major part of what freedom—or liberty—is. If you cannot make a choice on a matter, then by definition you do not have freedom in the context of that matter. It is quite simple and self-explanatory. Canonical is seeking to increase freedom here, not take it away. Some people actually want to use non-free software; others may not want to use it, but aren’t aware of alternatives. The latter group of people should have our focus with regard to education (but then we should let them make the choice for themselves!).

Note that I am not one of these people: I would rather use free software because of the liberty it gives me that I have come to expect over the years. But I am not going to tell someone else that they are harming me because they would rather use non-free software that is familiar to them. All I can do is show them that there are free alternatives that exist. I cannot—and I will not—make them use it or make them feel bad for not using it. I may not like proprietary software for a variety of reasons, but I will defend people’s right to use it just as I will defend even a stupid person’s right to spew nonsense by way of speech or written word. In other words, “I disapprove of what you say, but I will defend to the death your right to say it,” or perhaps more appropriately, “I [may] disapprove of what [software you run], but I will defend to the death your right to [run] it.” Even I use a package or two that is proprietary in nature (though it is looking like I will not have to do so for much longer, given the efforts to replace these packages with equivalent free software).

It is worth it to note that by adding non-free software to Ubuntu, the free software that is already there does not change. The mere existence of non-free software within its repositories does not make Ubuntu somehow bad or evil. It would add choices that do not currently exist, and that one such as myself or yourself can certainly opt out of—I most likely would, for the most part, as I do not need to depend on non-free application software, and I only use non-free drivers if I have hardware where anything else is nonviable (and only until there are functional free software drivers). Did you know that Ubuntu has an option in the installer to only install free software? Can you say that for your favorite desktop operating system distribution, whatever that might be?

The response to this idea, then, is that without choice, there is very little—if any, really—freedom. The thing that gives us freedom with free software is that we are able to to download the source code, to review/audit it, to change it to fit our needs or fix a problem, and to share those changes. If we cannot do those things, then it is not free software; see the essential freedoms. But non-free software inside a distribution is not something that should not cause you great consternation even if you are among the most dedicated of freedom advocates, for if you are a true advocate of freedom then by definition you must respect a computer user’s freedom of choice. Remember that we choose to run free software because of the benefits it brings to us; we choose to improve upon free software for much the same reason. Eventually, I think that free software will once again become the norm for computer software, on merit alone, for no other reason than the development, release, and usage of free software is a highly practical solution for many things ranging from library code to application software to complete operating systems. It is worth noting that free content—which is similar in concept to free software, which itself is merely a specific application of freedom itself—also appears to making major headway towards becoming mainstream; it is doing so more quickly than free software is, but there is every reason to believe that free software will follow, for it is already.

An Example

Imagine that you are in a store, because you need some milk for dinner some night. You always get 1 gallon of 2%. But, the store has stopped carrying it, because more people buy whole milk and they were throwing away the 2% milk—demand was low, supply got to be too high, so they just stopped carrying it altogether. You leave the store and head to the next in the same town and you find the same thing there. You have a choice of stores to go to, and you have made the choice to go buy yourself some milk. But there is only one type of milk. You no longer have the choice to buy 2% where you are, and so effectively, your freedom to buy it has been taken away. (Of course, you can make 2% milk from whole milk (and make whole from 2% even, or even butter), but I suspect just as many people want to do that as want to write their own free software that they demand simply must exist, but doesn’t yet).

Now, the point here is that there is more than one freedom in play: the freedom of the store to stock (or not stock) various products, which affects your freedom as a consumer to buy the product you want. In the case of software, and choice, if the software you are running gives you all the choices you want, then it fits your needs. If it does not, then you are not going to be able to use it the way you want. Now you have two choices: you can do the work that it would take to make your desired choice possible, or you can use another system (free or proprietary) that will give you the choice that you want. Many people will choose the latter, especially if they are non-programmers. Though I’ve seen programmers also choose to use proprietary systems for something that they could themselves implement. That is their choice, of course. After all, if you really wanted 2% milk, you would have the same choice: make it yourself, or drive to the next town over which might have it available for you (assuming that there is some in stock and that the stores neighboring towns have not also decided to stop stocking 2% milk).

Ubuntu One: The Reason Behind This

This discussion came up because someone on identi.ca made the claim that Canonical is forcing proprietary software into Ubuntu by way of the Ubuntu One client software. I cannot even begin to state just how woefully incorrect this point of view is. First off: the only thing added to Ubuntu is the ability to connect to Ubuntu One, and the software that was added to Ubuntu do to that is licensed under Version 3 of the GNU General Public License. The claim made in response to that was that Ubuntu One is only partly free software, because the server is somewhere else and has not been released. As we shall soon see, that claim is nonsensical—it depends on an extremely naïve view of how software actually works in order to make sense, really.

So, first things first: Ubuntu One, which was added to Ubuntu 9.04, is not proprietary software. The proof rests in the fact that it GNU GPL v3.0, and we know a priori that software licensed under the GPL is free software, so we do not need to go further on that point.

Now, because the software in question added to Ubuntu is free software, we can read it. The essential freedoms granted to us by truly free software ensure this, and the GPLv3 is indeed a truly free software license because it grants those freedoms. Because we are able to study the software and see how it communicates with the server. Once we know how to communicate with the server, we can write that up and design a server that communicates exactly the same way. From there, it is just a matter of patching the sync dæmon that is in Ubuntu to talk to an arbitrary, Ubuntu One compatible server. To determine how to do that, one need only read the Python source code contained in the python-ubuntuone-storageprotocol and python-ubuntuone-client packages. If you do not know Python well, you might expect to spend several days doing that, but if it bothers you so tremendously that you are going to practically start a flame war over it, you may find it worth it to do so.

Of course, the other side to that is this: if you really want Ubuntu One to talk to an arbitrary server that runs free software, and you want that free software to be written, you can fund the effort to write the free software. Approach a proficient developer somewhere out there on the Internet and ask them how much they’d charge to write a server for Ubuntu One. You might not be able to afford the fund the project entirely, but if you get a number from someone, you can start a coordinated effort to raise the funds. If you are lucky enough to be able to fund the whole project, then do so: it is but one way that you can help provide something back to the community. This does not apply to just an implementation of the Ubuntu One protocol, it could apply to anything that you see that is missing and needs to be created. Or you could spend time learning what you need to learn to pick up the project yourself, if you care for the project that deeply. The most important attribute that a person can have in order to get started with development is motivation—James Westby reminded me of this a couple of years ago, something which I had forgotten.

Perceptions: Another (Possible) Reason

It was suggested to me that another possible reason that people would object to having non-free software inside an operating system distribution such as Ubuntu is that they are afraid that the proprietary options have higher quality, or offer superior features, or provide functionality that is not offered by any existing free software. Thus, they have this perception that by adding such non-free software into a distribution like Ubuntu, people will automatically use and prefer it over free software. This simply is not the case. Sure, some people will use iTunes if it is available on Ubuntu. Maybe many people would. I might even do so, if it were legally available for me to use that way and if it supports the purchase of DRM-free music. However, if there were a free software client for the iTunes store, I’d much prefer to use that. To my knowledge, however, there is no such thing that exists.

If there is not a free software alternative for a non-free component inside a distribution of software, if you are offended by that, then by all means, create a free software alternative for it! As mentioned above, you can start on such a project’s development, or you can look for people that would be interested in volunteering for it and coordinating them, or you can put up funds to pay developers to implement it. If you have money, this can be the easy part: find someone who is willing to accept payment for the service of implementing the free software alternative for whatever it is that someone else has funded, wrote, and released as proprietary software. It is not like free software is developed without cost (and if you think that it is, then you seriously do not understand what free software is or anything about the world of free software and have no standing to be getting mad when a company spends money writing software and does not release it as free software. You can try to write companies that write such software and ask them if they will give you any form of written specifications for the software, or an interface definition, or something along those lines. The worst thing that could happen is that you will be told “no”. And do so nicely, or they’ll be more inclined to tell you “bugger off” instead of simply “no”.

“Allowing users to choose proprietary software is anti-freedom.”

Nothing could be farther from the truth; it is the same, in fact, as the above statement that one can have freedom without choice. For example, if Ubuntu adopts iTunes and makes it so that you can “sudo aptitude install itunes” in the future, that is not a bad thing! How can it be—It contributes to the ability to choose, and thereby contributes to the freedom of the end-user. If you are a die-hard free software supporter and do not want to run non-free software on your system, then there is a very simple solution for you: simply don’t install it.  That is a valid solution to the problem. There are tools already available that can be run as a cron job and report on any non-free software that you might have accidentally (or even intentionally) installed. If you are worried about additional non-free software getting into Ubuntu, then help enhance those tools. Or write a GUI front-end for something like the virtual RMS program and work to get that included into Ubuntu as well, perhaps something that can run every time you login to the computer, or that runs as a persistent process that watches the package database on your distribution of choice for updates and then checks to see if newly installed software is non-free and alerts the user. Of course, it’d be most effective as an opt-in system, and not an opt-out one where it would just be annoying.

There is no way, then, that freedom is actually reduced in this way when another choice becomes available. If iTunes were to be included in the repositories (and I suspect it would be, like the restricted, universe and multiverse repositories, a separate opt-in repository; perhaps simply “proprietary” would be fitting), this does not reduce your ability to choose to run a free software media player and manager like Banshee, or Rhythmbox, or even AmaroK if you are so inclined to run that KDE stuff.

Once upon a time, FUD (fear, uncertainty, and doubt) was the tool of Microsoft. We (the free software world) completely hated it when Microsoft would put out FUD, because we would then have to fight that FUD by way of explanation and demonstration. Well, some time ago, a subgroup of the free software world decided to start using FUD themselves—it was done with Mono, and it is being done now with just a survey asking people what sort of software they would like to see in Ubuntu. Now, those of us who are left who are advocates of liberty—both personal and societal—are stuck potentially fighting two battles. One with Microsoft’s FUD—such as the constant notion that you have to pay for software—and one with the “free software evangelists” FUD, who have even gone so far as to say that people should not use certain types of free software (the one who calls himself “The Open Sourcer” even still today tells people to remove certain truly free software from their systems). The truth is somewhere in the middle, between these two ends of the spectrum.

Conclusion

Back to the point at hand: to say that giving a person a choice is a constraint on that person’s freedom, that is doublespeak.; it is saying that “slavery is freedom,” albeit to a lesser degree than that very melodramatic extreme—it simply does not make sense. The concept just does not make sense unless the words that are used to express the concept are dramatically redefined to mean things vastly different from what standard English dictionaries define them to be. The only reason that one has to try to convince someone that additional choice is a constraint on freedom is to try to convince people of things that are not true; to install fear, uncertainty, and doubt into people. This is the sort of behavior that—no matter what community it originates from—is completely immoral, unethical, and absolutely unacceptable. It’s dishonest, and for those of you who know me personally, you know what I think of dishonesty.

Through something of a comedy of errors, the server suffered some strange software issues that prevented it from working this weekend.  There was a bug in a recent update to the server software (running testing software) and that caused longer downtime than it should have due to various interactions between things on the server.  The good news is that this is mostly fixed.

Additionally, this downtime has taught me that there is yet still more to do in terms of getting the server able to stand back up on its own.  I’ve simplified the server’s setup a bit, and I have to write some scripts and other little glue here and there to tie down some of the things I’m doing so that the server can do things like go down and come back up without issues, all by itself.  Getting that done would be generally a good thing.  First things first, I have to figure out a decently reliable way to shutdown the system without having to do something like kill the containers and not give them the chance to cleanly shut down.  Ideally, there would be some sort of command that could be run on the system that would enable the containers to be shutdown.  This is slightly challenging, because you cannot just chroot into the directory tree that the VMs are running in and kill processes, because things like /proc inside the container aren’t visible to tools running on the host.  Oops.

So, I have some work left yet in terms of getting the server going the way it needs to be again.  After that, I’ll be working on it over the next couple of weekends to try to increase its robustness, and so planned weekend downtime for *.trausch.us and www.mischiefinoverdrive.us can be expected. 

One piece of software that is almost ubiquitous (at least, outside of the not-so-wonderful world of Microsoft Windows) is a small program known as m4.  You may or may not have heard of it, and you have probably never used it outside of the GNU build system if you’ve used that at all.  m4 is fantastic, if hard to learn, but it is available and it is a pretty much standard component of most UNIX-like systems.  It is a macro processor that dates back to V7 UNIX and it’s been standardized as part of the POSIX body of standards, and GNU has its own version with extensions.

Essentially, what you do with m4 is create macros that process text, and then you can use those macros to simplify things.  In other words, m4 makes it possible to follow the DRY principle when it comes to writing text documents, configuration files, and other text-based files.  For example, I’ve written some macros to make it easier to work with djbdns configuration files, which are available on my software page.  Instead of writing a line that looks like this:

+alltray.trausch.us:173.15.213.185:600

I can write a line that looks like this:

DD_A_FULL(alltray, 173.15.213.185)

Or, for multiple hosts that share the same address, I can (actually, I do; this is from my configuration file) do this:

DD_A_IP(173.15.213.185)
DD_A(allspice)
DD_A(alltray)
DD_A(mike)
DD_A(morganne)
DD_A(phone)
DD_A(projects)
DD_A(sip)
DD_A(vcs)
DD_A(www)
DD_A(gallery)
DD_A(wiki)
DD_AAAA_IP(2001:470:1f11:3f::1)
DD_AAAA(allspice)
DD_AAAA(alltray)
DD_AAAA(mike)
DD_AAAA(morganne)
DD_AAAA(phone)
DD_AAAA(projects)
DD_AAAA(sip)
DD_AAAA(vcs)
DD_AAAA(www)
DD_AAAA(gallery)
DD_AAAA(wiki)
DD_AAAA(spicerack)

The nifty part is that the AAAA lines actually expand to:

:allspice.trausch.us:28:\040\001\004\160\037\021\000\077\000\000\000\000\000\000\000\001:600

Which, as you can imagine, is quite a pain to manage manually.  However, using m4 and some helper programs that are written in C for formatting IPv6 addresses for AAAA records and formatting SRV records for things like XMPP services, managing my configuration has become so easy that I don’t really have to think very hard to do it.  I don’t have to seek out any online generators for SPF records, AAAA records, or SRV records.  I don’t have to worry about repeating a TTL in every line, either, because I set up a domain like so:

DD_DOMAIN(trausch.us)
DD_TTL(600)
DD_SOA(spicerack,mbt.zest.trausch.us,1800,600,21600,600)
DD_NS(173.15.213.185,spicerack)
DD_NS(,primary.staffasap.com)
DD_PTR(173.15.213.185,spicerack)

And for a section that should have a longer TTL, I do so by saying DD_TTL(longer_ttl) and then writing the new lines.  I didn’t try to turn the configuration file format into something that was BIND-like (after all, part of the reason I left BIND was I hated managing its configuration files) but I did make the configuration easier for me to manage.  Now, when I need a new address in the file, or change anything about my domain, it’s as simple as adding or deleting macro calls, and the rest is handled for me.  (I also modified my Makefile that generates the djbdns "data.cdb" file so that m4 is called automatically when I update the data.m4 file.)

M4 can be a major pain to use until you learn it.  And while I do sometimes run into the occasional pitfall with it, I’ve used it for adding preprocessing capability to C# and Vala code to make my life easier, and I’ve used it for various other things in the past outside of the GNU build system.  I absolutely love it.  It is not for everyone—indeed, not everyone has a use for a macro processor—but if ever the need arises, it is well worth your time to learn m4 and use it any time you need a macro processor.  It sure beats having to learn macro processors that are specific to a particular environment, and thanks to Cygwin, you can use GNU m4 on Windows, too, if you happen to be so unlucky as to have to live life with 20% of your CPU cycles (and who knows how much RAM) paid as a tax to fend off viruses and malware. 

And no, m4 isn’t just for programming, nor is it just for programmers.  Anyone who works with a great deal of text is likely to have a good use case for it.  People have been known to avoid using things like PHP and alleviate server-side stress by using a set of macros and generating all of their pages statically (without having to statically manage them all).  This can be good if you have to work with a server that is extremely light on resources and shouldn’t be running things like server-side scripting languages and fetching data from databases.  Instead, you can do all of the database lookups and page formulations ahead of time, meaning that the so-called "slashdot effect" doesn’t ever cause you any trouble on nearly any type of server since it is only serving static pages.  Or writing documents that require things like legal boilerplate and the like; though the days of text processing and typesetting for the masses have generally gone away, sadly.  There are a potentially unlimited number of applications that m4 could be used for—and while m4 is somewhat difficult to learn and can be frustrating at times, it’s standard and it has decades of history, like UNIX in general.

One of the very few times I have uttered this phrase, but it works now:  Thanks, Microsoft.

1. Download the JRE or the JDK for 6u12 from Sun Microsystem’s Java download page. Select the bin option, NOT the RPM.
2. Save the file to your home directory.
3. When the download is complete, open a terminal and enter:
   • chmod +x jre-6u12-linux-x64.bin
   • sudo mkdir /opt; cd /opt
   • sudo ~/jre-6u12-linux-x64.bin
4. Type “q” and then type “yes” followed by to accept the license agreement, and the software will now extract in /opt/jre1.6.0_12
5. Tell Ubuntu how to use it:
   • sudo update-alternatives --install /usr/bin/java java /opt/jre1.6.0_12/bin/java 1
   • sudo update-alternatives --install /usr/lib/xulrunner/plugins/javaplugin.so xulrunner-1.9-javaplugin.so /opt/jre1.6.0_12/lib/amd64/libnpjp2.so 1
   • sudo update-alternatives --install /usr/bin/javaws javaws /opt/jre1.6.0_12/bin/javaws 1
   • If you downloaded the JDK, set up links for javac this way, too.
6. Tell your Ubuntu system to use the new JRE:
   • sudo update-alternatives --set java /opt/jre1.6.0_12/bin/java
   • sudo update-alternatives --set xulrunner-1.9-javaplugin.so /opt/jre1.6.0_12/lib/amd64/libnpjp2.so
   • sudo update-alternatives --set javaws /opt/jre1.6.0_12/bin/javaws
7. Restart Firefox, and verify that it works:
   • Type “about:plugins” in the address bar, and you should see a bunch of stuff for Java there.
   • Go to the Java Version Tester. It should tell you that you are running Java Version 1.6.0_12 from Sun Microsystems Inc.

There you have it—a functioning Sun JVM in your 64-bit Web browser. It’s about damn time, Sun!

Also, you will want to run *.jnlp files with “javaws”. You can do that in whatever your file manager is, and you may also need to do that with your browser (say, Firefox). There are instructions for Nautilus in the comments below.

I’d attempted it earlier, when I set up Ubuntu Hardy on my server just before it was officially released. Due to time constraints, I wasn’t able to finish working on it, and that was different with the release of Intrepid.

It was my intent to document everything every step of the way so that it could be made easier for everyone and I could share everything I learned along the way. That didn’t quite happen the way that I wanted, but I did still learn a lot and will be putting the final touches on testing the setup tomorrow, with the hope that it will work as my testing tonight shows it will.

After that, hopefully, I’ll be able to write up a document on setting this up with Ubuntu. There are a lot of documents out there which provide useful information, though this process involved a lot of trial and error and reading of more than 200 pages of printed material for me. That’s not a lightweight task, of course—and I’ve been using computers and UNIX/UNIX-like systems for a very long time. So, yes, currently setting these things up is something of a complex deal.

But, I did learn—well, more reinforce something I knew already—something throughout this little project. I’ve mentioned before that I think that the way Linux systems are distributed probably ought to have something of a better, cleaner division between what is the application software and what is the system software. This is another situation where I think that such a difference would be a wonderful thing in a system. What do I mean?

Well, we see in the Windows world such a division. When you purchase a copy of Windows, you choose one of eleventyone versions that fits your needs (or at least, so you think). We could do something similar for Linux systems, though we could obviously reduce the number of choices under a single brand to something that users would actually care to look at. Ubuntu has done some of this already—they ship different configurations of software by default for server and desktop versions, for example. However, the division between the system and the applications that run on the system is completely nonexistent. For people who very much like to tweak their system, this is something of a mixed blessing. For starters, it makes it easy to modify any single package which comprises the system. However, it can be a bit of a problem when you want to do something task-oriented that involves a mix of application and system software—that is, system software for an application.

I don’t know what the ideal approach is, or would be. It’s something that I’d like to try to figure out, though, at some point. FreeBSD has an interesting layout wherein the system itself is not managed by the package manager and is considered to be an implicit dependency in the package management system, and everything outside of the base system is installed using ports. This is a cool concept. What if someone were to do something similar with a Linux system and create a distribution wherein the base system is a nice tree of source packages which are shipped together in a single unit—and maintained together as a single unit—and then use the package manager to only manage application software?

Doing this is something that would be bound to make some current users unhappy—I wouldn’t expect that a Gentoo user would want to think about playing with such a system when they’re already quite happy with Gentoo, for example. But, if you made a desktop environment and server software to go with it, and made the system segments catered to each purpose, you’d have something that a manager could pull “off the shelf,” so to speak, and immediately put to use. If you have the assurance that the only people that are going to be modifying the base system are people that are very sure they know what they’re doing, then you also make it easier to assume a few things about the base system in various different configurations.

As an example, take a fictional new brand which had two distributions, the server distribution and the desktop/workstation distribution. The install process for both would be relatively fast, with only a few things being configured at set-up time. On a server install, there should be a common set of server software that is easily configurable—using utilities bundled with the server itself. On a workstation install, you’d have a similar thing, with the easy ability to join into any setup that the server supports, or maybe even that other servers running on other operating systems support.

Windows Server includes an interface for quickly configuring things like the Microsoft DNS server and IIS, and when you set up the directory service under it, it is integrated very nicely into the DNS server. For example, when you configure an Active Directory domain, there are automatically DNS records which are published so that Windows workstations can find the AD controller and use the services on it. We need something like that on Linux systems—where one drops a server, say, which can be quickly configured to provide central authentication and storage services and just as quickly get the clients up and running. Then, the solution is very quickly integrated.

What would this require? It’d require a distribution that manages certain classes of software—such as the DNS server, and the LDAP directory service, and the Kerberos authentication system—as system software and not as userland packages. Why? If you don’t, you have to decide things like which implementation of Kerberos you’re going to be using, or which LDAP server you’re going to use. The most common combination, as an example, seems to be MIT Kerberos with the OpenLDAP server, typing these into PAM and then combining them with some sort of networked filesystem such as NFSv4. This is what I did, in fact. There is also something called OpenAFS which can be used to provide the filesystem portion of things.

But, the important part would be that these things are configured by a single piece of software which is tasked with the purpose of integrating these things together. In other words, if you create a server product, you can provide a set of reasonable default choices for the software and also provide easy access to common configurations. Obviously, you’re not going to meet everyone’s needs if you only provide single solutions for each task, though, right? Probably not. But the point isn’t to fit every single possible configuration—the point is to give a quick starting point to launch quickly from and then give the user the ability to focus on doing more advanced things with their software. If I didn’t spend the last three days fussing with Kerberos, LDAP, and NFSv4, for example, I could have spent 30 minutes on the initial setup and then spent another three days putting all the polish on for very little things that I wanted to do. Or I could have spent the time moving my domain’s services—like this blog, or the email domain, or the Jabber domain—onto my own network. Or any number of other things.

Furthermore, if you provide a client which is fully and easily integrated into the server, you can do a great deal more in far less time. The client setup could even be smart enough to look for certain hints on the local network for the installer—say, issuing a few requests to the local DNS server such that it can automatically detect whether or not one is using a directory service and prompt the user during the workstation installation process as to whether or not they want to become part of that collection and configure their workstation to become a functional member of that network automatically. Maybe the network server of this fictional branded distribution could also publish information on the network which provides configuration settings for installed machines in a purely automatic fashion, making it such that if you want to install, you just start the installer and have the workstation configure itself. Then when you have a very large organization, providing a new workstation is a very easy task: Plug it in, install it, and go. This idea could even be extended to provide for different configuration profiles which could be used for very large networks, and I think it’d be better than the systems that exist currently.

To my knowledge, no such distribution exists. There are distributions that come close—I do like Ubuntu Server for its ability to quickly pull down and configure individual pieces of network infrastructure—but there is not (to my knowledge, anyway) any distribution which provides a very high level of quick-setup-and-go for many different things, and provide an easy-to-manage way of doing things with it.

I do think, for sure, that it all starts with removing the base system from the package manager—in effect, using a different method of management of the base system than the package manager provides. I think it’d also make long-term-support releases of desktop and server software much easier, since the line between the system and application software is more clearly drawn.

So, what to do after installing it? Here’s a few things:

1. Install ubuntu-restricted-extras. This will give you MP3, Flash, and Java support.
2. Install Banshee. It’s a hell of a media player, and very enjoyable to use.
3. Optionally upgrade to OpenOffice 3 using the Intrepid PPA. However, the major feature that everyone will likely want from OpenOffice 3 is already included in Intrepid’s OpenOffice 2.4—Office 2007 file support (read-only).
4. If you are able to use compiz, install the Emerald window decorator. It’s lovely.
5. Not sure if you could do this pre-Intrepid, but you can install the smbfs package and say (as a regular user) mount.cifs //SERVER/SHARENAME /path/to/dir -o user=USER to mount a Samba or Windows share in your home directory. If you don’t need a password, be sure to make -o user=USER into -o user=USER,guest

which will drop the request for a password by mount.cifs. You can also put such filesystems in the global filesystem mounting database, /etc/fstab.

Also, if you have the desire to see your fonts get really good looking, add the following to ~/.fonts.conf:

<?xml version="1.0"?>
<!DOCTYPE fontconfig SYSTEM "fonts.dtd">
<fontconfig>
  <!-- Set the DPI -->
  <match target="pattern">
    <edit name="dpi" mode="assign">
      <double>89</double>
    </edit>
  </match>

  <match target="font">
    <edit name="autohint" mode="assign">
      <bool>true</bool>
    </edit>
  </match>

  <!-- Configure default monospace font. -->
  <alias>
    <family>monospace</family>
    <prefer>
      <family>Monaco</family>
      <family>Courier New</family>
    </prefer>
  </alias>
</fontconfig>

This will add use of the auto-hinter so that you can have fonts that look better. You can tweak the file in other ways, too, telling the font system to not antialias monospace fonts, for example.

Some notable things that didn’t make it into Intrepid: OOo 3, stable ext4, and Mono 2.0. You can get all of these by installing them from PPAs, or directly (ext4 comes with the 2.6.28-rcX kernels, which you can use by building from upstream if you do not depend on any Ubuntu-provided drivers, and if you use NVIDIA, I have a post here that talks about how to re-enable the NVIDIA driver for 2.6.28 series kernels. Mono 2.0 is available in a PPA. If you want to play with MonoDevelop SVN, you’ll need to have Mono 2.0 installed somehow. You can do so in your home directory (without affecting your system) by installing the build-dependencies and then using a script that I wrote and put up here.

I am really happy with GNOME in this release, too. It’s a great release, though I am looking forward to what Jaunty has in store for us, really. I really am a neophyte when it comes to software, and I like to live on the bleeding edge. I don’t know why, but I guess that’s just the way that I am… Maybe someday I’ll stop doing that. For now, though, I like watching the development of things pretty close to real-time.

  File: `workspace'
  Size: 4096      	Blocks: 8          IO Block: 4096   directory
Device: 806h/2054d	Inode: 3228229     Links: 4
Access: (0755/drwxr-xr-x)  Uid: ( 1000/     mbt)   Gid: ( 1000/     mbt)
Access: 2008-10-23 13:42:23.000000000 -0400
Modify: 2008-10-23 13:42:22.000000000 -0400
Change: 2008-10-23 13:42:22.000000000 -0400
  File: `yellowdog-6.0-DVD_20080207.iso'
  Size: 3983831040	Blocks: 7788528    IO Block: 4096   regular file
Device: 806h/2054d	Inode: 1573509     Links: 1
Access: (0644/-rw-r--r--)  Uid: ( 1000/     mbt)   Gid: ( 1000/     mbt)
Access: 2008-10-25 05:45:11.375116110 -0400
Modify: 2008-10-25 05:45:11.375116110 -0400
Change: 2008-10-25 05:45:11.375116110 -0400

And:

Saturday, 2008-Oct-25 at 05:45:12 - mbt@zest - Linux v2.6.28
Ubuntu Intrepid:[1-25/9412-0]:~> mount | grep home
/dev/sda6 on /home type ext4 (rw,relatime)
gvfs-fuse-daemon on /home/mbt/.gvfs type fuse.gvfs-fuse-daemon (rw,nosuid,nodev,user=mbt)

Works for me. Will play more with it tomorrow.

And no, I didn’t package it (the kernel) up… to build it, just follow the instructions that come with the kernel, and then on Ubuntu, run update-initramfs and update-grub. If you use the NVIDIA driver 177.80, see my previous post for a change that needs to be made to /var/lib/dkms/nvidia/177.80/source/nvacpi.c and the kernel tree to make it build on the next reboot after upgrading your kernel.

$ sudo apt-get build-dep libgtksourceview2.0-cil \
 libgecko2.0-cil libgtk2.0-cil libgnome2.0-cil mono \
 libgluezilla

The usage screen for the script:

Mono 2.0 Home Directory Installer

Copyright (c) 2008 M. Trausch <mike@trausch.us>
License: GPLv3

Total download: ~206 MiB, total installed size: ~161 MiB.
Download & build takes ~35 minutes on an AMD Phenom 9500 Quad-Core CPU w/ 8Mbps
downstream Internet connection (and happy servers, of course).

Logs are output to '/tmp/mono2-build.3044/log'.

usage: install-mono2.sh [options]

Available options:
  -s PKG
  --skip PKG	Skip building package PKG (one of libgdiplus, mono, mono-basic,
		gtk-sharp, gnome-sharp, gnome-desktop-sharp, gluezilla,
		monodoc, mono-tools, mono-addins, gecko-sharp,
		gtksourceview-sharp, heap-buddy, nant, monodevelop).  May
		be specified multiple times.

  -d
  --download-only
		Only download the packages, do not install them.

  -r
  --monodevelop-revision
		Specify which SVN revision of MonoDevelop trunk to install.
		Defaults to SVN HEAD.

  -S
  --skip-download
		Skip the download (if you're rebuilding, use this to
		save bandwidth.

  -m
  --monodevelop	Download, build, and install MonoDevelop only.  ONLY USEFUL
		FOR UPDATING MONODEVELOP AFTER YOU'VE RUN THIS SCRIPT TO
		INSTALL MONO 2.0.

  -1
  --single-cpu	Use ONLY single CPU/core for building.  Use this if you have
		trouble building and think it might be related to 'make -j'.

Now, when this script runs, it will download the Mono files (and MonoDevelop from SVN) into /tmp/monosrc. It will do the build in /tmp/mono2-build.XXXXX where XXXXX is the process ID number of the install-mono2.sh script. When you’re finished and happy with the installation, you can safely remove those directories:

$ rm -Rf /tmp/mono2-build.* /tmp/monosrc

If you want to track MonoDevelop within SVN, then it is better to not delete /tmp/monosrc, because the script uses svn to pull from the MonoDevelop Subversion repository. This means that it can, if the directory already exists, save you bandwidth by only pulling a delta from the revision that you have and the current HEAD revision. The astute probably noticed that you can select a revision explicitly as well. I am currently using r115695, and have used it for a grand total of 20 minutes (and debugging, as best as I can tell, works quite wonderfully in it, but it is a work-in-progress, coming directly from the development mainline). In short, the MonoDevelop is great for toying with but not for production use. I may release a version of this script that lets you choose between the latest stable released version of MonoDevelop and an SVN revision, but I haven’t gotten there yet because I wanted to play with the SVN version (which uses features in Mono 2.0… that was the whole point of me wanting to play with Mono 2.0, actually).

In any case, the script is available for download here from my Web site.

A few words about the script: This script is released under the terms of the GNU General Public License, Version 3. It is version 3 ONLY. There is NO SUPPORT for this software; I wrote it for myself, and it may change or it may stagnate. I provide it in the hope that it is useful to someone out there other than myself, but it is AS-IS, WITHOUT WARRANTY, UNSUPPORTED software. If it changes your dog’s gender, bursts your house into flames, destroys your whatchamacallermicroflobbermajag, do not come and yell at me. That having been said, I welcome any modifications (at least to view them). You can modify it for your own use, you can share it (in fact I expect you to!) and you can tinker with and tweak it. Suggestions? Welcome! Comments? Welcome! Flames? Hey, free speech is your right…

Lastly, I RECOMMEND THAT YOU RUN THE SCRIPT ON A CLEAN USER ACCOUNT, WITHOUT YOUR DATA, WITHOUT YOUR ANYTHING IN THE WAY. Just create yourself another user, and login to it using Xnest or something, or log out of your user account completely—I don’t care how you do it. Why do I make this recommendation? Because while nothing bad should happen, it’s always best to sandbox things that you don’t trust. After all, what reason do you have to trust me if you don’t know me? You can also of course read through the script and audit it if you wish. It doesn’t handle EVERY exceptional condition, but it handles just about anything that needs to be and tells you where things went awry if they go wrong. And it logs everything (see the program output when you run it). It also takes advantage of multiple processors or cores if you have them for those (few) builds that will permit it without going nutso, but YMMV. If you have an issue with this aspect of the script, see the usage text. If there are any issues that you can’t solve with that, or installing build-dependencies, then paste the relevant segments of your failing log file to something like pastebin and ping me a comment here, and I can take a look at it and (try to) offer advice, depending on where the fail is.

Oh, yeah, and I used a hell of a lot of bandwidth putting it together and making sure that it did things like downloaded things right and all of that. Sorry for hitting your servers repeatedly, Mono people—and thank you for the software!

Does anyone else think that it’d be a good idea to segregate the core of the system and the application software into two separate bundles of packages? Say, for example, that the base system would comprise the absolute core software—the software that comprises the operating system, and core libraries. These could be managed by some package manager that manages the base system, say, “sys-dpkg”. Then you’d have application software, which could be managed by the “dpkg” command that we all use for managing that sort of thing anyway. This would seem to make a _LOT_ of sense for LTS releases, though it’d be useful for non-LTS releases, as well. The idea would be that application software and application frameworks would be managed separately, such that they could be more fluid. As long as they don’t depend on a newer version of the base system, they’d easily be able to be installed on systems. Otherwise, what people are left with are really just frozen snapshots of the way software was at a point in time, unless they’re an advanced user. Even a regular user can install software on Windows… they can do it on something like Ubuntu, too, but they can’t just go somewhere and download the software and install it on their system. Wouldn’t it make sense to make packaging for application software easier, and promote the idea of a separation between the operating system and the application software?

Thoughts?