desktop Unix has not arrived

Recently, the arrival of desktop Linux (and, no, I refuse to say GNU/Linux as much I refuse to say GNU/X/OpenBox/LXDE instead of Lubuntu) was announced. I think this came as no surprise to those of us that already use it on desktop. Sure, people may complain about this and that, but, honestly, Linux gives you choices. You can find your perfect desktop on Linux quite easily in this day and age of package managers. Filled with pre-compiled binaries, changing even components of a desktop environment is fairly seemless and just a few clicks away. Gone are the days of having to roll your own kernel from scratch (though, in typical fashion, you have the choice to do so). Heck, you rarely have a need to touch the command line (though it's often quicker). With Chromebooks and about half of the mobile devices out there running Linux under the hood, user-focused Linux is certainly here.

However, if we revisit that blasted GNU acronym, we should be reminded that GNU's Not Unix, or rather that Linux's Not Unix (ooh, we could fix the naming controversy by calling it LNU… but then someone would wawnt to call it G/LNU and that would be hard to pronounce). See, Linux owes its design and heritage (though not its code) to Unix. In fact, Unix is still plugging along, with some notable examples being the ever-secure OpenBSD, the distro that runs on pretty much everything, NetBSD (yes, that does include Amiga and VAX!), the almighty FreeBSD which is widely used by web servers, OS X, and plenty of embedded devices, and the version from whence Linux was born: MINIX.

So one might wonder how desktop Unix is doing. OS X certainly has made it but the FreeBSD core, Darwin, is quite different. Not to mention that it's a walled garden. It's not easy to change your window manager and using the command line is a frustrating experience, especially if you don't want to use the GUI. I guess that's not a very "user-focused" concern, but I think it reflects just how much OS X deviates from anything we think of as Unix-like. Ignoring that, it might be good to look at FreeBSD, as it is, if I may conjecture, the most widely used Unix out there.

Well, to give one a sense of things, I had to recently do an update on a co-worker's development machine, which was running FreeBSD and had an X setup. According to the FreeBSD documentation, assuming one doesn't need the "easy button" when it comes to installing, there's no need for PC-BSD. In this case, everything was installed, so no big deal, right? For that matter, all that needed to be done was to do some security updates. Those friendly folks at FreeBSD offer a script in periodic daily that emails root with updates on packages that need to be patched for security updates. Admittedly, the thing hadn't been updated in a while, but having been doing regular maintenence on other FreeBSD servers, I figured it would be fairly straightforward.

All of these machines use ports, which is basically a package management system that uses source code and compiles with each fresh install. There's also packages, but we use ports. Adds a little extra flexibility and is no more difficult, really. The package management system takes care of everything, including dependencies, as any good package manager would. The portmaster tool makes this task quite simple, needing little more than the package name to be installed.

Unfortunately, I faced several gotchas. One, in fact, came when having to update pkg, which is usually used for binary package management. It was super weird because I couldn't install it with portmaster, even if I specified it's full location (which usually fixes any ambiguity). I looked at /usr/ports/UPDATING, which is the canonical place to look for gotchas, but didn't find anything. On a whim, I chose to include the package version to upgrade from, and that worked. Never had that happen before at all, and never found any reference of others having it.

The next one was fairly easily solved, assuming you know where to look. gettext gave me an error on its install. I found the solution in /usr/ports/UPDATING: the port had been split, so I needed to remove the port and then reinstall it. Simple fix, but greping through a text file is not something one typically should be expected to do to install a freaking package. Also, the error didn't suggest where to look for the problem. You had to put two and two together.

So then I ran into some issue with GTK. First, I was having issues with gtk-update-icon-cache. I found something related, albeit old, in /usr/ports/UPDATING, so I decided to give it a go. I understood what I was doing and that doing it wasn't going to hurt anything if it didn't fix my problem. It referenced using pkg_delete -f gtk-2.\*. Now there's several problems here, the most obvious being the fact that there are three different package management tools: pkg, pkgng, and portmaster. Sometimes you might use a pkgng command even though you otherwise use portmaster. Problem is that that's not all described in these terse notes. Secondly, GTK2 is in a port called gtk2, so the search string was wrong, too. So pkg delete -f gtk2-2.\* did the trick.

So then there was complaints about cairo not being installed with X11 support. I confirmed it was installed. I checked the Makefile and there was a line that suggested that X11 was a default, but after digging some more, I discovered that it merely was a default option. Indeed, pkg info showed me "X11: off." I decided to run make config and there I could see it was not checked. So I checked it, did a make deinstall and a make reinstall and it was recompiled with X11 support.

However, I was still having issues with gtk. it failed to compile because of some test that required working with a PNG. It complained to not recognize the format, even though file had no problem recognizing it. Google produced no truly applicable results, but there was some mention among MacPorts/Homebrew folks about glib2 and gdk-pixbuf2. Checking the config of the latter, I discovered it was lacking PNG support, so I checked it, reinstalled the two, and finally, I got everything done.

One might be inclined to believe that since this is all on the command line, such problems are to be expected. I would, in fact, suggest the otherwise. As a general rule, graphical tools are front ends to command line interfaces. Ubuntu's Synaptic Package Manager is a great example of this. It's just apt under the hood. If the backend did not have a predicable, reliable interface, where one did not have to interpret, research, and intuit in order to figure out problems, then the frontend would suffer the same problems. That being said, the potential graphical interface to the FreeBSD package management system(s) are bound to be equally flawed.

That being said, desktop Unix is not here yet. Frankly, I'm not convinced it ever will be. Unix is a tool that was originally targeted at institutional use and to this day is employed largely by system administrators and hardware hackers. It tends to be fairly conservative (I like to call it "stable to a fault", which is to say you don't get the latest and greatest googaws). It's oriented towards the command line and towards users that are familiar enough with compiling to be able to deal with issues. Granted, it's a lot easier than grabbing a tarball and figuring out all your dependencies. But desktop Linux it's not.

