Yesterday morning, Romain pushed inline release 0.3.5 to CRAN. This is some ways a continuation of the 0.3.4 release I had made in December. That release had opened the door for the wide use of inline in our Rcpp package. And just how Rcpp has grown, we now have needs beyond the initial change. See the post on Romain's blog for details, but in a nutshell we are now gaining

• cxxfunction which extends cfunction further for C++ use and, among other things, adds a plugin system we can use from RcppArmadillo to permit use of inline
• package.skeleton which makes it easy to carry a function that one has prototyped with inline over into its own package -- and how to do that was a question at my most recent Rcpp talk in Vienna), and
• getDynLib which Romain will use to great effect in the next version of Rcpp to provide something not unlike Boost::Python. Stay tuned!

Last but not least, our thanks to Oleg Sklyar for letting us extend his amazing inline package for use by Rcpp.

Since the recent announce of http://ubuntudiff.debian.net, some people started using it and asked for a few features. Lately, I ve been working on it and tried to implement the following:

• Use a single page (instead of a small HTML page with a lot of JS) well, that was easy
• Show the debdiff between the Ubuntu package and the Debian one: that was simpler than I first thought. Right now, it s implemented and deployed [1]. When I first generated all patches, I realized how people can be crazy I had diffs larger than 60MB. So, I had to reduce that by keeping only diffs less than 200 lines per file. At the end, I had a little more than 2GB of patches (and html files) generated for ~2000 source packages (which is somehow reasonable). So now, below the changelog, there is a list of modified files and you can:
  • download a patch for each file, extracted from the debdiff,
  • or click on the file s name to see the diff (if not too large, i.e. less than 200 lines)
  Note that red colored filenames denote files with too large diffs.

I ll still have some details to fix like putting the download patch link on the left, fix the show/hide thing which is also activated when you click on download patch . Then, I ll consider it feature-complete (almost) and won t touch it again. My next game will be to write some tools to analyse or detect new transitions if you want to play, let me know As always, please test this new beta version of UbuntuDiff (and enjoy it :p) and maybe, you may also report errors/bugs, if any [1] http://ubuntudiff.debian.net/beta/

Would it be wrong to make a new blog entry just to test the blogging platform? If so I'm wrong. To pretend that isn't the case I'll briefly document some recent events:

Coding

I've been making changes to the blogging software, chronicle, to support RSS feeds on comments, and to allow outgoing Pings on new entries. I've also been flirting with an OpenID-backed image upload and sharing site, provisionally named picshare. Why? Partly for fun, partly because I like comments, and partly to flirt with RESTful design and API construction.

Photography

I've provisionally agreed to be the photographer for a special event at a local hair-dressers. This will either be fun, or all end badly. No money, but free food and the chance to experiment more. So all good.

There. Almost like a real entry, right? ObSubject: Cruel Intentions

Meego 1.0 was released last month. Predictably enough, it lacks any form of support for the GMA500 graphics chipset[1], which is reasonably in line with Intel's placing of US15W as an embedded product for MID-type devices rather than having anything to do with netbooks. Of course, the market pretty much ignored that detail, so we're left with the release of a netbook experience that's incompatible with a large number of netbooks.

There's been hints that there might be some sort of new driver coming, though, and Intel's rapidly heading towards the release of Moorestown - their new MID platform that's x86 but not a PC, that replaces Poulsbo (unless you want to run Windows) and which has the same SGX 3D core[2] as Poulsbo. Moorestown support has started landing in the mainline Linux kernel and Intel are talking about devices shipping with it this year, so we ought to see the graphics driver soon, right?

