So what is the number one shortcoming of most major desktop distro’s today ? In my opinion it’s none of the things we all remember, heck even *buntu has control centers of a sort now (so there goes one of my favorite rants – always nice to find improvements).
Well I think it’s a massive oversight. In a world where GNU/Linux systems have hardware setups that are comparable and in fact often much easier than our proprietory counterparts, one thing has changed and we have sucked at keeping up. The change ? Five years ago a tiny minority of advanced computer users had more than one computer screen, people who weren’t afraid to tweak config files, and there was one howto to read since there was really only one technology for it, except for the nvidious users but they were used to having weird setups anyway.
The only GUI tool that had any idea how to set up multidisplay setups were SAX2 and that was because as X auto-configuration got smarter and smarter – less and less developers cared about creating better tools for modifying it. But it wasn’t a crisis then.
Today, I would bet that a good 30% at least of all desktop systems and probably 95% of laptops deal with multidisplay use every single day ! The autoconfigurations pretty much always set them up cloned. Now this is in my opinion stupid since it is probably the least used configuration you find these days. It made sense five years ago when people used a big freestanding screen and a docking station to turn a laptop temporarily into a desktop. These days, we want the screen real-estate of both monitors – even on docking stations.
Cloning as a use-case is shrinking, and others are getting harder and hard to set up ! As if the usefullness of cloning wasn’t already losing out to bigger screen-space, it faces the further challenge that in most multiscreen setups the monitors have different ideal frequencies, cloning means you either stick to what the worst of them supports, or you accept half your image falling of the screen on one side.
And multidisplay setups have become far more complex to do. Nowadays you have at least three different types of multidisplay technologies out there. The first and worst is Nvidia’s twinview, while very powerful in it’s time, twinview breaks every other standard and it’s xinerama compatibility is flakey – so every now and then, you get massive breakage (NWN for example – will choose the smallest of the two screens as res, then go and sit smack in the middle, panning across both to make an unusuable setup for playing the game).
Xinerama is the old favorite, but many cards like nvidia don’t play well with it and it’s multiple screen entries in xorg.conf setup is pretty much impossible to autoconfigure right (I have never seen an autoconfig with this setup that didn’t create a sucky setup – you always have to tweak it). It’s complex to set up and doesn’t allow you to take advantage of the full featureset of your card.
In theory there is light at the end of the tunnel in the form of XRANDR1.2 which provides really nice ways to manipulate screen setups on the fly. You can set up cloning, rotations etc. – really cool. Only problem is, right now the only cards that actually support it are some of the higher end intel drivers. If you install nouveau you get the support for it on nvidia, but nothing else really works and nouveau won’t be production ready for a while yet. Nothing else can use the full feature-set.
Think it’s rough so far ? It gets worse, both major desktops have tools to act as GUI’s to the XRANDR commands, both of them suck. I have yet to manage to get them to set up anything other than a broken clone setup. The buttons are there for others, they just don’t work – and don’t even tell you why. The problem being that XRANDR multisetups depend on defining a virtual screen size, and neither of them can do the simple addition that is needed to actually allow the second screen to be moved ! I have full XRANDR1.2 support on my laptop – and I opted for configuring XRANDR with my xorg.conf file rather than to deal with the pain of trying to somehow coax krandrtray into working.
The final problem is that neither of the desktop’s included XRANDR frontend can save the changes permanently (e.g. into xorg.conf), to keep them, you have to set the frontend to autostart with the desktop – and if you ever log into a different session, bang goes your display setup until return to your usual one.

In short, it’s a mess. Is there any good news ? Well SAX2 is still under development and still pretty lonely in the one distro that includes it because nobody else seems to take the problem seriously. The support for xrand1.2 is not fully feature-complete yet but getting there, and unlike the others it is actually designed to set up your xorg.conf file for almost any advanced use-case with a click-and-drag interface. The only gripe I have against it is that current version can only compiled against QT3, but that will hopefully be changing in the near future. So what is the question ?Where do we go from here ? If we put our money on xrandr1.2 then the distro’s need to offer some resources to get the GUI’s up-to-scratch for it. For everybody who cannot use it and won’t be able to for some time – we need to offer easy ways to do what is becoming a more common use-case every single day, SAX2 is the closest to a solution that exists, and I think other distro’s should adopt it, whether on a permanent or temporary stop-gap basis is really rather unimportant. The important thing is dealing with the problem in front of us right now.

So I was a bit slow in trying git out for myself, I’ve occasionally done git checkouts of code that I wanted to try out but I had never tried to do any repo work with it. However after much discussion we chose git as the repo system for kongoni ports because it has features that works really well in that realm – and so it came that I had to set up my first git repos.
I spent a few hours today studying how git works and within a short while I could set up a really nice system for kongoni. Gitosis made setting up secure repos’ for the developers easy and quick, and then the fact that every git copy is also a repo became really powerful.
A simple script I wrote can take the git repos daily and clone them into the webserver for read-only repos that can actually be used by users, and since git checkouts are fully standing repos, these can be mirrored over rsync and kongoni users can sync their ports tree from any of the mirrors while still having full access to the version-controlled, incrementally changing ports tree as created by us.
Another advantage is that since there is in fact two repos (one where we work and one read-only where users check out from) with a delay between them, if a mistake creeps in and we can fix it the same day it will never even be seen by users.
Git’s concept of distributed version control is weird at first if you’re used to the svn/cvs approach of centralized version control but once you get it… it’s actually an awesome way of working that really ties in well with both the free software and open source ideals.
I wasn’t the one who proposed it for the ports, that credit belongs to Marius but I can see why it got such support, now I started working with it, I’m completely sold and I’ve not even explored half it’s features.

Question: What is annoying ?
Answer: When you finish a three month project, and as you are running the final build your PSU blows.
Question: what is more annoying than that ?
Answer: If the reason it blew is that the new CPU you bought 2 weeks ago needs a more powerful PSU.
Question: And what is even more annoying than that ?
Answer: If you actually had the hardware supplier install the new CPU and mobo to avoid any difficulties, and they didn’t notice that you would need a PSU upgrade, which if they had told you then would have saved 3 days of downtime.