Wandering Thoughts archives

A modest idea on how to get people to use Fedora Rawhide

One of the things that comes up every so often is that the Fedora people would kind of like more people to use Rawhide, their rolling development version, so that it gets more testing and all of the problems don't suddenly come out of the woodwork when a new version of Fedora is released (or so I heard once upon a time; maybe they have enough testers now). Although I've written about this before, I've recently had a new modest idea on how to make a version of Rawhide that people are more likely to use.

Let's start from the premise that what people really want is 'new but (mostly) stable' or better yet 'new with only minor bugs'. I don't think that Fedora can possibly deliver this, not with any certainty, so our job is to fake it as best as possible with something that comes as close to Rawhide as possible.

Our new Rawhide-like thing (call it 'Cowhide') works like this. First, it is what I will call 'slightly cooked'; you should have assurances that packages in Cowhide do not break machines in obvious ways. They should at least install and survive in automated virtual machines, and the machine should have basic functionality afterwards. You should never be left with a machine that is unbootable, with its core networking dead, or the like.

(Rawhide may provide this today, I don't know.)

Next, it provides easy, on the spot rollbacks to previous package versions, well previous versions that you had installed. So that the Rawhide mirrors don't explode, these are saved locally (so people who use Cowhide will need some extra disk space for it). There is a simple administrative interface to roll back to a time-based package version snapshot, so you can say 'it worked two days ago, take me back'. This rollback system should work very hard to always work (no matter what packages think about being removed or reverted), and for obvious reasons there should be a non-graphical version too.

Testing this interface should always be part of the Cowhide basic smoke testing. If you can't rollback from a package update, the update does not make it into the Cowhide repository.

(Ideally there would also be a rescue CD based version of this rollback system, so that you had a chance of recovering even an unbootable system if that happened somehow.)

However, as I've covered earlier, it is very difficult or impossible to support package rollbacks in general. I can't expect Cowhide to solve this hard problem, so instead we'll cheat. Cowhide has markers for 'this package update cannot be rolled back from; it introduces a non-reversible change', and by default the Cowhide updater will not install these non-reversible packages until they are at least N days old and there are no open bugs filed against the package version, where N is some useful value (say ten days). You can continue to update 'around' such a package, ie it only freezes itself and anything that depends on it.

(A non-reversible package version would be marked as such by the package's maintainer. Hopefully the maintainer knows this sort of stuff about their package.)

This relies on there being adventurous people who will turn this feature off (or down a lot) and play with the latest packages; if there are problems, hopefully they will get noticed and filed soon enough to block the package updating for the less adventurous. Since there are people using Rawhide now, I think that there would be such people in a Cowhide world.

In short: Cowhide shouldn't ever outright break your system beyond recovery, and when stuff breaks it should be possible and usually easy to get back to a working system. Stuff will still break from time to time, but it's not that annoying to fix.

My view on Wayland replacing X in Linux

There has been a little bit of commotion lately about Wayland perhaps replacing X (see also). I'm not really happy, and why goes like this:

• odds of a full Wayland environment having an X compatibility layer: decent but nowhere near sure.
• odds of Wayland having remote window support on initial deployment: low.
• odds of Wayland supporting remote X the way it's done today: basically certain if it has X support at all.
• odds of there being a Wayland to X translator, so you can run native Wayland programs on an X server: you jest. Zero.

• odds of the Wayland X compatibility layer letting you run an X window manager as your (Wayland and X) window manager: you jest. Zero.
• odds of fvwm being ported to Wayland: probably basically zero.

So, Wayland means that I can look forward to throwing away a highly customized, highly tuned environment that I've been building up for a very long time; this environment is not the only reason I use Unix and Linux, but it's a good part of it. I don't like either the Gnome or the KDE environments, either their interfaces, the design choices that they've been making, or by and large their programs. And with Wayland, one of those two is likely to be my choice.

(My grumpy side says 'if I'm going to have to throw away my entire environment and start over from scratch in some 'modern' environment, why don't I just get a Mac and be done with the hassle?')

The other reason that Wayland makes me unhappy is that today we have a bunch of LTSPs and we're mandated to provide some sort of 'graphical computing on people's desks' solution. LTSPs are already chancy today and Wayland is likely to shoot them in the head as a practical solution even if it theoretically supports remote windows on the initial release, because I can confidently predict that all of the Wayland desktop environments will of course assume fast local graphics.

(Gnome and KDE almost do today; they are increasingly barely useful on LTSPs. Something built from the ground up to assume good support for various modern graphics-intensive operations is almost certainly going to be worse.)

PS: the Wayland FAQ makes Wayland out as a rather different and currently much modest project than the 'replacing X with Wayland' writeups that have been going around. In fact, the more I actually look at what Wayland is today, the less I understand people talking about replacing X with Wayland any time soon.

(Possibly this means I should remember something I once wrote.)

Sidebar: why I give these odds

X compatibility

On the plus side there's a lot of people jumping up and down for it; on the negative side it doesn't exist yet and once you do enough to run Gnome and KDE programs natively, the motivation drops off a lot. On the balance I'm cautiously optimistic but I don't think it's anywhere near assured.

(On good days I can construct arguments for why all popular distributions will require X support before they ship Wayland as their major environment.)

Native remote window support

It doesn't exist now. Is Ubuntu going to delay migration to Wayland because it's not implemented yet? No; almost no desktop user uses remote windows.

Remote X

Today basically everyone does X forwarding over ssh, and it would take real work to break this while having X support. Indeed I'm not sure that it would even be possible.

X window managers managing Wayland windows

X window managers need a lot of special (X) features not needed by most or any other X clients, on top of all of the problems of trying to support management of Wayland windows by an X program.

In general, I won't be surprised if we wind up with some Wayland window managers that look like current X window managers; however, I expect Wayland window management to be up sufficiently different from current X window management that you'd be implementing a new window manager based on ideas from current X ones instead of porting an X window manager.

(Given just how complex X window management has gotten to be over the years, I certainly hope that Wayland window management is drastically different and significantly better.)

Some yum tricks with distro-sync and --releasever

Suppose, not entirely hypothetically, that you have just upgraded your Fedora 13 workstation to Fedora 14 (with the latest updates) only to find out that your window manager now causes the X server to crash. Seeing as this renders the system unable to start your environment, you would like to find a solution by trying older versions of the X server.

As it happens, yum has added some interesting options since I last read through its manual page; in fact, I found out about --releasever and distro-sync from the Yum upgrade FAQ. Today I exploited them to downgrade packages the easy way, or at least what I thought of as the easy way.

(For details on both of these options, see the yum manpage. If your yum manpage doesn't cover them, you can't use them anyways.)

First off, I tried downgrading the X server to the original release version instead of the updated version:

yum --disable-repo updates distro-sync xorg-x11-server-Xorg

With the updates repository disabled, distro-sync will only see the base release version and will (if necessary) revert the package back to that version. I believe but haven't tested that 'yum downgrade' will do the same thing but in a simpler way.

(These two approaches wouldn't be quite the same if Fedora updates kept around more than one version of packages.)

When that didn't work, I decided that I wanted to revert all the way back to the latest Fedora 13 version of the X server (which I knew worked, because I had been running it):

yum --releasever=13 distro-sync xorg-x11-server-Xorg

I was actually kind of surprised that this worked, but it did. Normally one uses --releasever to go forward to the next distribution, but it works backwards too, and with the distribution set back to Fedora 13 distro-sync will thus downgrade the X server to the latest Fedora 13 version. I would definitely recommend running 'package-cleanup --problems' after doing this stunt.

(As it happened I needed to also revert a bunch of other X server related packages in order to get the Fedora 13 X server to not lock up. The result runs my window manager, though, and so I can now actually start my environment on Fedora 14 and be productive.)

As a side note, one reason that I latched on to distro-sync for doing this is that it was easy to reason about how it would behave. Given a specific repository configuration it was easy to see what the end result of distro-sync be; the only challenge was arranging the right repository configuration. (Of course this was made easier because what I wanted to do could be expressed this way; something like 'revert to the previous update version' would have been completely impossible.)

When Linux's rp_filter might make sense

I wrote a grumpy entry about net.ipv4.conf.*.rp_filter setting back here, where I said that it didn't make any sense. Well, I can actually come up with one situation where it may make sense: virtualization and thus virtualization networks.

One relatively common virtual machine setup is NAT-based, where the virtual machines get IP addresses on a private virtual network on the host. While the host doesn't route to its virtual network (or networks, if you have a big enough virtualization setup), it may be listening for various guest related services on its internal IP address. You don't want these services to be reachable from outside the machine; instead, you really do want the machine's private virtual network to be an isolated network. Using the rp_filter setting is the easy way to achieve this, and its drawbacks are irrelevant because the isolated network is both private and disconnected from any other real machine.

(Well. Most of the drawbacks. Interesting things may happen if your guest virtual machines try to talk to the real IP address of your host.)

While you can use ipfilters or policy based routing to achieve the same effects, both require you to know the IP addresses of some or everything involved; this means you need to generate the rules for your machine and update them when the machine's IP addresses or connectivity change. Using rp_filter is a lazy blunt hammer that gets you away from this.

However, I still believe that it's a mistake to default rp_filter to on. At least right now, I think that most users are not going to do virtualization and so the better approach (although it takes slightly more work) is to turn rp_filter on only when people configure virtualization.

(The counter-argument to this is that having rp_filter on all the time prevents the situation where you turn on virtualization and suddenly your networking explodes. Of course it does this by making your networking explode from the start, but you're more likely to notice that.)