My Writings. My Thoughts.
I’ve been really quiet on the blogging front the last few months. There’s been a lot happening in my life. In short, I moved back to South Africa and started working for another company. I have around 10 blog drafts that I will probably never finish, so I’m just declaring post bankruptcy and starting from scratch (who wants read my old notes from Ubuntu VUDS from March anyway?)
For what it’s worth, I’m still alive and doing very well, possibly better than ever. Over the next few months I want to focus my free software time on the Edubuntu project, my Debian ITPs (which I’ve neglected so badly they’ve been turned into RFPs) and Flashback. Once I’ve caught up there’s plenty of other projects where I’d like to focus some energy as well (LTSP, Debian-Edu, just to name a few).
Thanks for reading! More updates coming soon.
The death of Gnome Panel
Gnome Panel (or more properly, gnome-panel) is the main dock that you would see in the Gnome 2 series desktop, and in the Gnome Fallback session (also called Gnome “Classic” in many distributions) in Gnome 3.
To provide the typical desktop experience, it’s also accompanied by Nautilus and Metacity along with a few other libraries (hence forth, gnome-panel’s friends). Gnome Panel and friends have recently been deprecated so that developers have more time to focus on Gnome Shell, the new default shell for Gnome that has a vastly simplified (and better) technology stack. Last November, Vincent Untz announced that he would stop maintaining Gnome Panel and friends beyond the 3.6 release, which means the death for it unless anyone else takes it up.
I’ve been an avid user of the Gnome 2.x series and also Gnome Fallback in the 3.x series. I’ve gotten rather good at supporting it too. We include it by default in Edubuntu, and even have an option in the installer to make it the default for installations over Unity. It provides a low-footprint, fast and simple desktop experience with very reasonable usability, while being very configurable and lockdownable. (my spell check says that’s not a word, but I don’t care).
I’ve been considering whether we should switch to having Xfce or LXDE as an alternative to Unity, but after discussing it with other Edubuntu contributors, it became clear that if I wanted to do that, I’d have to be willing to maintain it for Edubuntu by myself. In Edubuntu we’ve been pretty good at having at least 2 people being interested in any side-project we pick up and I like to keep it that way if we can. It means that if someone gets a bit busy, there’s someone who can pick up the slack for a little while. Also, Xfce and LXDE had big holes in usability, especially when it came to things like having multiple displays and running on laptops. I decided to put that project on the backburner a little since Ubuntu 13.04 will still be using Gnome 3.6, which meant that we’d have the Fallback session for one more release anyway.
The Inevitable Fork
Ikey Doherty forked off Gnome Panel to create a new environment called Consort. Metacity is forked to become Consortium. The website where the Consort desktop environment used to live seems gone now, but here’s a link to some screenshots from Google+.
This caused a bit of a stir, Vincent Untz posted a good chronology of what lead up to it and why he believes that a fork is a bad idea when the Gnome project has effectively put the upstream code up for adoption.
I’ve been interested in the Consort family since it could potentially be something that we could use in Edubuntu once the upstream gnome-panel is no longer in the archives. Also, while Gnome Shell, KDE Plasma Desktop and Unity are great and have come incredibly far in terms of stability and performance, it’s just not always for me. I want to be able to use it for myself in virtual machines, older machines and some other special cases (most notably, on LTSP).
Josselin Mouette, maintainer of Gnome in Debian, approached Ikey after some requests have been made for it in Debian. If you’ve read the post and the IRC logs linked, then you’ll probably agree that it could’ve gone a lot better. I’m not on the SolusOS IRC channel so only saw the conversation after the fact, but I was disappointing since it would need to go into Debian if I’d want to support it in Edubuntu. I think both Josselin and Ikey could’ve handled it better, but humans are just that and emotions and misunderstandings happen.
And so I Bite
I was chewing a bit on Josselin’s comment on how the former maintainer “maintainer decided to give the key to anyone who wanted to” and it’s been several weeks since Vincent invited people to take over maintainership. I decided that I’d at least be willing to do the absolute minimum just to keep the project releasable every six months so that it can be included in distributions, maintain its online presence pages, bug tracker status and keep up with component changes in the stack. So I e-mailed Vincent and explained what I’m willing to do. I had very little resistance, Vincent sent an email out to other people who are steakholders in the gnome-panel project and after a week, there were no objections. So here I am, brand new maintainer of the Gnome Fallback session and its components!
This means that the project is, at least for now, alive again. It’s not going to be part of the official Gnome 3.8 release (I still have to figure out exactly what that means), but there will be a 3.8 release of Gnome Panel and friends as tarballs and for people who maintain it in distributions, things will continue to work exactly as it did before.
- My complete primary goal for this at the moment is to ensure that gnome-panel, metacity, etc is releasable alongside the Gnome 3.8 release. This basically means making sure it builds, including any patches that we can and releasing.
- Do something about the long buglist. The Gnome bug tracker has an ugly long list of gnome-panel bugs (939 at my last count). I want to eliminate all the stale Gnome 2.x gnome-panel bugs of which a very large amount of them are no longer relevant (at least on first glance). Then I’d like to do some regular posts to the mailing list and blog about a few prominent bugs every now and again and try to fix them and get people involved.
- Porting Metacity to GTK3. So here’s a bit of really good news. Josselin is also involved with this and one of his mid-term goals is to port metacity to gtk3. It’s something that I know would have to happen, but I don’t have the skills to do that (yet) and I’m glad that he has took this up. Josselin’s mid-term goals also include possibly adding support for the new notification system (if necessary) and adding support for the new Gnome global menu.
- Create a nice project page with goals and to-do list, who’s envolved and what they’re doing and encourage more people to get involved. The current page is rather outdated so it would be nice to fix it. For now that mostly involved bringing the Gnome Panel Gnome Wiki page up to date.
- My pet peeve… intelligent launcher icons. Windows 7, Mac OS X, KDE, Unity and Gnome Shell have docks that work very similarly in many ways. You click on a launcher and those same launcher entries are recycled as your window list. Gnome Panel is a bit old fashioned in this regard. Many people use 3rd party panels and launchers just to get around this. I have thought for a long time that this should be fixed in Gnome Panel and long-term, it’s something that I’d like to see happen.
- Make the stack as downstream-friendly as possible. Regarding Ikey and Consort, I don’t actually think it was a completely horrible idea at the time. We live in a free world where we use free software and anyone is allowed to do whatever they want and fork whenever they want, and while that doesn’t necessarilly mean it’s a good idea, it also doesn’t mean that we need to get all hissy about it. I’d actually be very interested in working with people who want to fork and find out why they want to fork and try to reel them in closer to upstream. In the case of Consort, I think it would be most beneficial for both projects and all their users if Consort was a branch of Gnome Fallback, rather than a fork. Both projects use Git, FFS. I’ll reach out and try to minimize duplication of effort while not blocking anyone on experimenting with new features or implementing distro-specific changes.
- More metacity features. Metacity’s compositing features have come quite a long way, there are still a few bugs that need to be sorted out, but more than that, there are many window manager features that users have become accustomed to in pretty much all the other environments. Ikey has indicated previously that he wants to do this for consortium. It’s one of the reaons I’ll be super-nice to him because I’d really prefer that he submit as much of that upstream as possible.
- Make everything worth configurable and lockdownable. There are some settings that I get requests from from the users I support so often that it’s just getting boring. The Gnome 2.x series proved to work well in educational and corporate environments. I say we should play on that strength and make it even more so, while sticking 100% with the Gnome Human Interface Guidelines, of course.
Very Long-term Goals
Well, the fact is, Gnome Fallback will die. There’s a new project called Gnome Legacy, it implements a Gnome 2.x-like experience in Gnome 3. As time goes by, older machines become more powerful and the missing pieces will be implemented and eventually there would be no more good reason for anyone to want to run what we now know as Gnome Fallback. I think it could still have a good 3-5 years or maybe even more in it. Who knows, by then Gnome 4 might even be in development and all of this will be ancient history.
So, my very quick “Eek, I’m now maintainer of Gnome Panel!” post has become quite lengthy post, if you have any questions, I’ll respond to it in the comments.
The War on Time
Whoosh! I’ve been incredibly quiet on my blog for the last 2-3 months. It’s been a crazy time but I’ll catch up and explain everything over the next few entries.
Firstly, I’d like to get out a few details about the last Ubuntu Developer Summit that took place in Copenhagen, Denmark in October. I’m usually really good at getting my blog post out by the end of UDS or a day or two after, but this time it just flew by so incredibly fast for me that I couldn’t keep up. It was a bit shorter than usual at 4 days, as apposed to the usual 5. The reason I heard for that was that people commented in previous post-UDS surveys that 5 days were too long, which is especially understandable for Canonical staff who are often in sprints (away from home) for the week before the UDS as well. I think the shorter period works well, it might need a bit more fine-tuning, I think the summary session at the end wasn’t that useful because, like me, there wasn’t enough time for people to process the vast amount of data generated during UDS and give nice summaries on it. Overall, it was a great get-together of people who care about Ubuntu and also many areas of interest outside of Ubuntu.
I didn’t take many photos this UDS, my camera is broken and only takes blurry pics (not my fault I swear!). So I just ended up taking a few pictures with my phone. Go tag yourself on Google+ if you were there. One of the first interesting things I saw when arriving in Copenhagen was the hotel we stayed in. The origami-like design reminded me of the design of the Quantal Quetzel logo that is used for the current stable Ubuntu release.
The Road ahead for Edubuntu to 14.04 and beyond
This release will mostly focus on the Edubuntu Server aspect. If everything works out, you will be able to use the standard Edubuntu DVD to also install an Edubuntu Server system that will act as a Linux container host as well as an Active Directory compatible directory server using Samba 4. The catch with Samba 4 is that it doesn’t have many administration tools for Linux yet. Stéphane has started work on a web interface for Edubuntu server that looks quite nice already. I’m supposed to do some CSS work on it, but I have to say it looks really nice already, it’s based on the MAAS service theme and Stéphane did some colour changes and fixes on it already.
From the Edubuntu installer, you’ll be able to choose whether this machine should act as a domain server, or whether you would like to join an existing domain. Since Edubuntu Server is highly compatible with Microsoft Active Directory, the installer will connect to it regardless of whether it’s a Windows Domain or Edubuntu Domain. This should make it really easy for administrators in schools with mixed environments and where complete infrastructure migrations are planned.
You will be able to connect to the same domain whether you’re using Edubuntu on thin clients, desktops or tablets and everything is controllable using the Epoptes administration tool.
Many people are asking whether this is planned for Ubuntu / Ubuntu Server as well, since this could be incredibly useful in other organisations who have a domain infrastructure. It’s currently meant to be easily rebrandable and the aim is to have it available as a general solution for Ubuntu once all the pieces work together.
Empowering Ubuntu Flavours
This cycle, Ubuntu is making some changes to the release schedule. One of the biggest changes made this cycle is that the alpha and beta releases are being dropped for the main Ubunut product. This session was about establishing how much divergence and changes the Ubuntu Flavours (Ubuntu Studio, Mythbuntu, Kubuntu, Lubuntu and Edubuntu) could have from the main release cycle. Edubuntu and Kubuntu decided to be a bit more conservative and maintain the snapshot releases. For Edubuntu it has certainly helped so far in identifying and finding some early bugs and I’m already glad that we did that. Mythbuntu is also a notable exception since it will now only do LTS releases. We’re tempted to change Edubuntu’s official policy that the LTS releases are the main releases and treat the releases in between more like technology previews for the next LTS. It’s already not such a far stretch from the truth, but we’ll need to properly review and communicate that at some point.
Valve at UDS and Steam for Linux
One of the first plenaries was from Valve where Drew Bliss talked about Steam on Linux. Steam is one of the most popular publishing and distribution systems for games and up until recently it has only been available on Windows and Mac. Valve (the company behind Steam and many popular games such as Half Life and Portal) are actively working on porting games to run natively on Linux as well.
Some people have asked me what I think about it, since the system is essentially using a free software platform to promote a lot of non-free software. My views on this is pretty simple, I think it’s an overwhelmingly good thing for Linux desktop adoption and it’s been proven to be a good thing for people who don’t even play games. Since the announcement from Valve, Nvidia has already doubled perfomance in many cases for its Linux drivers. AMD, who have been slacking on Linux support the last few years have beefed up their support drastically with the announcement of new drivers that were released earlier this month. This new collection of AMD drivers also adds support for a range of cards where the drivers were completely discontinued, giving new life to many older laptops and machines which would be destined for the dumpster otherwise. This benefits not only gamers, but everyone from an average office worker who wants snappy office suite performance and fast web browsing to designers who work with graphics, videos and computer aided design.
Also, it means that many home users who prefer Linux-based systems would no longer need to dual-boot to Windows or OS X for their games. While Steam will actively be promoting non-free software, it more than makes up for that by the enablement it does for the free software eco-system. I think anyone who disagrees with that is somewhat of a purist and should be more willing to make compromises in order to make progress.
Ubuntu Release Changes
Last week, there was a lot of media noise stating that Ubuntu will no longer do releases and will become a rolling release except for the LTS releases. This is certainly not the case, at least not any time soon. One meme that I’ve noticed increasingly over the last UDSs was that there’s an increasing desire to improve the LTS releases and using the usual Ubuntu releases more and more for experimentation purposes.
I think there’s more and more consensus that the current 6 month cycle isn’t really optimal and that there must be a better way to get Ubuntu to the masses, it’s just the details of what the better way is that leaves a lot to be figured out. There’s a desire between developers to provide better support (better SRUs and backports) for the LTS releases to make it easier for people to stick with it and still have access to new features and hardware support. Having less versions between LTS releases will certainly make that easier. In my opinion it will probably take at least another 2 cycles worth of looking at all the factors from different angles and getting feedback from all the stakeholders before a good plan will have formed for the future of Ubuntu releases. I’m glad to see that there is so much enthusiastic discussion around this and I’m eager to see how Ubuntu’s releases will continue to evolve.
Lightning talks are a lot like punk-rock songs. When it’s good, it’s really, really amazingly good and fun. When it’s bad, at least it will be over soon :)
Unfortunately, since it’s been a few months since the UDS, I can’t remember all the details of the lightning talks, but one thing that I find worth mentioning is that they’re not just awesome for the topic they aim to produce (for example, the one lightning talks session I attended was on the topic of “Tests in your software”), but since they are more demo-like than presentation-like, you get to learn a lot of neat tricks and cool things that you didn’t know before. Every few minutes someone would do something and I’d hear someone say something like “Awesome! I didn’t know you could do that with apt-daemon!”. It’s fun and educational and I hope lightning talks will continue to be a tradition at future UDSs.
Stefano Rivera (fellow MOTU, Debianista, Capetonian, Clugger) wins the prize for person I’ve seen in the most countries in one year. In 2012, I saw him in Cape Town for Scaleconf, Managua during Debconf, Oakland for a previous UDS and Copenhagen for this UDS. Sometimes when I look at silly little statistics like that I realise what a great adventure the year was!
Between the meet ‘n’ greet, an evening of lightning talks and the closing party (which was viking themed and pretty awesome) there was just one free evening left. I used it to gather with the Debian folk who were at UDS. It was great to see how many Debian people were attending, I think we had around a dozen or so people at the dinner and there were even more who couldn’t make it since they work for Canonical or Linaro and had to attend team dinners the same evening. It was as usual, great to put some more faces to names and get to know some people better.
It was also great to have a UDS with many strong technical community folk present who is willing to engage in discussion. There were still a few people who felt missing but it was less than at some previous UDSs.
I also discovered my face on a few puzzles! They were a *great* idea, I saw a few people come and go to work on them during the week, they seem to have acted as good menial activities for people to fix their brains when they got fried during sessions :)
Overall, this was a good and punchy UDS. I’ll probably not make the next one in Oakland due to many changes in my life currently taking place (although I will remotely participate), but will probably make the one later this year, especially if it’s in Europe. I’ll also make a point of live-blogging a bit more, it’s just so hard remembering all the details a few months after the fact. Thanks to everyone who contributed their piece in making it a great week!
Last weekend I was in Southwest Harbour, Maine again for the annual LTSP hackfest (called By The Sea). It’s a fun and productive event and as always it’s been good catching up with LTSP folk, even though we were missing Oliver, Alkis and Vagrant.
Here is a summary of what I can recall from the discussions of the weekend…
Recent Happenings in LTSP
- New LTSP Website – After a really long time, LTSP finally has a new website. It’s a big improvement, there’s a new success stories page and the wiki is now self-hosted.
- LTSP PNP - This is a new package (ltsp-pnp) that can safely be installed on existing machines to allow a user to log into an LTSP server using LDM.
- Libpamssh - This has been ongoing work in the LTSP project that will allow you to authenticate against another machine using SSH with local PAM. This will make it somewhat trivial to adapt LightDM (Light Display Manager) as a remote login manager and we can then do away with LDM (LTSP Display Manager) which currently has several big limitations. Scott Balneaves and Stéphane Graber made big progress on this over the weekend and it’s close to an initial release.
- New LTSP Cluster Control Center - Simon Poirier has been working on a new LTSP Cluster Control Center, the old one has been rusting away and other attempts at rewriting it didn’t quite work out. He did a demonstration of the proof-of-concept code and it’s looking quite nice already.
- Squashed Bugs - Marc Gariépy took some time to squash some bugs: LP: #996533, LP: #1048689 and LP: #1062947
- Documentation - I’m taking it upon myself to fix some problems we have with documentation. The lts.conf documentation is incomplete and difficult to maintain, so I will be going through the client/server code and tag all the possible settings that there are so that we can auto-generate documentation from it. David Trask will be helping out there and will be writing some nice descriptions for the config settings.
- LTSP 6.0 and the Future of LTSP - There was a good opening discussion about the future of LTSP. The combination of all the recent partial rewrites that Alkis has been doing combined with the deprecation of LDM will culminate in what will be called LTSP 6.0. There was also some interest in having an LTSP standalone distribution again (that can be installed on none-integrated distributions) and things like an LTSP live client disc. We were also wondering about the future of pure thin clients, many upstreams are writing software that aren’t at all thin client friendly (Clutter-based software like Gnome Shell and Totem, Unity, etc) and at the same time, thin client hardware is becoming increasingly powerful. It’s possible that there may be a focus on making diskless fat clients working even better with LTSP and make it easier to use remote-apps for running only certain applications the application servers. We’re also quite interested in projects like FreeRDP for users who would still require pure thin clients.
- On Friday, Chuck Liebow took us out for a boat ride around the harbour on the Sea Princess
- On Saturday night we had the big lobster dinner as per BTS tradition (I had steak since I’m not a big seafood person). We were to busy eating and telling stories to be taking any pictures :)
- And last but certainly not least, I finally met Eric Harrisson, who did a lot of work on K12-LTSP in the Portland schools district. He has an awesome hobby where he builds guitars out of… well, almost anything he can find.
He brought along one of the experimental guitars he slapped together recently and told me all about how it’s put together. Even more amazing, he said I could have it! I was planning on getting an acoustic guitar anyway so I’m very thrilled about it. Not only is it a completely unique guitar but it sounds great too. I’m going to have to think of something to make back for him!
It was great seeing everyone again. I first started using LTSP around 9 years ago and never imagined back then that I’d get to meet the people behind it. Ron Colcernian sourced us some really cool LTSP tops that you can see us wearing in the group photo. I hope to get to BTS again next year!
My foray into the world of LXC and RLXC
A few months ago, I started trying out LXC (Linux Containers). Before that I used to use OpenVZ, which is an older and more mature contextualization implementation. I was pleased with how well LXC worked and started replacing my personal OpenVZ hosts with LXC.
It worked great, but it had a few quirks. While LXC itself works well, the user scripts that ship with it has some space for improvement. The lxc-list command lists anything that’s a directory in /var/lib/lxc, so if you have a lost+found directory, it will list it as a container (This has since been fixed upstream). Also, in some cases it would list containers twice or not at all. I was a bit annoyed with that, since OpenVZ’s “vzlist” tool prints out a nice table of your containers along with their IP addresses and other information. Since it’s very trivial to implement what I want in a shell script, I went ahead and did just that and called it RLXC.
I also missed the “vzctl exec <containername> command” to execute commands in containers and “vzctl enter <containername>” to gain a shell inside the container, so I added some more functionality to it so that I could configure ssh keys for these containers and use “rlxc enter” and “rlxc exec” like I used to do with the OpenVZ tools, but by using SSH.
I also realised that there are others too who wanted similar improvements in the LXC scripts and decided to continue improving RLXC and making it public.
I spoke to Stéphane about my ideas at the time and he introduced me to python3-lxc that he introduced on his blog yesterday. It provides Python bindings for liblxc, so I took the advantage of that and mostly re-implemented RLXC in Python and called it LLXC. The name doesn’t particularly mean anything, I’m open to suggestions for what to call it, if anyone cares.
Here are some screenshots that explains some of it better than I could do in words:
How to get it
As Stéphane mentioned in the python3-lxc blog entry, the API hasn’t yet been finalized and llxc itself is in an early state and many changes are planned, so it’s definitely not meant for production use yet, but since we believe in “release early, release often” in the free software community, here goes…
Currently, llxc.py itself is *very* Ubuntu specific and its only been tested on Ubuntu 12.04, but that will be fixed once more of its kinks have been ironed out. Some people are also working on getting python3-lxc on other distributions, which will help a lot.
The llxc.py script itself is hosted on Github: https://github.com/highvoltage/llxc
For python3-lxc and friends, you need to enable Stéphane’s experimental PPA: https://launchpad.net/~stgraber/+archive/experimental
You will then need to install the following packages: lxc, python3-lxc, python3-crypto, lvm, btrfs-tools
To generate the ssh keys used for ssh interaction between the containers, you need to run “llxc gensshkeys”. The “enter” and “exec” commands also rely on your containers being in dns or in your /etc/hosts file, at least for now, which you may have to configure manually.
There is a lot that I’m planning to add, mostly to scratch my own itches. These include:
- Awareness of other hosts, so that the list command can show you all containers in the “awareness”. You’d also be able to clone, move, etc containers between hosts.
- Easily modify container configuration
- Hooks everywhere, and at least one hook for configuring a configuration management system such as salt, bcfg2, puppet or chef.
- More checks and tips everywhere. Is the host running low on memory? Disk space? Perhaps list available resources on variable hosts and make some suggestions based on that.
- There a not-very-descriptive ROADMAP file in the distribution, check that for more details.
I’ll have some packaging for this available soon and work on making more things work right out of the box, updates will follow. Also, feedback and patches are very welcome!
If there’s one thing that I’ve had missing in my life for way too long, it’s hacking on small silly stupid amusing little things. When I was young I used to write dozens of little pointless programs a week and forget about them, only to found them a few months later and be incredibly amused by them.
This afternoon I noticed that one of my machines didn’t have my default .bashrc loaded, which colourises (or ‘colorizes’ for Americans or ‘colourizes’ for Canadians) my shell so that I know on which machine I am so that I don’t accidentally do something silly like reboot the wrong host. One problem I’ve had with this is that there are limited colours available that makes sense to use for a shell prompt. Right as I was thinking this, I was looking at my Byobu screen sessions and thinking “Hmm! I like those logos, maybe I could use them in my shell!”.
So in just a few minutes I had a little script to help you configure those for your shell. Here is a screenshot of the shell logos in action. On my laptop I use a red background when I have a root shell:
This is what the shello script looks like that sets it up:
I might get bored by seeing it soon and get rid of it, but at least I had a little fun with it.
If you’d like to try it out, then you can get the script right here: https://github.com/highvoltage/shello
It doesn’t do anything like validating input yet, I’d also like to add something that creates some kind of a checksum of your hostname and choose a unicode character based on that. Maybe I’ll finish it up this weekend, or maybe I’ll have new things to write about!
When the Joy theme was picked as the chosen theme for Debian 7.0 (Wheezy), I wanted to do what I could to get as much of it in the archive as possible before the freeze that occurred in June. I’ve been working with Paul Tagliamonte and Vagrant Cascadian and I’m glad that it resulted in some nice things!
The Joy theme is modest and beautiful and I think Debian 7.0 is going to be one of the best looking Debian releases so far.
Joy Plymouth Theme
Plymouth is the part that provides the boot splash. It also takes care of a few other things, like showing prompts and progress indicators for filesystem checks, password prompts for encrypted devices and more so that the splash doesn’t need to exit to show those. It’s very scriptable, The installers for the Genesi Efika range of devices even use it for it’s front-end.
I needed to start with a Plymouth theme where I knew the prompts for all the things that happen during boot was at least more or less implemented, so I started off with one that I know works well, the Edubuntu one. So, fun fact: Debian 7.0′s Plymouth theme is actually based on the Edubuntu one.
I had to play with the colours a bit to get it right, Edubuntu has a light background so I had to invert contrast for things like the input box, but I think it came out nicely.
Splashy isn’t in the archives anymore and it’s not widely used anymore, so I cleaned it up from the desktop-base package so that there’s less clutter shipped with it.
Joy LTSP/LDM Theme
This screenshot actually looks a bit uglier than it should because I took it on a VM that doesn’t have 24bit colour, but we’re looking into what we can do to make it look better on 16bit colour as well.
During Debconf in Nigaragua, Vagrant and I worked on getting the LDM theme in shape. I have already done what I thought was most of the work by the time Debconf started, but it turns out there was a lot more to it to do it properly. We managed to get rid of the gtk2-engines-murrine dependency, which in itself is quite tiny, but it’s a bit backwards in that it depends on the whole rest of the murrine-themes which brings in too much. We took the time to get the dependencies/recommends/etc right and to make it the default theme in Debian without messing it up for any Debian derivatives. It all came together and now when you install LTSP on Debian, you get the Joy theme by default! I’m really glad about that because I didn’t get the Spacefun LDM theme done in time for the Squeeze release. Enjoy!