Well, kind of. Digging through the Meego kernel git tree reveals an updated driver with Moorestown support. The blob is too big for gitorious to display, so I've put up a copy here. Things to note - this isn't a new driver (it's clearly derived from the PSB one), it includes a huge blob of Imagination's platform-independent code, the front end of the driver is still pretty much the i915 driver with a small number of PSB-specfic changes and despite the cheerily optimistic "Patch-mainline: 2.6.35?" at the top it stands pretty much no chance whatsoever of going mainline given that it's even more offensive than the previous version and that one got rejected out of hand.

So it's not clear what Intel's doing here. If this is the driver that Intel are developing for upstream then there's been a pretty serious breakdown in communication over what their driver has to look like. If it's not, Intel have another and presumably better driver somewhere that they're developing entirely behind closed doors despite having shipped millions of units of hardware that people would dearly love to be able to run mainline kernels on. Neither case looks especially good, so the continuing perception would seem to be that only a subset of the company understands the Linux development model - we'll see how this ends up interacting with Meego as a whole.

(Huh. I was about to hit "Post" on this, and then found that another and entirely different driver was submitted for the Meego kernel last week. A copy of it's here. "IVI" in this context appears to stand for "In-vehicle interface" and is aimed at those contexts rather than generic ones. It includes much the same Imagination glue code as the Moorestown driver, appears to be derived from a driver that has support for other Intel chipsets, was written to be at least partially OS-independent given that it abstracts things like PCI and stands even less chance of going upstream than the other driver - as acknowledged by "Patch-mainline: Never". Hilariously, if we include IEGD, that makes three different drivers for the same hardware from the same company, each having no chance to go upstream. Thintel.)

[1] Weirdly, it includes the kernel DRM for Matrox cards. No X driver though.
[2] It's clocked higher, though

submit your own dependency-resolution issue, a-la popcon [ repost from the original, with updates ] During the question time of my FOSDEM 2010 talk about cross-distro dependency resolution several interested people, mostly sysadms, asked how they could contribute upgrade scenarios to the Mancoosi project. The underlying idea is simple: we are working on improving dependency resolution techniques, algorithms, and tools; to that end we need a corpus of upgrade scenarios where shortcomings of state of the art tools can be observed. We already have quite some of such scenarios (partly provided by members of the project, partly generated in vitro, etc.), but we could use more. So, I'm hereby happy to announce the public availability of the mancoosi-contest package, for Debian-based distributions. mancoosi-contest essentially offers a wrapper, called dudf-save, that you can prepend to usual invocations of package managers such as apt-get and aptitude. What it does is to capture all package meta-data concerning your request, as well as the request itself and the package manager output. All these data are first compacted using snapshot.d.o hashes, then collected into a DUDF document, and finally (optionally) uploaded to a DUDF collector service. All in all it is very similar to the popularity-contest architecture, but instead of collecting installed packages it collects specific upgrade attempts. The similarity of course extends to privacy concerns, which we do take very seriously (censoring IP addresses and offering all the software we write and run available under FOSS licenses for scrutiny). Obviously, participation is completely optional and the mancoosi-contest package is currently being provided only unofficially by the Mancoosi project (even though it is signed by my key, in case you want a trust path from the Debian keyring). All that said, if, one day, you feel like having stumbled upon a challenging upgrade scenario, please consider contributing it using mancoosi-contest. We, for once, would be grateful , and you will be helping in improving the state of the art in dependency solving. Some of the most interesting upgrade scenarios already received are currently being used as material for the ongoing MISC 2010 competition, which we plan to repeat in the future. Technically, dudf-save is still quite hackish and while apt-get support is OK-ish, aptitude support is sub-optimal. In particular it will work properly only for "completely batch" aptitude sessions (or, better, it will not catch any intermediate solving attempt that aptitude goes through when interactively asking questions to the user). You can get mancoosi-contest from mancoosi.debian.net, i.e. simply doing apt-get install mancoosi-contest after having added the following APT repository to your sources.list:

    deb http://mancoosi.debian.net/debian/ unstable/

For the time being, bug reports can be sent to me.

When using sitesummary at a site to track machines, it is possible to get a list of the machine types in use thanks to the DMI information extracted from each machine. The script to do so is included in the sitesummary package, and here is example output from the Skolelinux build servers:

maintainer:~# /usr/lib/sitesummary/hardware-model-summary
  vendor                    count
  Dell Computer Corporation     1
    PowerEdge 1750              1
  IBM                           1
    eserver xSeries 345 -[8670M1X]-     1
  Intel                         2
  [no-dmi-info]                 3
maintainer:~#

The quality of the report depend on the quality of the DMI tables provided in each machine. Here there are Intel machines without model information listed with Intel as vendor and mo model, and virtual Xen machines listed as [no-dmi-info]. One can add -l as a command line option to list the individual machines. A larger list is available from the the city of Narvik, which uses Skolelinux on all their shools and also provide the basic sitesummary report publicly. In their report there are ~1400 machines. I know they use both Ubuntu and Skolelinux on their machines, and as sitesummary is available in both distributions, it is trivial to get all of them to report to the same central collector.

It seems I ve missed quite a few weeks in my countdown to our Mini DebConf. Fortunately, it s not too late for you to join even if, right now, you don t know why you should! So what s the status? Well, we ve had out problems in the beginning to start the whole thing but we managed. There are a few minor issues left, I admit. If you happen to have a bit time on 10th or 11th to hold the camera for an hour or so, contact us! Or if there is *anything* you would wanna do to help us out a bit, don t be shy. You don t need to be a known Debian contributor, you don t need to know us. Arguably, you should know Debian but then, if you re able to spell the name correctly, you re probably in. :-) Apart from that, we really think it s gonna be awesome. Not only will there be a few Debian Developers from outside Germany, like our project leader zack who we have the honor of listening to for he has the first talk on Thursday. There will also be quite a few German faces that some of us haven t met yet have you met Sebastian, the chief of our beloved debianforum.de, yet? We are going to have a great time and you re a fool not to join. Thus, a last time for all of you who still don t know what I m talking about: Next week there ll be the famous LinuxTag in Berlin from Wednesday to Saturday. Right in the middle, on Thursday and Friday, we, the Debian community, will have a Mini DebConf right there. There will be talks about different Debian related things. And many active developers will be there happy to talk to you about whatever you always wanted to know or say about Debian. And then, not to forget, we ll have a hacklab where you can easily plug in your notebook and start hacking with us. Have an idea to improve Debian? Always wanted to know how to fix a bug? You want to make Debian Squeeze the best Debian release ever? Join us it seems we re fighting on the same side. See you there, guys! PS: The latest and hottest news about it.

I'm all for security and really like encryption (my Notebook's harddrive is encrypted, I've recently got a GPG Smartcard, ...) but sometimes you see big failes where security is atemted but doesn't actually secure anything but only hinders the legitimate user. Today one of these candidates ate way to much of my time again. I'm currently getting more and more used to GNU Emacs and currently experimenting with emacs-jabber. Therefore copying my jabber accounts over from psi. As with these passwords you never type in I couldn't remember some of my jabber passwords -- no problem psi has to store them so it should be easy to get them, right? Well actually not. The configuration file (XML) had a password entry but all that was in it was just obviously hex-encoded numbers. These numbers turned out to be be 16bit packages of characters that are XOR-ed against the JID So now you have to read them in in junks of 16bit, XOR them against the JID and get the password. Time to recapitulate what this security helped. I've written a hacky 10 lines C Program that can reliably retrieve passwords from any config file I might come across. Seems you can do the same in 2 lines of perl. Ergo no security at all was added. Next question: What did it cost? Needed an hour or so of researching the encryption and trial&error out the right program fragment. For nothing gained at all. Fail.

Packages of bup, a git-based de-duplicating backup tool, are now available in unstable.

After xen-tools had been removed from Debian Unstable by the upstream developer last December due to no more upstream development, I took over upstream development as well as Debian package maintainership in January. Since then a lot happened:

• Development moved from Mercurial to a set of git repositories at gitorious.org.
• Dmitry Nedospasov joined my effort to revive xen-tools.
• Via gitorious clone tracking we noticed that there were useful patches in clones of xen-tools and incorporated most of them back into our master branch.
• We created a second mailing list xen-tools-dev which is mainly thought for communication between the xen-tools developers.
• The xen-tools.org website and the xen-tools mailing lists moved from Steve s to my server. The website has been slightly overhauled and the mailing lists now use Mailman.
• Support for all recent Debian and Ubuntu releases including Squeeze and Lucid.
• Full support for pygrub and DomU distribution kernels installed in the DomU. Now you easily can install DomUs whose udev doesn t fit to your Dom0 kernel.
• Full support for cdebootstrap in addition to debootstrap.
• Tons of bugs fixed
• I m on the quest to find the holy grail of bug tracking systems. ;-) More on this in another blog posting.

