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.

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 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/

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.

If you find yourself trying to pre-empt accusations of unfairness by coming up with plausible explanations, this should be a clear and obvious indication that you are about to do something unfair and wrong. If you are being accused of unfairness and are trying to think of ways to defend against this criticism, it means you probably already have done something unfair and wrong. It also means that you probably have too much power.

It's Memorial Day weekend so it was time for the Chicago's JP Morgan Chase Corporate Challenge on Thursday. The weather was glorious, the usual 20-some thousand runners participated and a good time was had. Work had arranged for a nice tent, food, music --- and a bunch of people showed up and enjoyed it. Nice one. This time we all got chip-timing via a small (rfid ?) strip tagged to back of the bib number. Which is handy as I managed to not stop my time by hand correctly. Given that I am still nursing a sore Achilles tendon and don't train well or much, the time of 23:51 (or 6:48 min/mile) was ok compared to the other seven previous times I have run this.

Last week was very busy for me. Unfortunately, I spent most of my time no my study duties. An exam session is fast approaching, so in next 3 weeks the situation will not be better. But as I promised, during second part of week, I am working full time on my project.

So, here are missing mockups of future Aptitude Qt GUI:

Changes Preview tab:

Only one "Preview Tab" can be opened at the same time. Changes will be live updated here.

Resolver:

Perform Changes tab:


This time I am not too innovative. I think that current Aptitude GTK design for this tabs is quite intuitive and good-looking, so I have added only minor tweaks.

To sum up mockups topic, below are links to all presented mockups (with some comments which raises during my recent private discussions). Now, I am open for any suggestions and comments about current design. At the end of next week, second iteration will be presented. Depending of the level of required changes there could be third iteration, before sending mockups to Piotr "Patpi" Pe zowski, who is the person behind Kadu Usability Project. I am glad that he agreed to spend his spare time and help me with this task :)

Packages tab:

This tab in second iteration will have only small changes. I was told that will be nice to select multiple categories at the same time. I agree, so categories list will support multi selection. There will be also an option in configuration window (There is no mockup now. Currently, I do not know what option will be configurable and it is not the most important thing at this stage. The window will be patterned upon KDE configuration windows) to move this list on the right side of this tab.

It will be possible to have multiple "Packages tabs" opened at the same time. It will not be allowed to close first "Package Tab". Ctrl + T shortcut, action in main menu and toolbar (I have forgotten about toolbar in this iteration - maybe it is not necessary?) will open new tab. There will be also an option that each text search will do this. I will try to add shortcuts wherever is it possible to allow using the GUI without mouse.

"Show changes" button will be change to "Resolve dependencies" when necessary.

Updates widget:

Most of the comments from "Packages tab" apply here too. In the table showing updates will be also "Current Version" column.


Package Informations tab:

Only one clarification: multiple "Packages Informations" tabs for the same package will not be allowed.

I am looking forward to read any comments regarding presented design. Please leave comment below this post or contact me directly (see About Me page).

On Monday/Tuesday I will write first weekly report.

Cheers.

Hello all.

Last week I was very busy, due to my university duties. On Tuesday I had my first exam in this semester (in Numerical Analysis), which took me more time than I had thought it would be.
From this reason my project is slightly behind schedule, but now I will do my best to catch the plan.

On the other hand, there are also some good news for me. Some time ago, Daniel Burrows migrated aptitude repository from mercurial to GIT. I am git user for nearly year, so I strongly support this move ;) .

Here are some basic thoughts which functionalities good package manager must have (and which approach (from aptitude-gtk, synaptic and adept) I like the most):

• upgrade packeges with good conflict resolution - aptitude conflict resolver is the most advanced. Without a doubt, it has to be in Qt version
• fast searching and installing new packages - I prefer synaptic/yast approach with categories on the left and packages on the right, with single click behavior from KPackegeKit/adept (single click shows package description under selected package and with detailed informations available in new tab - as in aptitude-gtk)
• viewing detailed package informations
• downgrading, holding etc
• fetching packages list, cleaning cache etc

