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.
After I tried OpenSolaris 2008.11, I also tried Fedora 10 and Ubuntu 8.10, each for almost one day.
Creation of bootable USB stick: For both distributions, I created a bootable USB stick because it is faster to install from USB than from CD/DVD. The creation was easy in both cases. Fedora ships a shell script and Ubuntu a graphical program for this task. Both very equally easy to use.
Booting from USB: Both distributions booted perfectly from USB. But there was a big difference in boot speed: Fedora 10 booted in about the same time Ubuntu needed to find the USB stick.
Installation from USB to HDD: Installation of both systems went very well, without any problems. Fedora’s installer is far more powerful than Ubuntu’s, e.g. it allows to use LVM or encrypted partitions. To setup LVM and encrypted volumes with Ubuntu, you need to use the text installer on Ubuntu’s alternate disk (It’s debian-installer). Ubuntu’s graphical installer received a new partioning screen.
Boot: Fedora’s boot time seems to have improved a lot since the last release. Ubuntu’s boot time seems to be roughly the same as in 8.04. Both distributions provide a progress bar, whereas Ubuntu’s usplash looks better. But this may change once kernel-based modesetting works on Intel cards in Fedora, because Fedora’s splash program needs it for graphics. Else, it only displays ASCII progress bar.
Login: Fedora 10 shipped with GDM 2.24, which means that there are no themes yet. But this was no problem, as the non-themed design of GDM has improved a lot. I even like it more than any themed GDM I have seen. It reminds me a bit of OSX.
Desktop: Both distributions ship with GNOME 2.24. The default themes look good, whereas Fedora’s uses more GNOME-like icons, whereas Ubuntu uses Human, which is based on Tango. And that is important for me, since I normally do not change any aspect of my desktop, except for adding cpu frequency and tomboy applets to the panel.
Hardware support: Both distributions provide good hardware support. Ubuntu leads here, at the cost of having non-free drivers included on the disk.For users needing windows wireless LAN drivers, Ubuntu is the right choice, as it ships ndiswrapper and the graphical frontend (ndisgtk) on the installation medium. Fedora does not include ndiswrapper, because of what it is used for (installing non-free Windows drivers). Both distributions ship firmware, and consider firmware images as free enough, as they do not run on the CPU.
EXT4: Fedora 10 ships with patches for EXT4 backported from Kernel 2.6.28. It also supports the installation on ext4 partitions, but only using the DVD and if booted with the ext4 option. The Live discs do not support installation to ext4.
Package management: Both distributions ship with good package managment software. YUM really improved since the early times, where it downloaded an extra metadata file for every package. Nowadays, yum and apt seem to be on a nearly equal level, but aptitude lets Ubuntu win, because it can handle problems much better (ie. it proposes ways to solve problems) than YUM.
Graphical package management: Ubuntu wins here. Fedora only ships PackageKit for package managment, which, in my opinion, is not able to really compete with Synaptic and gnome-app-install.
Conclusion: Both distributions are very solid. Ubuntu still has the better package managment, and a bigger selection of packages. This has only been possible due to Debian, which is the base of Ubuntu. I tried to write this blog post not as an Ubuntu member. I always liked Red Hat and Fedora, and one of my first Linux distributions was Red Hat 9.
I worked a bit with some Gentoo systems the last days and it was no fun. The whole compiling thing is no fun. In fact, it is a danger for the environment. If every computer in the world run Gentoo, power consumption would increase dramatically. There would also be no netbooks, as they are almost unusable for running Gentoo on it, compiling software.
The path chosen by binary distributions like Debian is much better. Packages are compiled centrally and users download and install these pre-compiled packages. But it is also much less flexible in terms of which functionality is supported. We, as package maintainers, have to decide which functionality is likely to be used by the users. In Contrast, Gentoo has USE flags, which allows the user to enable the specific functionality he/she wants.
Should we combine the advantages of both technologies? Provide a normal binary distribution as we do now, but also provide a framework for users to easily recompile their packages, adding new functionality.
Imagine a combination of all these technologies: User wants to install software X with feature F. The package maintainer has not enabled F in the binary. The user opens the website for his personal archive, selects the F flag and the software and clicks on build. The server builds the software and notifies the user once the binary is ready.
At Ubuntu, the first step has been made into this direction. While the package format is still the same, Launchpad allows users to create so-called PPAs (Personal Package Archives), where users can upload their source packages, which are then compiled and made available to other users. Let’s say Project A releases version X of their software. They can create a source package for it, upload it to the PPA, and provide the binary packages to the users. Prior to PPAs, most users would have used an old version, compile their own version or use tarballs containing pre-compiled software (mozilla does this).
And sorry for the title. I respect the Gentoo community and the Gentoo developers, they are doing great work there. And ebuilds and Gentoo’s boot system (with this runscript stuff) is really easy.
BTW: I also like the way Gentoo displays its boot messages. It looks much more organized than Debian’s boot process. (In terms of the message logging, where Debian writes “done” when something is done, and Gentoo writes “[OK]” to the right side of the screen, in green letters. (This is partially possible in Debian using lsb-base-logging.sh, but not all init scripts use these functions, or they use the wrong ones.)
As promised, i have built a few development snapshots of the swfdec git branch for hardy. They are available in my PPA.
To use it, add the following line to /etc/apt/sources.list and install swfdec-mozilla0.7.
deb http://ppa.launchpad.net/juliank/ubuntu hardy main
Please note that these packages are experimental and are only for experienced users.