But despite all the things which were to fix after Steve discontinued the xen-tools developement, Steve Kemp did a great job to bring xen-tools so far initially. I m really happy that this software exists and that s the reason why I won t let it die so fast. :-) xen-tools 4.2 beta 1 released Last weekend I released xen-tools 4.2 beta 1 which I also uploaded to Debian Unstable. And thanks to the active ftp-master team, xen-tools went through the NEW queue in less than 12 hours and is now available again in Debian Unstable. 4.2 beta 1 still has some known bugs, the worst ones are in xen-delete-image. But no fear, it doesn t delete more than wanted, just not enough or things which don t exist anyway. :-) There are also some smaller issues to fix for a final 4.2 release. We may also create an PPA for Ubuntu Lucid in the future to work around the lack of xen-tools in Ubuntu Lucid. What about Fedora/RedHat/CentOS support? Since rinse is out of date with regards to current Fedora releases, rpmstrap seems to be out of date for even longer (it has been removed from Debian before the Lenny release) and febootstrap neither seems to work out of the box nor seems to support bootstrapping to mount points (because it wants to delete them first and fails), bootstrapping Fedora ist currently not supported. The copy installation method should work though. rinse still is able to bootstrap CentOS 4 and 5, but the installation seems incomplete. We ll try to work around these issues for the final 4.2 release. We haven t looked at mach and mock so far, but according to Lucas, both are out of date, too. Sure, implementing Lucas howto in form of a script would be a possible way, but we think it would just create yet another not so well supported clone of rinse, rpmstrap, mach, mock or febootstrap. Because of that, Dmitry works on support for the installation of Xen DomUs via kickstart. Fate of xen-shell? Xen-shell has also been removed from Debian Unstable last December because Steve stopped its developement, too. But in comparison to xen-tools itself, we didn t resurrect xen-shell since none of us currently has use for it. So if you are currently using xen-shell and intend to continue to do so, you should hurry up if you want to see it in Debian Squeeze. We can also help you, but we surely can t and won t do it alone nor will we take the majority of the necessary workload.

Robert Collins did a very nice writeup not so long ago of creating a Debian package with bzr-builddeb, but he starts from the assumption that upstream also uses bzr. As we all know, there are many projects that have their upstream sources in a VCS, but don't use bzr. Can we still get reasonable results from bzr-builddeb, including the ability to merge new upstream releases direct from the VCS, if, say, upstream is using git? Yes, we can! Of course, if you're happy with using git as the VCS for your Debian packaging already, there's probably no compelling reason for you to switch to bzr. But if you prefer to use bzr and have been frustrated at having to choose between being able to use the VCS client of your choice for your packages and being able to use your VCS client to access upstream revision history, read on. Thanks to the fine work of Jelmer Vernooij and friends, bzr-git has been usable for a while if you just want to track the default git branch. But what if you care about tracking multiple upstream branches? Enter bzr git-import, which we'll use to set up a bzr repo from scratch for our cifs-utils package, with a full import of all the branches of upstream's git tree. First we do some work to set up a shared bzr repository. As long as we're going to the effort of mirroring all the git branches, we probably want to publish them for other people to use, so we make sure our bzr repository is reasonably configured for sharing data between branches:

$ bzr init-repo --no-trees cifs-utils.server
Shared repository (format: 2a)
Location:
  shared repository: cifs-utils.server
$ cd cifs-utils.server

Then we use bzr git-import, provided by the bzr-git plugin, to do a full import of the upstream branches into a cleverly named subdirectory:

$ bzr git-import git://git.samba.org/cifs-utils.git upstream
[/                   ] Counting objects: 181, done.

Now we create our own local 'trunk' for the package, by branching from the upstream tag matching the release version we're going to package.

$ bzr branch -r tag:cifs-utils-4.0rc1 upstream/HEAD trunk
Branched 42 revision(s).

Do a little more prep work for future branches...

$ mkdir branches

And that's it. Now we have a bzr repo locally that we can push out to our hosting server of choice (N.B.: we could do this all directly on the server, but alioth doesn't currently have bzr-git installed):

$ rsync -az . alioth.debian.org:/bzr/pkg-samba/cifs-utils/
$

Now that we have a bzr repository, it's time to get ourselves a working directory and do some packaging. We're probably going to work with multiple branches locally as well, so we create another shared repository for local use, and get a copy of the trunk branch we created before.

$ bzr init-repo cifs-utils
Shared repository with trees (format: 2a)
Location:
  shared repository: cifs-utils