All of this will be elaborated in mockups. Am I forgetting something important?

The most important questions is: "What is the most common use case for package manager? Installing packages or upgrading packages?". I am not sure if this two actions require different views, or there should be only new category in install package view.

This is all now. More updates (and mockups) will be available today's midnight (or tomorrow morning). So please stay tuned :)

Hello Planet Debian readers!

I've never thought that such a thing can ever happen, but I've started blogging ;) So now it is time to introduce myself.

My name is Piotr Galiszewski and I am second year student of computer science at AGH - University of Science and Technology in Krakow (Poland). I have been GNU/Linux user for about 5 years (mostly Debian based distributions).

Thanks for Debian and Google, this summer I will be working on creating Qt-based user interface for aptitude as my Google Summer of Code project. I hope that my mentors Sune Vuorela and Daniel Barrows will be patient with me ;) I am sure I will learn a lot from them. Please look at abstract of my project made by Debian GSoC administrator Obey Arthur Liu:

Qt GUI for aptitude. Currently, KDE users need to use Aptitude via the console interface, or install the newly developed GTK frontend, which does not fit well into KDE desktop. Making Qt frontend to Aptitude would solve this problem and bring an advanced and fully Debian-compliant graphical package manager to KDE.

As I wrote in my proposal I will split my work into three main parts:

1. writing low level classes which will abstract aptitude signals and slots (which uses sigc++) into Qt slots and signals.
2. creating and evaluating GUI mockups
3. implementing GUI on top of classes from the first point

Point 1 and 2 will be made simultaneously and will take all May and half of June. Low level classes should implement all necessary functions for further use in GUI. This classes allow me to avoid direct usage of none Qt code in GUI classes and also give much more time to prepare completed and usability-wise mockups. Every mockups version will be presented and discussed on this blog. First version should be ready in next few days and updates will appear each week (or to weeks).
After finishing this two steps I will start coding GUI. With mockups and finished low level classes this should not be complicated (Yeah, I know that this is only my dream).

Full text of my proposal (including more precise time-line) can be found at Debian wiki.

Currently, project is slightly behind the schedule . It is caused by changes in my studies plan. The Juwanalia students' festival took place earlier, and yesterday it finished. But my first exam will take place one week later on 18 May, so I will have more time to catch up with time-line.

This project is my first direct contribution to Debian, but not first involvement in free software movement. I've been Kadu Instant Messenger developer for more then two year. In last two years I have been second most active developer with more than 700 commits in master branch. During GSoC period my Kadu activities will be limited. If time allows me to do this, I will be still contributing to Kadu. I still can be found at Kadu forum or #kadu channel on irc.freenode.net. I will also continue reviewing patches and fixing low time-consuming bugs.

My plans for the next few days:

• continue researching aptitude codebase
• discover all functionalities that should be implemented by Qt frontend
• review of other graphical package manager GUIs (and probably write about my thoughts on this blog)
• create first draft of my mockups

If you have any thoughts about this project, please add comment to this post or contact me directly. I will be glad to read all yours opinions

Cheers

PS. As you can see English is not my mother tongue, so please forgive me my mistakes

With the 10.10 developer summit behind us, several teams have published engineering plans for the 10.10 release cycle, including:

• The Desktop team plan, via Rick Spencer, includes both Desktop Edition and Netbook Edition, and covers Software Center, GNOME, application and browser selection (including Chromium), X11 and social networking
• The Server team plan, via Jos Boumans, covers migrating services to Upstart, improvements to the mail stack, cloud and cluster storage systems, cloud deployment and load balancing, Ubuntu Enterprise Cloud, and Java
• The Foundations team plan, via Duncan McGreggor, covers system initialization, btrfs, cleaning house, improvements to the installers, Software Center (also) and Upstart (itself), along with a batch of miscellaneous projects, including compiling Ubuntu for the i686 instruction set
• The Kernel team plan, via Leann Ogasawara, covers the choice of kernel 2.6.35, the current Ubuntu patch set, the configuration of our various kernel flavours, bug management, and the availability of backports of newer kernels to Ubuntu LTS releases

