Archive for the ‘Ubuntu’ Category
Yesterday was my 21st birthday, and I received all “Hitchhiker’s Guide to the Galaxy” novels, the five ones in one book, and the sixth one written by Eoin Colfer in another book. Needless to say, the first book weights more than an N900. I did not read them yet, so now is the perfect chance to do so. Yes, I did not know that 25th is towel day, sorry for that.
I also bought a Toshiba AC100 before my birthday, a Tegra 2 based notebook/netbook/”web companion” with 1 GHz dual core ARM Cortex A9 chip and 512 MB RAM. It runs Android by default, and had a price of 160€ which is low compared to anything else with Cortex A9. It currently runs Ubuntu 11.04 with a specialised kernel 2.6.37 from time to time, without sound and accelerated video (and not functioning HDMI). Mostly waiting for Nvidia to release a new binary blob for the video part (And yes, if you just want to build packages, you can probably get happy without those things).
Another thing happening last week is the upload of python-apt 0.8.0 to unstable, marking the beginning (or end) of the API transition I started more than a year ago. Almost all packages not supporting it have proper Breaks in python-apt [most of them already fixed, only 2 packages remaining, one of which is “maintained” (well, not really maintained right now) by me], but there may be some which do not work correctly despite being fixed (or at least thought to be fixed).
If you know any other interesting thing I did last week, leave a comment, I wrote enough now. And yes, WordPress wants to write a multiplication sign instead of an x, so I had to use x instead.
MeeGo (Nokia/Intel): Openness does not seem to be very important for Nokia and Intel. They develop their stuff behind closed doors and then do a large code drop (once dropped, stuff gets developed in the open). In terms of professionality, it does not look much better: If you look at the meego-dev mailing list, you feel like you are in some kind of a kindergarten for open source developers – Things like HTML emails and top-posting appear to be completely normal for them, they don’t even follow the basic rules for emails and they also appear to ignore any advice on this topic. Oh, and writing a platform in GTK+ while pushing Qt as the supported toolset is not a good idea.
Android (Google): The situation with Android appears to be even worse. Google keeps an internal development tree and the only time the public sees changes is when a new release is coming and Google does a new code drop. Such a behavior is not acceptable.
Ubuntu (Canonical): Canonical does an outstanding job on openness. Canonical employees develop their software completely in the open, and there are no big code drops. They basically have no competitive advantage and allow you to use their work for your own project before they use it themselves. Canonical employees basically behave like normal free software developers doing stuff in his free time, the only exception being that they are paid for it. Most Canonical employees also know how to behave on mailing lists and do not post HTML emails or do top-posting. There are of course also other people: The design process of the Ubuntu font on the other hand is a disaster, with the font being created using proprietary software running on Windows; for a free software company, that’s not acceptable (such persons should probably not be hired at all). Furthermore, the quality of Ubuntu packages is often bad when compared to the quality of a Debian package (especially in terms of API documentation of Canonical-created software); a result of vastly different development cycles and different priorities.
On a scale from 0 to 15 (15 being the best), Nokia/Intel receive 5 points (“D” in U.S. grades), Google receives 3 points (“F” in U.S. grades), and Canonical receives 12 points (“B” in U.S. grades). Please note that those grades only apply for the named projects, the companies may behave better or worse in other projects.
Final tips for the companies:
- Nokia/Intel: Teach your employees how to behave in email discussions.
- Nokia/Intel/Google: Don’t do big code drops, develop in the open. If someone else can create something awesome using your work before you can, you are on the right way. Competitive Advantage must not exist.
- Canonical: Fire those who used Windows to create the Ubuntu font and restart using free tools.
- All: Document your code.
Yesterday, I uploaded command-not-found 0.2.38-1 (based on version 0.2.38ubuntu4) to Debian unstable, using the “3.0 (quilt)” source format. All steps worked perfectly, including stuff like cowbuilder, lintian, debdiff, dput and the processing on ftp-master. Next steps are reverting my machine from Ubuntu 9.10 to my Debian unstable system and uploading new versions of gnome-main-menu, python-apt (0.7.93, not finished yet) and some other packages.
In other news, the development of Ubuntu 10.04 Lucid Lynx just started. For the first time in Ubuntu’s history, the development will be based on the testing tree of Debian and not on the unstable tree. This is done in order to increase the stability of the distribution, as this release is going to be a long term supported release. Ubuntu will freeze in February, one month before the freeze of Debian Squeeze. This should give us enough room to collaborate, especially on bugfixes. This also means that I will freeze my packages in February, so they will have the same version in Squeeze and Lucid (applying the earliest freeze to both distributions; exceptions where needed).
Overall, having time-based freezes is a good idea. But the chosen cycle is problematic, especially if one considers Ubuntu’s LTS release cycles. The problem is that if Debian releases a new version at approximately the same time as Ubuntu, there will not be much synchronization and Ubuntu will have newer program versions.
Consider the releases of Ubuntu 8.04 LTS (April 2008) and Debian GNU/Linux 5.0 (February 2009). Whereas Ubuntu 8.04 provides GNOME 2.22 including a new Nautilus, Debian provides GNOME 2.22 with nautilus 2.20. Ubuntu’s release made at about the same time (Ubuntu 9.04) already included GNOME 2.26.
The reason for this are the different development processes. Whereas a Debian release is based on stable upstream versions, the development of Ubuntu releases happens using newest pre-releases, causing Ubuntu releases to be one generation ahead in most technologies, although released at the same time.
Another difference is the way of freezing and the duration of the total freeze. Ubuntu has a freeze process split into multiple stages. The freeze which is comparable to Debian’s freeze is the feature freeze, which usually happens two months before the release. Debian’s freeze happens 6 month before the release, just about the time when Ubuntu has just defined the features to be included in the next release.
Synchronizing the release cycles of Debian and Ubuntu basically means that Ubuntu will always provide the newer features, better hardware support, etc. Ubuntu is the winner of this decision. It will have less bugs because it inherits from a frozen Debian branch and it can include newer versions where required because it freezes 3 months later.
To synchronize the package versions shipped in Debian and Ubuntu you have to make your release schedules asynchronous, in a way that the Debian release freezes after the Ubuntu release. This basically means that I expect Debian 6.0 (2010/H1) to be more similar to Ubuntu 9.10 than to Ubuntu 10.04. I would have preferred to freeze Squeeze in December 2010 and release in April 2011, and Ubuntu LTS to be re-scheduled for October 2010.
Now let’s say you are a Debian and Ubuntu user (and you prefer none of them) and you want to setup a new system in 2010/H2 (so the systems have a half year to stabilize). This system should be supported for a long time. You have two options: Debian 6.0 and Ubuntu 10.04. Which will you choose? Most people would probably consider Ubuntu now, because it provides better support for their hardware and has the newer features. A (partial) solution to this problem would be to make backports an official part of Debian starting with Debian 6.0.
Furthermore, there is the question of security support. If we want to provide the ability to upgrade directly from Debian 5.0 to Debian 7.0, we will have to support Lenny until 2012/H2 (to give users enough time to upgrade, when we release 7.0 in 2012/H1). This means that we would have to support in 2012: Debian 5.0, 6.0 and 7.0. And another side effect is that Debian 6.0 would have a 3 year security support, just like Ubuntu 10.04.
All in all, the decision means that Debian and Ubuntu LTS releases will occur at about the same time, will be supported for about the same time and that Ubuntu has the newer packages and less bugs to fix.
As I promised, I released python-apt 0.7.91 today. This version provides a new API, with real classes in apt_pkg, new names which conform to PEP 8 conventions, and it supports new language features such as the ‘with’ statement. Old code should still continue to work, if it does not and it is using only public interfaces, report a bug against python-apt or send an email.
I can not guarantee that all the names will be kept like they are at the moment (it’s a pre-release), but there should not be many more changes needed. The series will hit Ubuntu Karmic later this month, and the final 0.8.0 release is going to be shipped in the final Karmic release.
If you want to help with python-apt, consider to write some examples of what can be done with python-apt, and some tutorials for the documentation. You can also check for spelling mistakes and alike. If you want, you can also contribute code. See the documentation (in the package, or online) for guidelines on how to contribute.
You can get the 0.7.91 release from Debian experimental, and you can view the documentation online at http://apt.alioth.debian.org/python-apt-doc-exp/.
And of course, a short example:
with cache.actiongroup(): # apt.Cache 'cache' for package in my_selected_packages: package.mark_install() # New PEP 8 names, previously named markInstall()
Today, I was testing Canonical’s new Ubuntu One service. Ubuntu One is a service for syncing and sharing files online, with 2GB storage for free. I installed the Ubuntu One client on Ubuntu 9.04 and it’s cool.
Ubuntu One creates a directory named Ubuntu One in your home directory. Within this directory, there are two subdirectories. The first one is “My Files” and the second one is named “Shared With Me”. When you place files in the “My Files” directory, the Ubuntu One client gets notified (using inotify) about the change and begins uploading the file to the Ubuntu one server.
When you access the web interface, which should work in every modern browser, and upload a file there, the next time your local client connects the files are fetched to your local hard disk. This also works when you have two different computers and create a file on the one computer, it will be visible on the second one as soon as it has fetched the new file.
You could also copy your .mozilla directory into the synced directory, and create a symlink from your home directory to it. I have not tried it myself, but in theory this would allow you to have your profile synced on all your computers.
And the best thing about Ubuntu One is that the client is completely free software and written in Python. This makes it possible to package the client for other distributions, like Debian. Packaging it for RPM-based distribution such as Fedora should also be doable, but may require some more time.
There seems to have been some criticism that the server side is not free software. While that may not be the good, it’s certainly better than other services where even the client is proprietary. And there still is the possibility to write your own server as the protocol is available.
Ubuntu One is currently in private beta, if you want to try it out, you need an invitation (visit ubuntuone.com for further information).
Much happened since the last time I wrote about debimg. The project is now registered on Alioth and has a mailing list. On the code side, there have also been several changes.
First of all, the repository module has been merged into the master branch. This was the first step towards the creation of the image building, which happened today by introducing the ‘image’ module.
The code should be treated as Beta quality, but the project as a whole is Alpha, because the application utilizing debimg.core is still missing. As always, I hereby encourage to try out debimg, have a look at the examples, and help to develop it.
Patches should be sent to the mailing list, created with git format-patch, and its usual settings (eg. prefixed with eg. ‘[PATCH 1/2]’). The patches should be inline and validate in pyflakes and using pep8.py. See the README for some more recommendations.
Because NEW seems to be really busy at the moment (and doko uploaded python2.6 and python3.1), I’m not uploading the current state as 0.1.0~a1 to experimental, but wait until NEW is smaller (maybe it will be 0.1.0~b1 then).
What is wanted/planned?
- Compatibility configuration formats
- (debimg.config.simple_cdd) A reimplementation of simple-cdd using debimg. This probably needs to wait until there is a module for dealing with the installer, but I want to implement an application to support simple-cdd configuration files.
- (debimg.config.debian_cd) There could be an implementation of debian-cd’s configuration format. This would allow people to easily try out debimg. We can only support a subset, though.
- New configuration formats
- (debimg.config.yaml) Debimg’s native configuration format. This is the only one supported by the graphical frontends. Where possible, configuration between compatibility formats and this format will be provided.
- Graphical Frontends:
- (debimg.frontend.gtk2) The graphical GTK+ frontend for inexperienced users who just want to create their own disk.
- (debimg.frontend.qt4) The graphical frontend written in QT4.
- Text frontends
- (debimg.frontend.text) The basic command-line frontend.
- (debimg.ubuntu.frontend.text) A script to build Ubuntu images, which could be used to build the official Ubuntu Images. This requires interaction with the germinate tool for dependency resolution, and more. It’s also not flexible enough for building custom images.
Requirements for 0.1 Beta
- Implement at least one configuration format and the build frontend.
- Have at least one external contributor.
- Mailing-List: firstname.lastname@example.org (Archive at http://lists.alioth.debian.org/pipermail/debimg-devel/)
- Wiki: http://wiki.debian.org/DebImg
- VCS-Git: git://git.debian.org/debimg/debimg.git
- VCS-Browser: http://git.debian.org/?p=debimg/debimg.git
Julian Andres Klode (6):
- debimg/core/files: When creating a file object allow filename as source
- debimg/core/resolver.py: Introduce Package.fullname, Package.component
- debimg/core/repository.py: Merge the repository module.
- debimg/core/resolver.py: Improve handling of certain dependency types
- debimg/core/repository.py: Allow Repository.add_group to take a ‘distro’ parameter
- debimg/core/image.py: Introduce the image module.