$ cd cifs-utils
$ bzr co bzr+ssh://bzr.debian.org/bzr/pkg-samba/cifs-utils/trunk

Now we grab the upstream tarball, and whip up some quick packaging with (what else?) debhelper 7:

$ wget ftp://ftp.samba.org/pub/samba/cifs-utils/cifs-utils-4.0rc1.tar.bz2
$ ln -s cifs-utils-4.0rc1.tar.bz2 cifs-utils_4.0~rc1.orig.tar.bz2
$ cd trunk
$ mkdir -p debian/source
$ echo '3.0 (quilt)' > debian/source/format
$ echo 7 > debian/compat
$ cp /usr/share/doc/debhelper/examples/rules.tiny debian/rules
$ dch --package cifs-utils --versio 4.0~rc1-1 --create 'Initial package'

Create debian/control by hand, generate an initial source package, and import it into bzr with bzr-builddeb.

$ debuild -uc -us -S -i
$ rm -r debian
$ bzr import-dsc ../*.dsc
$

Since we want to continue tracking upstream development, we need to periodically sync our bzr import of the git tree.

$ bzr git-import git://git.samba.org/cifs-utils.git bzr+ssh://bzr.debian.org/bzr/pkg-samba/cifs-utils/upstream
$

And when we find a new upstream version in that import that we want to package, bzr-builddeb makes this a snap, too.

$ cd cifs-utils
$ wget ftp://ftp.samba.org/pub/samba/cifs-utils/cifs-utils-$version.tar.bz2
$ cd trunk
$ bzr merge-upstream --v3 --version $version_with_epoch \
    ../cifs-utils-$version.tar.bz2 -r tag:cifs-utils-$version \
    bzr+ssh://bzr.debian.org/bzr/pkg-samba/cifs-utils/upstream/HEAD
No distribution specified, and no changelog, assuming 'debian'
Committing to: /tmp/tmpbzOVMs/upstream/
Committed revision 2.
All changes applied successfully.
The new upstream version has been imported.
You should now review the changes and then commit.
$ bzr diff
<review changes>
$ bzr commit -m "merge upstream $version"
Committing to: bzr+ssh://bzr.debian.org/bzr/pkg-samba/cifs-utils/trunk
modified debian/changelog
Committed revision 50.
$

And that's it! It's exciting to see signs of real interoperability between DVCSes at last. Thanks to everyone who's helped make it possible!

It is strange to watch how a bug in Debian causing KDM to fail to start at boot when an NVidia video card is used is handled. The problem seem to be that the nvidia X.org driver uses a long time to initialize, and this duration is longer than kdm is configured to wait. I came across two bugs related to this issue, #583312 initially filed against initscripts and passed on to nvidia-glx when it became obvious that the nvidia drivers were involved, and #524751 initially filed against kdm and passed on to src:nvidia-graphics-drivers for unknown reasons. To me, it seem that no-one is interested in actually solving the problem nvidia video card owners experience and make sure the Debian distribution work out of the box for these users. The nvidia driver maintainers expect kdm to be set up to wait longer, while kdm expect the nvidia driver maintainers to fix the driver to start faster, and while they wait for each other I guess the users end up switching to a distribution that work for them. I have no idea what the solution is, but I am pretty sure that waiting for each other is not it. I wonder why we end up handling bugs this way.

I was asked by email whether SE Linux could implement traditional Unix users and groups. The Strictly Literal Answer to that Question The core of the SE Linux access control is the domain-type model where every process has a domain and every object that a process can access (including other processes) has a type. Domains are not strongly differentiated from types. It would be possible to create a SE Linux policy that created a domain for every combination of UID and GID that is valid for a user shell given that such combinations are chosen by the sysadmin who could limit them to some degree. There are about 2^32 possible UIDs and about 2^32 possible GIDs, as every domain is listed in kernel memory we obviously can t have 2^64 domains, but we could have enough to map a typical system that s in use. Of course the possible combinations of supplemental groups probably makes this impossible for even relatively small systems, but we can use a simpler model that doesn t emulate supplemental groups. For files there are more possible combinations because anyone who is a member of a group can create a SETGID directory and let other users create files in it. But in a typical system the number of groups is not much greater than the number of users the maximum number of groups is typically the number of users plus about 60. So if we had 100 users then the number of combinations of UID and GID would be something like 100*(100+60)=16,000 it should be possible to have that many domains in a SE Linux policy (but not desirable). Then all that would be needed is rules specifying that each domain (which is based on a combination of UID and GID) can have certain types of access to certain other types based on them having either the same UID or the same GID. Such a policy would be large, it would waste a lot of kernel memory, it would need to be regenerated whenever a user is added, and it s generally something you don t want to use. No-one has considered implementing such a policy, I merely describe it to illustrate why certain configuration options are not desirable. The rest of this post is about realistic things that you can do with SE Linux policy and how it will be implemented in Debian/Squeeze. My previous post titled Is SE Linux Unixish? addresses this issue at a more conceptual level and also considers MAC vs DAC [1]. The History of mapping Unix Accounts to SE Linux Access Control In the early releases of SE Linux (long before it was included in Fedora) every user who could login to a system needed to have their user-name compiled into the policy. The policy specified which roles the user could access, the roles specified which domains could be accessed, and therefore what the user could do. The identity of files on disk was used for two purposes, one was logging (you could see who created a file) and the other was a permission check for the SE Linux patched version of Vixie cron which would not execute any command on behalf of a user unless the identity on the crontab file in the cron spool matched the identity used to run it this is an analogy of the checks that Vixie cron makes on the Unix UID of the crontab file (some other cron daemons do fewer checks). Having to recompile policy source every time you added a user was annoying. So a later development was to allow arbitrary mappings between Unix account names and SE Linux Identities (which included a default identity) and another later development was to have a utility program semanage to map particular Unix account and group names to SE Linux identities. This was all done years ago. Fedora Core 5 which was released in 2006 had the modular policy which included these features (apart from mapping Unix groups to SE Linux identities which was more recent). Fedora Core 5 also introduced MCS which was comprised of a set of categories that a security context may have. The sysadmin would configure the set of categories that each account would have. A recent development has been a concept named UBAC (User Based Access Control) which basically means that a process running directly on behalf of a regular user (IE with a SE Linux identity that s not system_u) can only access files that have an identity of system_u or which have the same identity as the process. This means that you can only access your own files or system files not files of other users which may have inappropriate Unix permissions. So for example if a user with a SE Linux identity of john gives their home directory the Unix permission mode of 0777 then a user with a SE Linux identity of jane can t access their files. Of course this means that if you have a group of people working together on a project then they probably need to all have the same Identity and in practice you would probably end up with everyone having the same identity. I ve given up on the idea of using UBAC in Debian. The Current Plan for Users and SE Linux Access Control in Debian My plan is to have things work in Squeeze in much the same way as in Lenny. You have a SE Linux identity assigned to a login session and everything related to it (including cron jobs) based on the Unix account name or possibly the Unix group name (if there are login entries for both the user-name and the group-name then the user-name entry has precedence). The mapping between Unix accounts and SE Linux identities is configured by the sysadmin and SE Linux identities don t matter much for the Targeted configuration (which is what most people use). The identity determines which roles may be used and also has a limit on the MCS categories. The MCS categories are also specified in the login configuration which has to be a sub-set of the categories used by the identity record. So for example the following is the output of a couple of commands run on a Debian/Unstable system. They show that the test Unix account is assigned a SE Linux identity of staff_u and an MCS range of s0-s0:c1 (this means it creates files by default at level s0 and can also write to other files at that level, but can also have read/write access to files at the level s0:c1 ). The staff_u identity (as shown in the output of semanage user -l can be used with all categories in the set s0:c0.c1023 where the dot means the set of categories from c0 to c1023 inclusive) but in the case of the test user only one category will be used. The test group however (as expressed with %test ) is given the identity user_u and is not permitted to use any categories.

# semanage login -l
Login Name    SELinux User    MLS/MCS Range           
%test         user_u          s0                     
__default__   unconfined_u    s0-s0:c0.c1023         
root          unconfined_u    s0-s0:c0.c1023         
system_u      system_u        s0-s0:c0.c1023         
test          staff_u         s0-s0:c1               
# semanage user -l
             Labeling   MLS/       MLS/                         
SELinux User Prefix     MCS Level  MCS Range         SELinux Roles
root         sysadm     s0         s0-s0:c0.c1023    staff_r sysadm_r system_r
staff_u      staff      s0         s0-s0:c0.c1023    staff_r sysadm_r
sysadm_u     sysadm     s0         s0-s0:c0.c1023    sysadm_r
system_u     user       s0         s0-s0:c0.c1023    system_r
unconfined_u unconfined s0         s0-s0:c0.c1023    system_r unconfined_r
user_u       user       s0         s0                user_r

I hope to get the policy written to support multiple user roles in time for the release of Squeeze. If I don t make it then I will put such a policy on my own web site and try to get it included in an update. The policy currently basically works for a Targeted configuration where the users are not confined (apart from MCS). How MMCS Basically Works The vast majority of SE Linux users run with the MCS policy rather than the MLS policy. For Debian I have written a modified version of MCS that I call MMCS. MMCS is mandatory (you can t relabel files to escape it) and it prevents write-down. If a process has the range s0-s0:c1,c3 then it has full access to files labelled as s0, s0:c1, s0:c3, and s0:c1,c3 and any files it creates will be labeled as s0. If a process has the range s0:c1-s0:c1,c3 then it has read-only access to files labelled as s0 and s0:c3 and read-write access to files labelled as s0:c1 and s0:c1,c3. This means that any secret data it accesses that was labelled with category c1 can t be leaked down to a file that is not labelled with that category. Now MCS currently has no network access controls, so there s nothing stopping a user from using scp or other network utilities to transfer files. But that s the way with most usable systems. I don t think that this is necessarily a problem, the almost total lack of network access controls in a traditional Unix model doesn t seem to concern most people. Now to REALLY Answer that Question SE Linux is a Mandatory Access Control (MAC) system, this makes it inherently different to a Discretionary Access Control (DAC) system such as traditional Unix access controls. Unix permissions are based on each file having a UID, a GID, and a set of permissions and each process having a UID, a GID, and a set of supplementary GIDs. If a user runs a setuid or setgid program then the process will have extra privileges. It also has a lot of stuff that most people aren t aware of such as real vs effective UIDs, the tag bit, setgid directories, and lots more including some quite arbitrary things like making ports <1024 special. SE Linux is based on every object (process, file, socket, etc) having a single security label which includes an identity, a role, a type, and a sensitivity label (MCS categories or an MLS range). There is no support for an object to have more than one label. The SE Linux equivalent to setuid/setgid files is a label for a file which triggers a domain transition when it s executed. This differs from setuid files in that the domain transition is complete (the old privileges can t be restored) and the transition is generally not to a strict super-set of the access (usually a different sub-set of possible access and sometimes to lesser access). These differences are quite fundamental. So really SE Linux can t implement traditional Unix access control. What SE Linux is designed to do is to provide a second layer of defense and to also provide access controls that have different aims than that of Unix permissions such as being mandatory and implementing features such as MLS.

• [1] http://etbe.coker.com.au/2008/08/25/is-se-linux-unixish/

Moonshot is being discussed at the TERENA TNC 2010 conference. Our session started at 08:00 UTC (a few minutes ago), but will be going on for around the next hour or so. There is a presentation before Moonshot, but then Josh is up. See here for streaming and the Moonshot web site for our updated specifications. When the session is archived I ll post a pointer to the video stream.a

The Eurovision Song Contest has been and gone with a better-than-usual winner and much of the snarkiness was on microblog sites like identi.ca this year. Search for #ESC, #eurovision or incomprehensibly-to-me #eurovison (no second i is it spelt like that in some language, or can thousands not spell?). Anyway, enough of the title, on with the message I ve been irritated by my linphone SIP internet phone (Skype without lock-in, with standards) taking up my screen space for a while. I ve been meaning to upgrade to one of the recent versions that includes the linphonecsh shell and write some client that only displays windows when it s needed, but I ve been writing programs for work so much that I ve not even found time to write blog posts recently, much less fun code, so that s not happened. So I m quite happy to find linphone.el for my GNU Emacs text editor and find it mostly works. I changed one line at the end to (define-key global-map [menu-bar tools linphone] '("Linphone" . linphone)) to put it on the tools menu, but other than that, it just worked. Well, the Mute doesn t, but that s probably my phone headset being a different ALSA device. I don t care: I use the hardware mute button. In previous times, I would have added the link to the venerable EmacsWiki too, but it has the evil bad wrong Google reCaptcha on the edit page to stop disabled users, so screw it. Google s reCaptcha seems to be spreading again, obstructing more people when accessing more websites. Is there a reason for that? The re in reCaptcha stands for replace with real anti-spam, please! Anyway, now I m controlling phone calls from Emacs. Whatever next? Voice recognition, M-x doctor and a speech synth?

The following developers got their Debian accounts in the last month:

• Scott Kitterman (kitterman)
• Dominique Belhachemi (domibel)
• Sylvain Beucler (beuc)
• Alessio Treglia (alessio)
• Giovanni Mascellani (gio)
• Ulises Vitulli (dererk)
• Tommi Vainikainen (tvainika)
• Serafeim Zanikolas (sez)
• Hideki Yamane (henrich)
• Obey Arthur Liu (arthurliu)
• Thierry Soloniaina Randrianiriana (thierry)
• Thomas Weber (tweber)
• Mikhail Gusarov (dottedmag)
• Ritesh Sarraf (rrs)
• Kanru Chen (koster)

Congratulations!

This should solve the yurt's bed problem. Over the past two years I've learned there are really two: It's not a fully dry environment so anything left on the floor will mildew; and the yurt makes no pretense of having a level floor. Thus this custom bed with independently levelable legs, custom sized to hold together a multipart matress. In keeping with the yurt thing, it's disassemblable and portable, but not too easily. :) Couldn't have been done without Mark's skilled ripping of the plywood. Anna cut the smaller boards and assisted, and we were very happy with what we managed to accomplish in a few hours. It's sturdy, and even level.

Two years ago, while working on awesome, I joined the Freedesktop initiative to work on XCB. I had to learn the arcane of the X11 protocol and all the mysterious and old world that goes with it. Now that I've swum all this months in this mud, I just feel like I need to share my thoughts about what become a mess over the decades. When I was unborn

the Toto band were releasing their song "Africa" and some smart guys were working on a windowing system: the X Window System (this is its full name) which therefore has a (too) long history. The latest version of its protocol, the 11th one, has been designed in the 80's. You can learn more about the history in the Wikipedia article about X. In 2010, we still listen disco music and we still use various protocols designed in the 80's and even before X. Music have evolved, protocols have evolved, and so did X11. The problem is that X11 did not evolve that well. The guys at MIT-and-some other-places-with-very-smart-people-in-it created X version 1 in 1984, and updated it until X version 11 (the one we're still using) in 1987. Eleven version in 3 years, that was following the "release early, release often" model. But I don't know why, it just stopped to happen for the last 23 years¹. I don't know what changes have been made in the first 11 major versions of the X protocol, but I'm rather sure we should have deserve a couple of major version updates this last 2 decades. In my humble opinion, X11 was not designed to live 23 years. But hey, I'm not blaming anyone here: I was 4 years old and playing Lego when they released this latest version of the X protocol, so there is little chance I'd have done something better.

1. That's not totally true: they added (and then deprecated) many extensions. We won't fix. We'll work-around.

That is probably one of the guideline of the X protocol for the last years. And don't misread me: I'm not bashing anyone thereafter. Since the X11 protocol was aging, the X guys started to add extensions. They added tons of them over the years. This, in application of one of the early principles of X:

It is as important to decide what a system is not as to decide what it is. Do not serve all the world's needs; rather, make the system extensible so that additional needs can be met in an upwardly compatible fashion.

All of them with no exception were added because, bad luck, the X11 protocol did not anticipated the things that happened in the last 23 years, like video, OpenGL, multiple monitors, or the pleasure to draw oval windows. Some of this extensions are still in use, while some of them have been dropped. While this is not a bad thing to extends the protocol, it seems like a bad thing to try to fix the protocol with for example the XFixes extension, even with all the good intentions Keith Packard might have in his greatness. Actually it's even worst than you think

The X11 protocol (without extensions) defines about 120 types of requests: create a window, move a window, etc. Nowadays, there's at least 25 % of them which are useless: usage of server-side font, or the drawing of squares and polygon, are unused by any modern application or toolkit. All of this is superseded by requests from extensions, like the XRender one. The handling of multiple monitors displays has totally been screwed up. X11 has been designed to work in Zaphod mode (independent monitors). But Xinerama, and nowadays XRandR have replaced it up: recent X servers (released after ~2007) does not support Zaphod mode anymore, even if it's a core piece of the X11 protocol. Worst: on many requests, there's limitation or design flaws, like described in this document: Why X Is Not Our Ideal Window System by DEC researchers. We'll add more broken standard on top of that

Following its early principle, X does not define policies but only mechanisms, which seems like a good thing, Consequently, people started writing specifications to determine a number of stuff and dogmas: ICCCM. That was 22 years ago in 1988. It's useless to add that many things in this specification are now obsolete, useless, or that it misses many modern stuff. I was not the only one to think that. The people from what will be the major desktop environments, KDE and GNOME, saw that too in the 90's while I was learning to count. So they wrote EWMH, another standard that comes on top of ICCCM and extends it with nifty features like maximization, full screen mode, etc. The problem is that this standard has also been written by narrow-minded people who at that time, were working on GNOME or KDE (and maybe others). This desktop environments were having and still have some strong concepts of how should work a desktop: "it should have work-spaces", "a window is only on one workspace", "we only see a workspace at a time", "you do not have multiple screens", etc. Dude, we don't care: we have toolkits!

This vision of how the desktop should work have now been written in marble in all applications and libraries implementing EWMH, like GTK+ or Qt. Nowadays, everybody forgot about all of this standards. Toolkits have implemented this, circumvented the X11 protocol limitation and flaws, and nobody wants to look back. Like all standards, obviously some people implemented them badly. This had some side effects, like OpenOffice acting like a pager. We don't look back? Worst, we forgot where we came from!

With all these layers of bad designed standards, the desktop continued to evolve for more than a decade. They continued to add more standard, the more recent ones being based on D-Bus like the Desktop Notification Specification or the latest Status Notifier Specification developed by KDE. The Status Notifier is a new implementation of the good old system tray based on XEmbed, using D-Bus instead of the X11 mechanisms, and adding the possibility to show the system tray with something else than icons. This specification draft saw an important issue and design flaw raised by Wolfgang Draxinger in this thread on the XDG mailing-list. What Wolfgang points out, is that X is network-oriented, and D-Bus is not. Therefore, making the Status Notifier specification to use D-Bus to pass system tray messages around is a bad idea, since running a X application from host A on host B will draw the system tray on the wrong host! Apparently, reading the thread, this does not fear some of the KDE people:

of course this is a bizarre corner case not worth much thought. at least that's what you'll think until you actually run into it yourself (be it because you are testing something or because you are setting up some weird kiosk environment).

What Oswald describes as a corner case is an actual common use case for many of us. Of course, YMMV. From my point of view, this is a step back in the wrong direction. But we can conclude that the network part of X is now worthless, to at least KDE. I used to believe in XCB

When I joined Freedesktop, it was to work on XCB, the X C Binding. XCB is a nice, clean, 21st century technology based API to play with the X11 protocol. Its code is auto generated based on XML file describing the protocol. In comparison, Xlib is 80's obfuscated code with almost no comments and hard-coded things. Only a few people can understand some of its corner like its i18n or XKB implementations. And all its code is synchronous. For people not knowing it yet, X is a network protocol where you send request (like a GET in HTTP) and then get a response. Xlib forces the application to wait for the reply to its request, so the application is blocked until the X server sends the reply to the request. XCB on the other hand does not block and allows the application to send a batch of requests, do some other stuff in the mean time, and then gets the replies. It's like your Web browser would send one request at a time to a Web server, and would wait until you downloaded all the images one by one to display the page. In cases where X and all its clients are on the same host, the latency is small and not really visible, therefore the gain for XCB to be asynchronous is small. On slow network however, the gain can be huge, as proved in the rewrite of xlsclients with XCB by Peter Harris. One of the long standing goal of the XCB folks is to kick-out Xlib, to increase speed and hides latency in X11 applications. That requires to port many libraries, because almost none of them (Cairo being an exception) supports XCB. From where I stand, I don't really see if the work is worth it now. The desktop world is trusted by GNOME and KDE, meaning GTK+ and Qt. It seems none of this toolkits are interested to work on XCB, neither on the X protocol. They probably put hard effort in bypassing X limitation and flaws, and they now sit on top of crap of workarounds and broken-by-design-standard implementation. It seems to me they don't want to go back in the layers and improves things. They're too high to go back down and they don't see what the gain would be. Enlightenment with its EFL was the first toolkit to have an XCB back-end with the work of Vincent Torri. Unfortunately, the back-end is not maintained and nobody cares about it. Last time I tried it, it did not compile at all. X12 ?

There's a page called X12 on the Freedesktop wiki, listing all the things that should be fixed some days. Unfortunately, the list continues to grow up an no one talks about working on X12. On the other hand, there's a handset of people trying to work when they will have time on XKB2, the second version of the "let's-try-to-fix-up-the keyboard-part-of-the-protocol-we-wrote-23-years-ago-a-second-time" extension. To me, it does not seem X12 will happen in the next decade neither. Alternative ?

Do we got alternative to X ? There's Wayland, but it's far from being usable. There's DirectFB, but that's not very portable. None seems candidate to replace X some days to me. Anyhow, none of the main toolkits around support this alternative. GTK+ once supported DirectFB, but as far as I know, it is not supported nor works nowadays, as stated by Josselin Mouette. This is why recent versions of the Debian installer have migrated to X for the graphic part, thanks to Cyril Brulebois work. Conclusion

XCB has been around for more than half-a-decade, and very few people showed interested in it. As far as I can see, nobody is interested to use the X protocol and everybody tries to encapsulate it in some higher-level API as soon as possible to stop seeing it. This leads to poorly written application and toolkits, with a lot of ugly hack. All of that also means that starting to write applications and graphical toolkits based on XCB would be a very interesting project, but that would lead to spend too much time learning to circumvent the X protocol flaws, things that have been done in years by predecessors like Qt and GTK+. Major toolkits implementations have almost nothing to win in going back in the dark water of X. I guess most of their folks prefer to work on shiny 3D effects based on your GPS location, rather than redefining better basis for everyone. The manpower available in the X world is very small. Debian lacking of X maintainers is just the summit of that. There is very smart and very competent and skilled guys in the X world, as you can see by simply reading blog posts on Planet Freedesktop for example (me excluded). Unfortunately, there's not enough of them to cover all the things involved in X: input devices, graphics devices, new protocol extension specification and so on. The X server is really late, and it seems most of the developers prefers to work on the server itself than on the protocol behalf. Which is understandable. I'm curious to see where all of that will lead in the upcoming years. I've been walking in the X world hallways for about 3 years now, and I feel desktop alternatives to KDE and GNOME will all die sooner or later. The time were you could choose between a dozen "modern" window managers has passed away. After all, maybe that is simply Darwinism applied to computer software.

multistrap is gaining some important functionality. When preparing a root filesystem for a new product, the sources used to generate the system need to be made available. So, multistrap has an option to retain the sources and 2.1.5 adds the functionality of downloading the source packages to go alongside the binaries that are downloaded to make the system itself, into a directory outside the final system.

Equally, 2.1.5 includes the idea (contributed by Rodolfo Giometti) of not listing deb-src entries inside the final filesystem - a useful idea to save space on systems where there is no likelihood of sources actually being downloaded "on-device".

Also in 2.1.5, is a handler for device tables. udev is one thing but when creating new systems from scratch, some devices still need to be created with mknod. MAKEDEV is too general, creating dozens of nodes when maybe only a handful are needed yet also omitting device nodes that actually are needed. So, /usr/share/multistrap/device-table.pl can parse a mini device table file (a tab-separated-value file), creating directories, symlinks and device nodes in a specified directory.

The aim is to combine the entire generation of a bootable root filesystem in a single call to multistrap - to which two further steps are necessary.

1. Packing up into a tarball at the end


2. Running a customised script outside the eventual filesystem, passing it the location and architecture of the filesystem.

Both are in 2.1.5 - the config script can be used to pre-seed debconf questions, write out custom configuration changes, run the device table parser and various other tasks.

As with earlier versions, multistrap supports creating package building chroots (including cross-building chroots) and, to go alongside this functionality, pdebuild-cross has now entered unstable. pdebuild-cross is a set of hooks for pbuilder to support cross-building inside a pbuilder chroot created by multistrap.

I'm hoping to be able to cover more about these issues at DebConf10.

If debootstrap is not doing what you need, multistrap is probably the answer - and if it doesn't quite do what you need yet, ask.

My project This week I followed an advice of my mentor, Simon Marlow, and started to play with the code including print statements in interesting places in order to understand it s flow. It s indeed much better than just reading the source code and the documentation on the wiki. As usual, I had a lot of doubts about some parts of the code, and noted them down. But now, I m seeing that I m resolving most of them just by playing more with the code, without need to ask in the mailing list. There are still some left, and I m planning to send them to the list in a next oportunity. The first thing I noticed was the high number of objects, from my perspective, that are created and collected in: main = return () I measured how much times evacuate() was called. This function moves an object to the next generation of the Garbage Collector. It s called 775 times, in 1 call to GarbageCollect(), with 479 different objects (with different pointers to their Info Tables). Also, there were pinned objects and large objects in this count. This was surprising to me. I also made a small draw of the memory allocation in lines using diagrams. The draw: The source code: import Prelude hiding (tan)
import Control.Monad
import Data.Colour.RGBSpace
import Data.List
import Graphics.Rendering.Diagrams
import System.Random objectMaxLength :: Double
objectMaxLength = 50 objectMinLength :: Double
objectMinLength = 10 nObjects :: Int
nObjects = 10 main :: IO ()
main
= do
objects <- replicateM nObjects $ randomRIO (objectMinLength, objectMaxLength)
let objects = [18,50,12,46,16,41,14,30,49,23]
renderAs PNG "mem.png" Auto
$ vsep
10
[text 40 "(1)" <> continuous objects
, text 40 "(2)" <> lineByLine objects
, text 40 "(3)" <> allocated] continuous :: [Double] -> Diagram
continuous = memory colors lineByLine :: [Double] -> Diagram
lineByLine = memory (intersperse white colors ++ [white]) . objectsLine allocated :: Diagram
allocated
= memory
(intersperse white colors ++ [white])
[18, 82, 50, 0, 12, 0, 46, 0, 16, 0, 41, 35, 14, 0, 30, 0, 49, 7, 23] objectsLine :: [Double] -> [Double]
objectsLine [] = []
objectsLine (x : xs) = x : objectMaxLength x : objectsLine xs memory :: Color color => [color] -> [Double] -> Diagram
memory colours objects
= unionA
top
left
[hcat
$ map (uncurry fc)
$ zip (cycle colours)
$ map (lw 0 . flip rect objectMaxLength) objects
, lines_] lines_ :: Diagram
lines_ = hcat $ replicate nObjects $ rect objectMaxLength 50 colors :: (Ord colour, Floating colour) => [Colour colour]
colors
= [red, green, blue, yellow, magenta, cyan
, darkred, darkgreen, darkblue, darkmagenta, darkcyan]