The python-pykickstart package just landed in sid. If you wish to create or modify your kickstart configuration file from python, pykickstart is developed by Redhat fellows in order to make your job with kickstart easier. Kickstart aims to make automated systems installations for redhat/fedora.

The last weeks, I've occasionally been contributing to Wikipedia. I must say, Wikipedia is a really odd world of its own. Another thing I found quite surprising is the difference between the English and the German Wikipedia.Some things I noticed:

• Some information in Wikipedia is grossly inaccurate. Interestingly, this even applies to computer science topics as simple as database indexes.
• A lot of the time, you meet users that 'defend' 'their' pages to any changes, as if they were the sole expert on this subject
• There appear to be plenty of zealots^W users with their life focused on deleting things from Wikipedia they do not consider "notable". This goes as far as the German Wikipedia having an initative called "Improve, don't delete" or the "Article Rescue Squad" in English Wikipedia
• English Wikipedia suffers a lot from link spam, despite "nofollow". In 'hot' (commercially, not on Wikipedia) topics such as "knowledge management" (yes, the "knowledge management" article on Wikipedia is crap, despite Wikis often being called "knowledge management"), half of the edits are link spam and reversals. There also is a lot of bookspam and citation spam, resulting in badly written articles where half of the article is unsorted and only partially relevant literature. In German Wikipedia, this seems to be a lot less of an issue.
• In general, German Wikipedia seems to be a lot more patrolled against changes (in particular links), but often is both less complete and less accurate.

So on overall: keep away from Wikipedia contributors, they're all maniacs. And often, don't bother to read a Wikipedia article if you can get an appropriate textbook. The Wikipedia article will just try to sell you a dozen textbooks anyway; you'll also have to read them to check the validity.It is a pity, that despite its size and "eyeballs", Wikipedia so far seems to have not attracted much attention by actual "domain experts", but it seems that it is largely filled by bureocrats, zealots and promoters. (That don't have any real work to do?)There are many things wrong here, that have been pointed out by many others, too. I'm not going to rescue the Wikipedia world, either. And yes, I am aware that you can discuss in Wikipedia, too.

