At our school we have around 100 desktops, a vast majority of which run Fedora, and somewhere around 900 users. We switched from Windows to Fedora shortly after Fedora 8 was released and we’ve hit 8, 10, 13, 16, and 17 (deploying a local koji instance has made it easier to upgrade).

As I finished putting together our new Fedora 18 image, there were a few things I wanted to mention.

The Good

1. Offline updates: Traditionally, our systems automatically updated on shutdown. In the 16-17 releases, that became very fragile as any systemctl scriptlets in the updates would block because systemd was in the process of shutting down. Now, with systemd’s support for offline updates, we can download the updates on shutdown, reboot the computer, and install the updates in a minimal system environment. I’ve packaged my offline updater here.
2. btrfs snapshots: This isn’t new in Fedora 18, but, with the availability of offline updates, we’ve finally been able to take proper advantage of it. One problem we have is that we have impatient students who think the reset button is the best way to get access to a computer that’s in the middle of a large update. Now, if some genius reboots the computer while it’s updating, it reverts to its pre-update state, and then attempts the update again. If, on the other hand, the update fails due to a software fault, the computer reverts to its pre-update state and boots normally. Either way, the system won’t be the half-updated zombie that so many of my Fedora 17 desktops are.
3. dconf mandatory settings: Over the years we’ve moved from gconf to dconf, and I love the easy way that dconf allows us to set mandatory settings for Gnome. This continued working with only a small modification from Fedora 17 to Fedora 18, available here and here.
4. Javascript config for polkit: I love how flexible this is. We push out the same Fedora image to our school laptops, but the primary difference compared to the desktop is that we allow our laptop users to suspend, hibernate and shutdown their laptops, while our desktop users can’t do any of the above. What I would really like to do is have the JS config check for the existence of a file (say /etc/sysconfig/laptop), and do different things based on that, but I haven’t managed to work out how to do that yet. My first attempt is here.
5. systemd: This isn’t a new feature in 18, but systemd deserves a shout-out anyway. It does a great job of making my workstations boot quickly and has greatly simplified my initscripts. It’s so nice to be able to easily prevent the display manager from starting before we have mounted our network directories.
6. Gnome Shell: We actually started experimenting with Gnome Shell when it was first included in Fedora, and I switched to it as the default desktop in Fedora 13. As we’ve moved from 13 to 16, then 17, and now 18, it’s been a nice clean evolution for our users. When I first enabled Gnome Shell in our Fedora 13 test environment, the feedback from our students was very positive. “It doesn’t look like Windows 98 any more!” was the most common comment. As we’ve upgraded, our users have only become more happy with it.

The Bad

The bad in Fedora 18 mainly comes down to the one area where Linux in general, and Fedora specifically, is weak – being backwards-compatible. This was noticeable in two very specific places:

1. Javascript config for polkit: While I was impressed with the new javascript config’s flexibility, I was most definitely not impressed that my old pkla files were completely ignored. As a system administrator, I find it frustrating when I have to completely rewrite my configuration files because “now we have a better way”. I’ve read the blog post explaining the reasoning behind the switch to the JS config, but how hard would it have been to either keep the old pkla interpreter, or, if it was really desired, rewrite the pkla interpreter in javascript? The ironic part of this is that the “old” pkla configuration was itself a non-backwards-compatible change from the even older PolicyKit configuration a little less than four years ago.
2. dconf mandatory settings: With the version of dconf in Fedora 18, we now have the ability to have multiple user dconf databases. This is a great feature, but it requires a change in the format of the database profile files, which meant my database profile files from Fedora 17 no longer worked correctly. In fact, they caused gnome-settings-daemon to crash, which crashed Gnome and left users unable to log in. Oops. To be fair, this was a far less annoying change because I only had to change a couple of lines, but I’m still not impressed that dconf couldn’t just read my old db profile files.

As a developer, I totally understand the “I have a better way” mindset, but I think backwards compatibility is still vital. That’s why I love rsync and systemd, but have very little time for unison (three different versions in the Fedora repositories because newer versions don’t speak the same language as older versions).

I know some people will say, “If you want stability, just use RHEL.” That’s fine, but I’m not necessarily looking for stability. I like the rate of change in Fedora. What I dislike is when things break because someone wanted to do something different.

All in all, I’ve been really happy with Fedora as our school’s primary OS, and each new release’s features only make me happier. Now I need to go fix a regression in yum-presto that popped up because of some changes we made because we wanted to do something different.

As mentioned in this post, I have an HP Veer cell phone that I bought last year when we were in the States on furlough. Despite (or maybe because of) a 2.6″ display and tiny keyboard, I’ve found it a joy to use, but its operating system, WebOS has one major drawback. Apps-wise, it’s dying.

My wife has an LG P500 with half the Veer’s RAM, a fraction of its flash, an ICS ROM that the good fellows over at AOKP have managed to hack together, and an up-to-date version of Skype, Whatsapp and any other app she desires. I, on the other hand, have a version of Skype that doesn’t log in unless I reset my user information, an impressive but buggy implementation of Whatsapp that seems to suck the ole’ power out of my phone, and a small list of apps that’s slowly but surely shrinking.

Over the Christmas holidays, I thought I would see what it would take to get some form of Android on this phone. There seem to have been a couple of attempts, but no source code that I could find, which brings me to my first complaint.

<rant>

What is up with Android ROM developers who take thousands of man-hours of somebody else’s work, add a few hours of their own, and then act as if they’ve invented the wheel and they need to keep it top secret? Maybe it’s the fact that I’m coming from the Fedora community where the concept of working as a team is an ideal even if it doesn’t always happen in fact, but the isolationist attitude I see in the different Android communities is quite depressing. I believe it’s one of the main reasons that participants in the Android community can be quite harsh with each other, much harsher on average than I see in the Fedora community.

</rant>

So I go to AOSP, download the platform and build it with no problems. Yay! Then I need to get the kernel source. From where? I start with https://android.googlesource.com/kernel/msm.git. There are four branches, three which are supposedly 3.0 or 3.4 JB kernels. And I can’t compile any of them. Some of the problems are configuration issues (the config.gz from WebOS’s 2.6.25 kernel is only a starting point), but there are also simple typos that are preventing compilation. Not exactly confidence-inspiring.

I decide to check out Cyanogenmod’s kernel, but it looks like it hasn’t been touched in forever. A closer look at Cyanogenmod’s github repository shows 10… no 20… no a hundred kernel forks for various devices? And all this brings me to my second major complaint.

<rant>

Why on earth do we need a different kernel fork for each device? All I want to do is build straight from kernel.org. Is that so wrong? When will the forking stop?

</rant>

Seriously, though, forking the Linux kernel to build it for your device seems a bit overkill, but it’s par for the course for the Android community. Is there any way to get this stuff back upstream? Or at the very least, could AOSP (or possibly Cyanogenmod) use one “official” kernel tree with patches sent back from these forks?

Anyhow, now I’m off to see if I can get one of the Cyanogenmod kernel forks to build. I’m sure I saw one in there for a msm7x30 chipset. Maybe I’d be better off just waiting until I can get a Nexus 4. Happy new year, everyone!

Edit: A couple of weeks ago, I got a Samsung Galaxy S3 Mini, as they are available and cheaper here in Lebanon than in the States. It may not be the best phone out there, but it’s a great size and easily does everything I need. Goodbye WebOS. It was nice knowing you.