To be clear, this it not meant to be a bash on Unix (actually, bash is not a standard part of the install!). BSD is excellent where stability and security are required at the expense of anything else. Having the ability to sort of create your own system from scratch the easy way sure is nice. A few make configs and you can have your system locked down to only do what you want. That includes your kernel, too. I'm sure this is part of the reason why OS X uses it (well that, and its precursor, NeXTSTEP, was derived from BSD).

I'm just pointing out that just because it's been out for much longer than Ubuntu, BSD and Unix in general, has not been able to really capture the attention of desktop users while still retaining the flexibility inherient in a standard system. In that sense, it's actually pretty amazing what Linux has been able to accomplish. Call me biased, but I give special credit to Ubuntu as it has moved beyond the neckbeards and actually drawn the attention of your average Joe, not just through its wonderful user interface, but through business partnerships and outreach. That is the herald of a great desktop operating system.

Read and Post Comments

learn anything linux

If there's anything I learned from hack.summit() (more on that soon), it's that we need more mentorship opportunities. The Ubuntu community informally offers mentorship opportunities, but with the loss of the Ubuntu Beginners Team, the amount of mentorship, I believe, has declined. Without a formal and inviting place, I think a lot of people are left to kind of figure it out on their own. With so many documents being written to a more higher level of user, I think we really lose potential contributors.

With the goal of having Linux users also be Linux contributors, a band of friends and I (mostly from the Lubuntu Team) have put together a new project we call Linux Padawan. You might remember that padawans were apprentices to the Jedi Masters in Star Wars. So we seek to unite masters with padawans to be mentored in their learning and contributors to their respective community.

Note that wording. Linux Padawan is distro-agnostic. There are certainly many of us who are from various parts of the Ubuntu community, but not all of us are. Additionally, we don't want to shut the door on people who are not or may not be interested in joining the Ubuntu community. Of course, we'll continue to invite them in. ☺

I've set myself up there with the following areas of expertise: testing & bug squashing, community, programming, Lubuntu, BSD (yes, we're even going to support BSD!). If you need mentoring on any of these, please let me know.