• Good articles get more contributions. Nobody cares for the black sheep. It probably gives just much more gratitude to turn a good article into an excellent one, than turning a bad one into an okay one.
• Wikipedia at the same time tries to be exhaustive and maintain a certain "notability". This ends in people creating articles (because they're missing) and others then deleting them (because they consider them "not notable"). This is very discouraging to users that might even be experts on that subject they have been adding. (See also "the rich get richer" in this blog rant)
• New articles get extra attention, and often are attacked quickly for either quality or notability (despite WP:IMPERFECT), while articles that have been bad for years are barely re-checked. The categories listing Articles that need expansion and Articles that need cleanup are getting out of control, at 58000+ articles for the latter. Articles "lacking sources" is at 340.000+ articles. That is 1 out of 10.
• In fact, Wikipedia even has 138 "cleanup categories". Did I mention it is run by bureocrats, not by domain experts?

I fear that Wikipedia will go the DMOZ road. There was a time that DMOZ was doing quite well. Nowadays, large parts of DMOZ are dead. For two main reasons: it's hard to get in, and the backlog is way too large. If you get into DMOZ for a larger category, you'll be faced with thousands of pending link submissions, where for a large part you don't feel qualified to judge on appropriateness or rewrite their description in a neural manner. I have the impression that the same is happening for Wikipedia: on one hand, users that join are often kicked badly for many of their first contributions and will just leave again. At the same time, many of the old articles are in desparate need for attention, but nobody of the established users is willing to spend the days of cleanup/rewriting needed to get the article into a useful shape again. And a new user will never dare to discard most of the existing article; they usually just add or modify single paragraphs to see what happens. So Wikipedia might be hitting some kind of barrier.Still, I have to admit that I frequently use Wikipedia to look up things. Usually because it just comes up first in Google. I then often follow links to better resources, such as MathWorld. And I wish, Google would have taken me there right away ...And don't assume I'd know how to run things better. I'd sure propose to spend more time at fixing existing articles instead of attacking new contributions that much (you'll lose contributors this way). But I also see the need for fighting spam (although you should also remove old spam ...). But I don't know if there is a solution that will actually attract domain experts to re-write all the badly written and inaccurate articles that don't have their personal zealot to patrol them.P.S. Sorry, no comments on my blog. This isn't Facebook. Instead of commenting on my blog, how about working on Wikipedias backlog instead?P.S. Another example is the German Wikipedia story surrounding Fefe's blog. Many here at the open source communities will know fefe for his work on Dietlibc, libowfat and similar highly respected open source projects. His blog has been famous for being high-quality in security, privacy topics, politics and media critics. Some of his fans (likely) started a Wikipedia page on his blog. There have been at least two huge discussions about deleting the Wikipedia page. "sock puppets" and all such things have been brought up, while Fefe himself was amused. The discussions around deleting the blogs page on Wikipedia made it all the way to the print newspapers. As I said, I'm not actually bringing up new critique on Wikipedia. It's an ongoing problem for years now.[Insert random Deletionism rant against Wikipedia]

So, yesterday was my 0 14 (20th) birthday and Germany won the Eurovision Song Contest 2010. Next up is Formula One in Turkey and Sebastian Vettel starting from position 3, hopefully he manages to overtake Hamilton and Webber and win this race. Let s see
Filed under: General

Martin Meredith wrote a blog post about logging in as root and the people who so strongly advocate against it [1]. The question is whether you should ssh directly to the root account on a remote server or whether you should ssh to a non-root account and use sudo or su to gain administrative privileges. Does sudo/su make your system more secure? Some years ago the administrator of a SE Linux Play Machine used the same home directory for play users to login as for administrative logins as for his own logins he used newrole to gain administrative access (like su or sudo but for SE Linux). His machine was owned by one of his friends who created a shell function named newrole in one of his login scripts that used netcat to send the administrative password out over the net. He didn t immediately realise that this was a problem until his friend changed the password and locked him out! This is one example of a system being 0wned due to having the double-authentication of course if he had logged in directly with administrative privs while using the same home directory that the attacker could write to then he would still have lost but the attacker would have had to do a little more work. When you login you have lots of shell scripts run on your behalf which have the ability to totally control your environment, if someone has taken over those scripts then they can control everything you see, when you think you run sudo or something they can get the password. When you ssh in to a server your security relies on the security of the client end-point, the encryption of the ssh protocol (including keeping all keys secure to prevent MITM attacks), and the integrity of all the programs that are executed before you have control of the remote system. One benefit for using sshd to spawn a session without full privileges is in the case where you fear an exploit against sshd and are running SE Linux or some other security system that goes way beyond Unix permissions. It is possible to configure SE Linux in the strict configuration to deny administrative rights to any shell that is launched directly by the sshd. Therefore someone who cracks sshd could only wait until an administrator logs in and runs newrole and they wouldn t be able to immediately take over the system. If the sysadmin suspected that a sshd compromise is possible then a sysadmin could login through some other method (maybe visit the server and login at the console) to upgrade the sshd. This is however a very unusual scenario and I suspect that most people who advocate using sudo exclusively don t use a SE Linux strict configuration. Does su/sudo improve auditing? If you have multiple people with root access to one system it can be difficult to determine who did what. If you force everyone to use su or sudo then you will have a record of which Unix account was used to start the root session. Of course if multiple people start root shells via su and leave them running then it can be difficult to determine which of the people who had such shells running made the mistake but at least that reduces the list of suspects. If you put PermitUserEnvironment yes in /etc/ssh/sshd_config then you have the option of setting environment variables by ssh authorized_keys entries, so you could have an entry such as the following: environment= ORIG_USER=john@example.com ssh-rsa AAAAB3Nz[...]/w== john@example.com Then you could have the .bashrc file (or a similar file for your favorite shell) have code such as the following to log the relevant data to syslogd:
if [ "$SSH_TTY" = "" ]; then
logger -p auth.info "user $ORIG_USER ran command \"$BASH_EXECUTION_STRING\" as root"
else
logger -p auth.info "user $ORIG_USER logged in as root on tty $(tty)"
fi I think that forcing the use of su or sudo might improve the ability to track other sysadmins if the system is not well configured. But it seems obvious that the same level of tracking can be implemented in other ways with a small amount of effort. It took me about 30 minutes to devise the above shell code and configuration options, it should take people who read this blog post about 5 minutes to implement it (or maybe 10 minutes if they use a different shell or have some other combination of Bash configuration that results in non-obvious use of initialisation scripts (EG if you have a .bash_profile file then .bashrc may not be executed). Once you have the above infrastructure for logging root login sessions it wouldn t be difficult to run a little script that asks the sysadmin what is the purpose for your root login and logs what they type. If several sysadmins are logged in at the same time and one of them describes the purpose of their login as to reconfigure LDAP then you know who to talk to if your LDAP server stops working! Should you run commands with minimum privilege? It s generally regarded that running each command with the minimum privilege is a good idea. But if the only reason you login to a server is to do root tasks (restarting daemons, writing to files that are owned by root, etc) then there really isn t a lot of potential for achieving anything by doing so. If you need to use a client for a particular service (EG a web browser to test the functionality of a web server or proxy server) then you can login to a different account for that purpose the typical sysadmin desktop has a dozen xterms open at once, using one for root access to do the work and another for non-root access to do the testing is probably a good option. Can root be used for local access? Linux Journal has an article about the distribution that used to be known as Lindows (later Linspire) which used root as the default login for desktop use [2]. It suggests using a non-root account because If someone can trick you into running a program or if a virus somehow runs while you are logged in, that program then has the ability to do anything at all of course someone could trick you into running a program or virus that attempts to run sudo (to see if you enabled it without password checks) and if that doesn t work waits until you run sudo and sniffs the password (using pty interception or X event sniffing). The article does correctly note that you can easily accidentally damage your system as root. Given that the skills of typical Linux desktop users are significantly less than those of typical system administrators it seems reasonable to assume that certain risks of mistake which are significant for desktop users aren t a big deal with skilled sysadmins. I think that it was a bad decision by the Lindows people to use root for everything due to the risk of errors. If you make a mistake on a desktop system as non-root then if your home directory was backed up recently and you use IMAP or caching IMAP for email access then you probably won t lose much of note. But if you make a serious mistake as root then the minimum damage is being forced to do a complete reinstall, which is time consuming and annoying even if you have the installation media handy and your Internet connection has enough quota for the month to complete the process. Finally there are some services that seek out people who use the root account for desktop use. Debian has some support channels on IRC [3] and I decided to use the root account from my SE Linux Play Machine [4] to see how they go. #debian has banned strings matching root. #linpeople didn t like me because Deopped you on channel #linpeople because it is registered with channel services . #linuxhelp and #help let me in, but nothing seemed to be happening in those channels. Last time I tried this experiment I had a minor debate with someone who repeated a mantra about not using root and didn t show any interest in reading my explanation of why root:user_r:user_t is safe for IRC. I can t imagine that good the #debian people expect to gain from denying people the ability to access that channel with an IRC client that reports itself to be running as root. Doing so precludes the possibility of educating them if you think that they are doing something wrong (such as running a distribution like Lindows/Linspire). Conclusion I routinely ssh directly to servers as root. I ve been doing so for as long as ssh has been around and I used to telnet to systems as root before that. Logging in to a server as root without encryption is in most cases a really bad idea, but before ssh was invented it was the only option that was available. For the vast majority of server deployments I think that there is no good reason to avoid sshing directly as root.

• [1] http://www.sourceguru.net/login-root/
• [2] http://www.linuxjournal.com/article/7166
• [3] http://www.debian.org/support
• [4] http://www.coker.com.au/selinux/play.html

As some of you might have seen, KOffice 2.2.0 was finally released today. Quoting the release announcement: There are still areas in the user interface that we want to work on before stating that KOffice is fit for the general public. We are, however, at a stage where we think that KOffice can be used for real work by some users.
I agree with this statement and it is still to be decided if KOffice 2.2.0 will make it into Squeeze. I am inclined to do so but I would love some well argumented feedback. Take into consideration some applications are more mature than others. The packages will be uploaded to the official archive soon, but they still need some minor work and given they include new deb files (kformula shape and kexi), they need to go thru the NEW queue, it might take some time. Meanwhile, you can find packages for amd64 & i386 from the semi-official repository at: http://qt-kde.debian.net/.
You also have available the localization packages (see the list here) and braindump, an interesting application based in KOffice libraries. These packages are not in the Debian archive so please *don t* report bugs against them in the Debian Bug Tracking System. If you see any packaging problem, please report it in the debian-kde mailing list.
If you find a bug, miss a feature or have a wishlist, please file a report in the KDE bugzilla: https://bugs.kde.org/ Include all the information you can about your system (Debian experimental, KOffice 2.2.0) and all the details you are able to give. In the case of crashes, install the package koffice-dbg to get a backtrace. Read more at this techbase article.

why Debian for scientific computing: a case study Yesterday I've been invited to visit EDF R&D center at Clamart, near Paris. They wanted to discuss their Debian usage and present some of the cool stuff they're doing. The most interesting component is an in-house Debian-based distribution called "calibre", which has been presented at RMLL 2008. Even though it is now growing desktop profiles (currently deployed on about 1'200 desktops and counting), calibre was mainly developed for clusters dedicated to scientific computing. Current cluster deployments at EDF are not that big, but still comprise hundreds of machines for about 40 teraFLOPS, with their largest cluster in Top 500. The main goal of calibre was to quickly bring a complete cluster from the bare metal to production state. The goal has been quite successfully achieved: using Debian and FAI they get a cluster of 200 machines ready for production in about 1 hour and a half, installing more than 3'000 packages on each machine (as the cluster will be used for heterogeneous purposes, rather than for a handful of specific applications). What I found most interesting of the visit are the reasons for choosing Debian over other (commercial) distros for their scientific computing purposes:

• They use a wide range of open source scientific softwares (some developed in house): according to their claims Debian is the mainstream distribution with the largest offering of such software, with the additional benefit that corresponding Debian maintainers are experts of the software they package, so that they can trust them. They have kudos for Debian Science, which I'm happy to proxy.
• They need to rebuild packages to trigger specific optimizations for their clusters. On one hand, that defeats the typical management argument of "commercial support" that other distros offer, as rebuilding packages void support guarantees.
• On the other hand, it really helps them the focus on quality that we do have on Debian: we fight FTBFSs to death, and people which need to rebuild our packages really appreciate that.

EDF is generally keen of contributing back to Debian (even though the team behind calibre is still small), and I've been happy to walk them through how they can contribute. The last interesting feedback I've to share, is that they feel a bit alone in what they're doing (which is unsurprisingly, given that their communication on the matter has been rather limited thus far ...). Still, there is probably room for synergies that can be better exploited among users with similar needs. So, are you a cluster / scientific computing user of Debian? Then let me know, and I'll be happy to get you in touch with EDF and other users with similar interests.

Debian-based scientific computing at EDF Yesterday I've been invited to visit EDF R&D center at Clamart, near Paris. They wanted to discuss their Debian usage and present some of the cool stuff they're doing. The most interesting component is an in-house Debian-based distribution called "calibre", whish has been presented at RMLL 2008. Even though it is now growing desktop profiles (currently deployed on about 1'200 desktops and counting), calibre was mainly developed for clusters dedicated to scientific computing. Current cluster deployments at EDF are not that big, but still comprise hundreds of machines for about 40 teraFLOPS, with their largest cluster in Top 500. The main goal of calibre was to quickly bring a complete cluster from the bare metal to production state. The goal has been quite successfully achieved: using Debian and FAI they get a cluster of 200 machines ready for production in about 1 hour and a half, installing more than 3'000 packages on each machine (as the cluster will be used for heterogeneous purposes, rather than for a handful of specific applications). What I found most interesting of the visit are the reasons for choosing Debian over other (commercial) distros for their scientific computing purposes:

• They use a wide range of scientific softwares: according to their claims Debian is the mainstream distribution with the largest offering of such software, with the additional benefit that corresponding Debian maintainers are experts of the software they package, so that they can trust them. They have kudos for Debian Science, which I'm happy to proxy.
• They need to rebuild packages to trigger specific optimizations for their clusters. On one hand, that defeats the typical management argument of "commercial support" that other distros offer, as rebuilding packages void support guarantees.
• On the other hand, it really helps them the focus on quality that we do have on Debian: we fight FTBFSs to death, and people which need to rebuild our packages really appreciate that.

EDF is generally keen of contributing back to Debian (even though the team behind calibre is still small), and I've been happy to walk them through how they can contribute. The last interesting feedback I've to share, is that they feel a bit alone in what they're doing (which is unsurprisingly, given that their communication on the matter has been rather limited thus far ...). Still, there is probably room for synergies that can be better exploited among users with similar needs. So, are you a cluster / scientific computing user of Debian? Then let me know, and I'll be happy to get you in touch with EDF and other users with similar interests.

A recent development in SE Linux policy is the concept of UBAC (User Based Access Control) which prevents SE Linux users (identitied) from accessing each other s files. SE Linux user identities may map 1:1 to Unix users (as was required in the early versions of SE Linux), you might have unique identities for special users and a default identity for all the other users, or you might have an identity per group or use some other method of assigning identities to groups. The UBAC constraints in the upstream reference policy prevent a process with a SE Linux identity other than system_u from accessing any files with an identity other than system_u. So basically any regular user can access files from the system but not other users and system processes (daemons) can access files from all users. Of course this is just one layer of protection, so while the UBAC constraint doesn t prevent a user from accessing any system files the domain-type access controls may do so. If you used a unique SE Linux identity for each Unix account then UBAC would prevent any user from accessing a file created by another user. For my current policy that I am considering uploading to Debian/Unstable I have allowed the identity unconfined_u to access files owned by all identities. This means that unconfined_u is an identity for administrators, if I proceed on this path then I will grant the same rights to sysadm_u. UBAC was not enabled in Fedora last time I checked, so I m wondering whether there is any point in including it I don t feel obliged to copy everything that Fedora does, but there is some benefit in maintaining compatibility across distributions. For protecting users from each other it seems that MCS (which is Mandatory in the Debian policy) is adequate. MCS allows a much better level of access control. For example I could assign categories c0 to c10 to a set of different projects and allow the person who manages all the projects to be assigned all those categories when they login. That user could then use the command runcon -l s0:c1 bash to start a shell for the purpose of managing files from project 1 and any file or process created by that command would have the category c1 and be prevented from writing to a file with a different category. Of course the down-side to removing UBAC is that since RBAC was removed there is no other way of separating SE Linux users, while MCS is good for what it does it wasn t designed for the purpose of isolating different types of user. So I ll really want to get RBAC reinstalled before Squeeze is released if I remove UBAC. Regardless of this I will need to get RBAC working on Squeeze eventually anyway. I ve had a SE Linux Play Machine running with every release of SE Linux for the last 8 years and I don t plan to stop now.