Scott Remnant has published a new roadmap for Upstart 0.5, Ubuntu’s init replacement. It picks up several items which has been discussed earlier with developers of other distributions.
The roadmap was posted a month after a “State of Upstart” post. In this state post Scott described what kind of changes were requested or mentioned by other distribution developers to fit Upstart to their ideas and visions thus creating a cross distribution solution for an init replacement. The roadmap now includes several of these parts.
As a result the IPC service for Upstart will be D-BUS. While the original idea to have an own IPC service was to keep it simple and easy the other distributions requested/suggested/demanded (well, at least Fedora mentioned something in that direction afaik) D-BUS for this. It also makes sense since IPC isn’t that easy and D-BUS is already out there and the de-facto IPC service of Linux (once KDE 4 gets spread enough).
It can be said that Upstart plans work better with HAL and D-BUS in general: in the future Upstart could take over most of the tasks where services have to be started due to a HAL or D-BUS event/request.
Besides the IPC stuff a big part of the roadmap is covered by the service management: Upstart will not only start or stop services but will also manage them if necessary. A use case would be that Upstart could ask a service to reload its configuration – or to reload a different configuration.
This allows conflicting configuration to exist and be handled sanely; which is especially important since I’d like to support job creation by
external processes. They’ll be able to register themselves as a configuration source and define jobs under it.
Scott also plans to add resources and more environment variables to the service management. A process could for example come along with a specific resource request (1 GB free RAM or whatever). If that resource is not available Upstart would put the process into a queue until the resource is available. The additional environment variables will not be hardcoded but depend on the job’s own definition.
All in all it is great to see that Upstart is further developed. Why I know that a lot can be done by just improving the init and start scripts (like almost all recent distributions did) the old init system had its best time some ten years ago. Today’s systems need a flexible and careful service manager which works together with the other basic elements of the system (HAL, D-BUS, etc.). There is simply no need that specific network services are started on my machine as long as NetworkManager says the system is offline.
I’m looking forward to the first Upstart version which incorporates all these changes. I would like to have another look at it then with Fedora.
Richard Hughes posted information about the current PackageKit development. Recently PackageKit become capable of managing repositories and performing automatic updates with GUI support. Additionally, version 0.1 will be released these days and there is also work under way to create a KDE/Qt GUI.
PackageKit now includes the feature to switch repositories on and off. This is indeed useful for most Linux users out there since almost every user includes at least one more repository than the standard repositories (most often the additional repository comes along with non-free software). Of course average computer users are only supposed to change these values when they are advised to do so by the computer support or by a (good) howto – but there might be situations why this can become necessary, and in such cases a GUI is always better than the command line (this is the opinion of someone who is a voluntary help desk for years now).
As another feature PackageKit is now also able to notify when automatic updates are performed. The user can also cancel the task until further notice. The idea is that the automatic update is only done when the computer is idle (screen saver) and has a network connection (NetworkManager is used for that). If that is the case the user is still notified in case he wants to do something else or is short in front of a meeting or similar where he needs the absolute reliability of the machine.
Besides these new features of PackageKit itself we might see a KDE/Qt GUI in the near future: Adrien Bustany has started working at this and already published first results (Qt bindings). It would be really great to see native PackageKit support in for example KDE 4.1.
Speaking about future releases: the first official release of PackageKit is around the door: it was announced for this week and should therefore arrive soon. Besides the technical numbering for better planing and packaging such a release is also a declaration: PackageKit is stable enough to test it the first time. The APIs have matured up to a certain point and it is now worth looking at it.
And indeed: the Foresight distribution plans use PackageKit as their native frontend in the future. Congrats to the PackageKit team for that!
Besides these larger news the development goes on at high speed: the PackageKit team implemented local file install, support for new repository GPG keys and support for rollbacks. As usual, if the feature will work on your system depends on the backend and how far the backend supports these actions. In case PackageKit gets more spread (and I really hope it will do so) I wonder if we will se more development in the backends to better support PackageKit. Usually package management developers are very stubborn but PackageKit could even change that.
And maybe in some months PackageKit could start replacing the distribution specific tools slowly but steadily (relax, just for the average users!). That would be a silent, but large and really necessary revolution.
While Fedora 8 will not ship with KDE 4 as the default KDE version there will be all necessary packages available to provide a development environment. Now these packages also entered the Fedora 7 repository.
Fedora 8 will be released around 8. November. As already reported it will come along with a development environment of KDE 4.0.
Since 1. October these packages are also available for Fedora 7:
# yum install kdebase4
Loading "skip-broken" plugin
Loading "fastestmirror" plugin
Loading "changelog" plugin
Loading mirror speeds from cached hostfile
Package Arch Version Repository Size
kdebase4 i386 3.93.0-4.fc7 updates 26 M
Installing for dependencies:
kdelibs4 i386 3.93.0-10.fc7 updates 13 M
kdepimlibs i386 3.93.0-3.fc7 updates 2.0 M
soprano i386 0.9.0-2.fc7 updates 94 k
strigi-libs i386 0.5.5-1.fc7 updates 336 k
Install 5 Package(s)
Update 0 Package(s)
Remove 0 Package(s)
Total download size: 41 M
Is this ok [y/N]:
The installation does not carry any updates, an existing KDE 3.x installation will not be changed. Also, there is only everything necessary for a basic runtime environment and development platform. All other major packages of KDE like the network or games package are imssing. These will most likely find their way into Fedora in the next months when KDE becomes more and more stable.
Now there is no more need for Fedora users to update to Fedora 8 just to have a loom at KDE 4. However, keep in mind that these KDE packages are not svn snapshots but the official Alpha/Beta releases. Since the next KDE release should be here any day now the currently shipped KDE version for Fedora is comparable old and does not deliver more than a first look at the upcoming KDE 4.0. The number of changes even between Beta 2 (the version in the Fedora repositories) and Beta 3 is very large and includes many important parts.
There is an update to this post available: UUIDs and Linux: Everything you ever need to know.
The Universally Unique Identifier can be used to identify a device independent form its mount point or device name. This is more and more important as many devices today support hot-plugging or are external anyway. Therefore it makes sometimes sense to access a device (for example in
fstab) not by device name but by the UUID.
There are several ways to get the UUID. The first one uses the
/dev/ directory. While you are on is you might want to check other
by-* directories, I never knew of them.
$ ls -l /dev/disk/by-uuid
lrwxrwxrwx 1 root root 10 11. Okt 18:02 53cdad3b-4b01-4a6c-a099-be1cdf1acf6d -> ../../sda2
Another way to get the uuid by usage of the tool
$ blkid /dev/sda1
/dev/sda1: LABEL="/" UUID="ee7cf0a0-1922-401b-a1ae-6ec9261484c0" SEC_TYPE="ext2" TYPE="ext3"
There you also get the label and other information. Quite usefule.
Btw., if you wonder how “unique” this unique is, here a quote from Wikipedia:
1 trillion UUIDs would have to be created every nanosecond for 10 billion years to exhaust the number of UUIDs.
Thanks to Linux By Examples for the initial howto.
The company IP Innovation has filled an “patent infringement claim” against the two largest Linux Distributors. The patent in question is about a “user interface with multiple workspaces for sharing display system objects”.
The battle has begun. The first patent infringement claim against Linux is out there and two big Linux distributors will have to defend in court. Groklaw has more information and the text of the complaints.
This comes only days after Microsoft’s Ballmer attacked Red Hat Linux users.
IP Innovation already made such claims against Apple this year. However, Apple settled the the patent dispute without any further details.
While it doesn’t sound good that there is now a patent claim against Linux there is hope that a court find these claims not valid. Keep in mind that in these days the US courts are slowly moving regarding stupid or invalid patent claims. Also, this process will now show how vulnerable the Linux ecosystem really is against patent claims – and how well it can be defended. I must add at this point that I’m somewhat happy that there have been the SCO claims in the last years. Due to SCO the Linux community now has a well working and well established community of people who know their way about laws and courts: Groklaw. I’m anxious to see which role Groklaw will play in this act.