I really want to focus my efforts on programming, though. I'm not the world's greatest programmer (yet), but I know enough that I can help foster people to become programmers. hack.summit() focused on how we need mentorship in programming. I couldn't agree more. Learning how to program is relatively easy. Taking that to the next level and actually making a contribution is a whole different story.

To that end, over the past couple of days, I have developed a fairly general introduction to the subject, with plenty of links. Please take a look at that here and let me know if you know of any other resources that can be added.

Most of all, I encourage you to consider learning programming. It's not as scary as it seems. Additionally, learning some of the tools and processes that programmers use can help you to successfully contribute to things like documentation. An exmaple is the Ubuntu Server Guide which is "programmed" in XML and whose development happens on Launchpad.

I guess I'm taking this a little farther than the Hour of Code which happens next week. I don't just want to contribute an hour to get kids into programming. Instead, I'd like to donate whatever time I need to help everyone find the resources they need to contribute code to open source projects. How can you refuse that offer?

Read and Post Comments

git your blog

So I deleted my whole website by accident.

Yep, it wasn't very fun. Luckily, Linode's Backup Service saved the day. Though they backup the whole machine, it was easy to restore to the linode, change the configuration to use the required partition as a block device, reboot, and then manually mount the block device. At that point, restoration was a cp away.

The reason why this all happened is because I was working on the final piece to my ideal blogging workflow: putting everything under version control.

The problem came when I tried to initialize my current web folder. I mean, it worked, and I could clone the repo on my computer, but I couldn't push. Worse yet, I got something scary back:

remote: error: refusing to update checked out branch: refs/heads/master
remote: error: By default, updating the current branch in a non-bare repository
remote: error: is denied, because it will make the index and work tree inconsistent
remote: error: with what you pushed, and will require 'git reset --hard' to match
remote: error: the work tree to HEAD.
remote: error:
remote: error: You can set 'receive.denyCurrentBranch' configuration variable to
remote: error: 'ignore' or 'warn' in the remote repository to allow pushing into
remote: error: its current branch; however, this is not recommended unless you
remote: error: arranged to update its work tree to match what you pushed in some
remote: error: other way.
remote: error:
remote: error: To squelch this message and still keep the default behaviour, set
remote: error: 'receive.denyCurrentBranch' configuration variable to 'refuse'.

So in the process of struggling with this back and forth between local and remote, I killed my files. Don't you usually panic when you get some long error message that doesn't make a darn bit of sense?

Yeah, well, I guess I kind of got the idea, but it wasn't entirely clear. The key point is that we're trying to push to a non-bare folder— i.e. one that includes all the tracked files— and it's on a main branch.

Why is this bad? Well, what if you had uncommited changes on the remote repo and you pushed changes from the local repo? Data loss. So Git now won't let you do it unless you specifically allow it in your remote config in the receive.denyCurrentBranch variable.

So let's move to the solution: don't do this. You should either push to a different branch and then manually merge on remote, but merges aren't always guaranteed. Why not do something entirely different? Something more proper.

First, start with the remote:

# important: make a new folder!
git init --bare ~/path/to/some/new/folder

Then local:

git clone user@server:path/to/the/aforementioned/folder
cd folder
# make some changes
git add -A
git commit -am "initial commit or whatever you want to say"
git push

If you check out what's in that folder on remote you'll find it has no tracked files. Basically, a bare repo is basically just an index. It's a place to pull and push to. You're not goinng to go there and start changing files and getting git all confused.

Now here's the magic part: in the hooks subfolder of your folder, create a new executable file called post-receive containing the following:

#!/usr/bin/env sh
export GIT_WORK_TREE=/path/to/your/final/live/folder
git checkout -f master
# add any other commands that need to happen to rebuild your site, e.g.:
# blogofile build

Assuming you've already committed some changes, go ahead and run it and check your website.

Pretty cool, huh? Well, it gets even better. Next push you do will automatically update your website for you. So now for me, an update to the website is just a local push away. No need to even login to the server anymore.

There are other solutions to this problem but this one seems to be the most consistent and easy.

Read and Post Comments