Search Results: "rul"

10 November 2006

Joachim Breitner: Teaching Linux with Games

I m still at the school in Ghana, and although I have quit, there are another five weeks to make use of. Linux is installed on quite a few machines, but it is not used very often, partly because the studentds don t know about it. I was instructed to boot to Windows by default, so they don t stumble over it either. To raise a more interest, I announced a Linux Gaming Tournament, and put up some posters. The participating students will compete in Frozen Bubble, the game formally known as Tuxracer and Tetrinet.As it turned out I got the permission to do so based on a misunderstanding: The principal thought I would create a game that itself would teach students to use Linux (maybe some kind of rally with hidden hints in various applications and folders, and whoever finds them wins). My original plan would not have been allowed, as there is a officially strict school policy against computer games, and because it is a boarding school, it is also a life policy for the students for four years.Because the tournament was already announced and students signed up for it, I will still be able to hold it, as an explicit exception to the rule. But what the administration would like to see, also to keep the interest in Linux up even after I will have removed the games again, is a longer lasting competition in a game with a more educational purpose. An old Mac game was named where the player has to run a business and in the process learns about spreadsheets.So, dear lazyweb, do you know of a game thatI know that the last two wishes would point to a web based game, but that defies the purpose to lure the people to start Linux.

7 November 2006

Erich Schubert: The power of userContent.css

All mozilla-based browsers have a feature called "userContent.css". It was designed to allow you to override page CSS with your own, e.g. for accessibility reasons. It has mostly been used by people to remove ads, and I'll share two examples with you. Create ~/.gnome2/epiphany/mozilla/epiphany/chrome/userContent.css (you'll probably need to create the chrome directory, too; other browsers use similar path names) and put these two rules in there:
a[href$=".pdf"]:after  font-size: 10px; color: red; content: " [PDF]"; 
iframe[src*="devart.adbureau.net"]  display:none !important; height: 0;  
@-moz-document domain("mail.google.com")   button#ac_tr   color: red !important;   button#ac_dl   color: red !important;    
The first one will postfix a red [pdf] to any link going to a PDF file. This is very valueable especially with Google scholar. The second rule is an example on how to hide elements. This example hides some ads on deviantart. You can easily pick a wider term or grab some of the existing rulesets. The third rule will color the ">deviantart. You can easily pick a wider term or grab some of the existing rulesets. The third rule will color the ">deviantart. You can easily pick a wider term or grab some of the existing rulesets. The third rule will color the "delete" button in Gmail red, so you find it easier. Since it moves around (UI hazard; "delete forever" replaces "archive" button in spam and trash folders.) this is quite nice to have. But if you want to go for default ads filtering, I'd suggest to use some of the adblock extensions. These userContent tricks are mostly useful for adding rules that the extension didn't catch.

Stefano Zacchiroli: editing latex the vim way

Editing LaTeX, the Vim way Uwe presented latexmk as its way of previewing LaTeX output while editing in Vim. While I don't know latexmk myself, I'm using quite a lot LaTeX recently (my Ph.D. thesis is getting huuuge) and I'm co-maintaining vim-latexsuite in Debian. With vim-latexsuite what he wants can be achieved quite easily too. I keep on editing in Vim and can exploit the following shortcuts (where <Leader> is usually mapped to backslash):
  1. <Leader>ll compile the current LaTeX source, the generated format depends on the value of g:Tex_DefaultTargetFormat (I use dvi, for a reason explained below);
  2. <Leader>lv fire up a viewer for the compiled format, in my case this runs xdvi;
  3. <Leader>ls move the DVI viewer to the point the cursor is currently at in Vim, highlighting (in xdvi) with a rectangle the current paragraph (believe me, this is amazing);
  4. CTRL+Mouse Click (this in xdvi) do the opposite of (3), i.e. move Vim to the point in the LaTeX source file corresponding to where we clicked in xdvi.
I don't really understand why Uwe want to see working previews in PDF format, to me PDF is just the final output. DVI is much better (especially for (3) and (4) above, but also because it takes less time to be generated). Oh, and of course vim-latexsuite is able to do a lot more, like deciding whether LaTeX needs to be run again to fix dangling references, use the quickfix window to jump to compilation error, and so on ... End of the SPAM :-) PS these are my latex-specific vim settings from my ~/.vim/after/ftplugin/tex.vim
setlocal tw=80
setlocal ts=8
setlocal sts=1
setlocal sw=1
setlocal iskeyword+=\\
setlocal makeprg=make
setlocal keywordprg=:help
"setlocal formatoptions+=a
setlocal spell
vmap ,b "zdi\textbf <C-R>z <ESC>
vmap ,e "zdi\emph <C-R>z <ESC>
vmap ,t "zdi\texttt <C-R>z <ESC>
  " Latex-Suite
let g:Tex_CompileRule_dvi = 'latex -interaction=nonstopmode -src-specials $*'
if v:servername != ""
 let g:Tex_ViewRule_dvi = 'xdvi -editor "vim --servername ' . v:servername . ' --remote +\%l \%f"'
endif

Maximilian Attems: linux-2.6 2.6.18 status

2.6.18-4 was uploaded on Sunday and should be soonest available after dinstall run for most archs. The ia64 build failure is fixed in svn thanks to Thiemo Seufer (ths). alpha is waiting for an updated gcc (see patch in #397139). s390 is currently broken by vserver, patch is awaited soon. linux-latest will be updated tomorrow and expect soon a 2.6.18-5, once those issues are cleared.
linux-image-2.6.18-2- is the Debian kernel team stabilized kernel. Please install it and report eventual bugs. If you know a patch from Linus git tree that fixes your problem even better name it. Thanks for your testing!
We had been quite busy to feed stable with patches that fit the Documentation/stable_kernel_rules.txt. Goodies like Xen, drm-i965 or ahci backport are shared with Fedora Core 6 release. Beyond that for example the r8169 patch series or ccisss support for 2 TB volumes got backported. Out of reach are destabilizing patches like the new 2.6.19 ACPI patches. Further backports are planed for the SUSE reiserfs 2.6.19 patches and vorlon has a fix in the pipe for the vga console driver on alpha.

6 November 2006

Wouter Verhelst: From 2 to 5

One thing about being an m68k porter is that you get to play with hardware a lot. And I mean a lot. Ska, jazz, newwave, and barok had all died during the last few weeks to months; so I was back to two working m68k machines that I could somewhat work with (quickstep, a 25Mhz 040 that I own, and arrakis, a 50Mhz (or so) 060 owned by Ingo Juergensmann). Which was not enough. To make matters worse, arrakis had actually died last week, but that was fixed quickly enough (thanks, Ingo). Which had left me with non-working jazz, barok, ska, and newwave. It isn't the first time that newwave dies on me, and it isn't the first time that a simple power-on again fixes it, after a few weeks of downtime. I can only conclude that this isn't a box which likes being powered on all the time, and that I'll have to leave it powered off for a few weeks every now and then. That's not a big issue, since the machine isn't very high on RAM anyway, so not very useful (apart from testing EMILE on, and other similar things). Barok had died a few weeks ago with a kernel oops that it couldn't even print out entirely. If that sounds like hardware failure, that's because it is hardware failure. Luckily, it's nothing too bad; removing the expansion cards one by one and replacing them afterwards revealed that it's the cache RAM which is the culprit. That's good news and bad news at the same time; good, because a Macintosh IIci can work without this cache RAM (it was sold without those things after all; the cache expansion was an option); bad, because it already is the slowest machine I have, and losing the cache doesn't make it speed up. But at least that one works again—if any of you have some IIci cache lying around that you don't need anymore, feel free to send it my way. Jazz had only paniced, like it does every time. It's a Quadra 950, and those have never been very well supported by Debian. I just needed to reboot it, which I forgot about every time I got near it. It's working again now, compiling away at the next EMILE version, which will fix a few bugs and should make it into etch. Or, well, at least it would be, if not for the b0rken debian/rules file, which I will now have to fix, I guess. Not that this isn't anything I can't handle. Leaves Ska, which needs a new hard disk. That's not a big problem, I just need to get around to flinching me one out of the old unused RAID array at the office, low-levelling it, and placing it in ska. Which I have been planning to do for only, eh, three months or so. Whoops.

3 November 2006

Julien Danjou: DeFuBu contest #4

Bug Welcome to this 4th issue of the DeFuBu contest, the monthly championship of the funniest bug reported to the Debian BTS. The challengers How the vote has been done Four Debian related people voted for these bugs, Philipp Kern, Florent Bayle, Cyril Brulebois and Gregory Colpart.
Mohammed Adn ne Trojette should vote quicker next time. Full ranking Bugs Challengers The winners Notes To participate, simply drop me an email with a bug number. About DeFuBu

Maximilian Attems: Early Userspace Fun

History
For the sarge release official kernel-images from the newly formed Debian kernel team came together with initrd-tools. initrd-tools Maintainer was jbailey. It saw some care from tbm, vorlon and me before the actual release. Remembering the flow of bugs and installation-reports it accounted for a huge number of install failures plus lacked many features the Red Hat mkinitrd had. Ubuntu got hit more directly as hoary released with a newer kernel than 2.6.8 and due to the initrd-tools devfs requirement.
initramfs-tools originated out of the need of a direct replacement. Inspired by an initramfs OLS talk jbailey had the goals of boot-time hardware detection using the nice and neat features the Linux 2.5 branch incorporated: The sysfs support of the Linux drivers allows an neat userspace daemon aka udev to coldplug them. udev is the replacement of a maze of slow shell scripts called hotplug package. The second big feature is the new initramfs format (the curious may want to read Documentation/filesystems/ramfs-rootfs-initramfs.txt of any current linux-2.6 source). For a boot loader initramfs or initrd is the same fish. The smaller and more efficient in kernel code makes the difference. The initramfs gets loaded much earlier, due to being only an cpio archive and not an fs allowing it to completely rule the rootfs search and mount. One initial assigned spec had the name "easy NFS root". The LTSP guys joined in and showed interest in incorporating their work.
Technology
initramfs-tools got default in Debian together when the first common linux-2.6 (2.6.15) package reached etch, powered all the Ubuntu releases from Breezy on and is used by the grml live-cd. Since archive inclusion almost a year ago it got much better support of all the various linux boot parameters (see man initramfs-tools or the "official" Documentation/kernel-parameters.txt), keeps an backup initrd around and has better block-based bootloader support (lilo, ..). klibc has been ported to _all_ the Debian release archs where it is in use and compiles fine on m68k and sh.
The initramfs-tools early userspace is very flexible based on it's hooks for initramfs build and boot. Thanks to alphix for the help on shaping the building blocks. There are initramfs hooks in cryptsetup, evms, dmraid, firmware-qlogic, lvm2 multipath, mdadm, usplash, .. Reviewers, uploaders and sponsors included fs, jbailey and Sesse. Most of the time it is sufficient and easy to test changes in qemu images (See slides workshop early userspace). The best wish of an early userspace is not to be remarked - aka happy booting. Nevertheless thanks a lot for the public support: Achieving Xen Disk encryption support in Etch, Popping my initramfs cherry, ..
Future
The latest initramfs-tools release seems almost ready for the upcoming etch release. The bug reports coming over from installation-reports are happily rare. Although the uuid based fstab generation solution is not yet integrated in the debian-installer. There are one or two known nitpicks left-over in the bts plus one bugger: udevsettle may exit to early, when not all the discs are ready for use. For grub there is a fail-over net, but which does not account for a to early md or lvm2 boot hook. Future initramfs-tools development will focus on an optional small klibc based Modules=dep hand walking /sys initramfs generation allowing better embedded support. grub2 will present run-time assembly challenges for the initramfs.

2 November 2006

Ben Hutchings: How to fix www.royalmail.com in Firefox for Linux

The front page of www.royalmail.com displays wrongly in Firefox on Linux (though apparently not Windows). Worst of all, it is impossible to focus the input fields near the top of the page by clicking on them. However, I worked out some style rules that will fix it. These have been tested in Firefox 1.5 on Debian etch and Fedora Core 5. To apply these, you need to copy/add the following text to ~/.mozilla/firefox/profile/chrome/userContent.css and then restart the browser. Perhaps someone who knows about GreaseMonkey can work out a rule for that, which would make it easier to install them.
@-moz-document url-prefix(http://www.royalmail.com)   
  div.Content-Region    position: static !important;  
  div.Content-Region div    position: static !important;  
  div.List-Container   height: auto !important;  
  div.hpBottomWide   clear: left;  
 

Gunnar Wolf: Oaxaca on fire

Before anything else: Please excuse some grammatical mistakes I've made in this post. You should understand the topic is really upsetting, and typing while searching for links, listening to news, and gathering the basic information for a five month old conflict is not exactly compatible with me spewing out proper English ;-)
Just to re-state the obvious: Mexico is, once again, on fire. This posting is mainly written with the Debian people in mind - An important number of them, after Debconf 6, went to visit Oaxaca - In late May, during the first weeks of this incredible, stupid and scary conflict we are now facing.
I've written in my blog every now and then about our political situation. Many of us had high hopes on our current government. We thought that the authoritarian regimes were a thing of the past, we hoped for real democracy, we hoped for a government that would honor human rights and solve long-standing topics for our society - Yes, we all knew president Fox came from a right-wing party, and didn't expect much advance in the social agenda -which many of us perceive as the real problem in Mexico- but still, hoped for openness and reconciliation with the past.
I won't repeat what I've extensively said over and over - The thing is, Fox's government continues to amaze us with its stupidity, with its near-sightedness, with its hypocresy. Fox's term is really close to an end - In one more month, the govt. will change hands to the first de-facto president since Carlos Salinas (going over another story we hoped to forget).
As some of you wittnessed, there was a popular protest taking place mainly in Oaxaca - Basically, the State's public elementary school teachers demanding better payment for their work. Such a protest is already a common occurrence in Mexico, as public school teachers are among the worstly paid workers (no wonder, then, our country is still undeveloped - Make public education worse, and you have the warranty of an unprepared, ignorant population). The teachers went on strike in early May, briefly returned to classes on late June to properly close the 2005-2006 lective year, but went back on strike afterwards.
Of course, the local government (Mexico is a federative republic, each state is autonomous and makes decisions independently) took a very long time to act - and acted the worst way possible: By sending policemen to forcefully throw the teachers from their camps in the downtown streets, with no negotiation, no answer, not a drop of common sense.
That led to the formation of the (pleonasmicaly named) APPO: Popular Assembly of Oaxaca's People - A group of people, partly formed by the unhappy teachers, mainly demanding the Oaxaca state governor to step down, after he proved he is inept for his office. And yes, I'm oversimplifying here, but I don't want to dig too much - There is fortunately plenty of available information in this regard.
That happened over four months ago. APPO kept control of the city. Nobody denies that this has caused Oaxaca, a city that attracts national and international tourism like few others in the country, a great deal of economic damage - Oaxacan people are, however, still sympathetic to APPO's demands. Governor Ulises Ruiz (from PRI, the party that ruled the country for over 70 years) has not been able to be seen in public in his state for some months already. The legislative power has also been unable to work properly, and the judicial power is half-dead, doing only its most basic tasks. Renowned jurists, such as Miguel ngel Granados Chapa, have repeatedly stated that this is enough for the Federal Senate to declare the governing powers in Oaxaca have disappeared - This would put an end to the conflict, leading to immediate elections, but the Senate has denied taking this course of action. Not only that, but the Federal government took the command of the local security forces, tacitly recognizing the local government is unable to coherently excersise their authority. After almost five months, last week they issued an unanymous -but mild- exhort, asking Ulises Ruiz to consider stepping down.
So far, 15 people have been killed in the different represive actions taken, first by the local police under local command, later by the local police under federal command, and starting last week, by the federal police. Today, it seems the army is getting in the conflict as well, despite promises of not doing so by the federal authorities - Of course, they have become masters in the art of breaking promises.
Why is the federal government upholding Ulises Ruiz? Simple: After the undeniable electoral fraud we had some months ago, there are too many indicatives pointing out that our (supposedly) elected president Felipe Calder n (FeCal, as he is better known as) will have a hard time becoming the president, and many people doubt he will be able to hold the authority for the six years. So far, he has shown no better aptitude as a statesman than Vicente Fox: Instead of boldly facing the claims of fraud, he just chickened out and has spent many months hiding from the public, appearing only for selected, friendly audiences. For many months already we have heard "Ulises ya cay , le sigue Calder n" (Ulises has fallen, Calder n is next). This country has not been so badly shaken in decades - Of course, Great Statesman Vicente Fox insists the country is in peace and there are no red spots. Fox even was stupid/blind enough to state that the problems in Oaxaca would be dealt with easily and successfully, just as the problems in Chiapas and Atenco were doing his term. During Fox's campaign, he promised to solve the centuries-old Chiapas problem (that resulted in the EZLN uprising in 1994) in just 15 minutes - He just has not had time to do so. Atenco? Yes, in 2002 an angry people made him step back from the most important project of his term (a new airport for Mexico City). In May 2006, Atenco sprang again to the news because of a massive repression - I'm not going into details on Atenco right now, as it would be off-topic, but you can look at my article in FeCal.org.mx or watch a very strong video by Canal Seis de Julio (both in Spanish only) for further details.
Last Friday, however, something was different. In a repressive action, a USA citizen, the Indymedia reporter and cameraman Brad Will was killed by a paramilitary group. Even more, he was killed while doing his work, and we can clearly see this evidence on his last tape. Of course, the US ambassador issued a warning, asking the US citizens not to go to Oaxaca. And, as Lorenzo Mayer says, hay de muertos and muertos - There are different categories of dead people. A highly visible US citizen is more important than the other 14 dead Mexicans, and now the Federal Preventive Police is clashing in Oaxaca.
What should be shocking, but is not so much to those of us who know this beaten country, is the attitude of the authority when taking the city. After five months of occupation, the Oaxacan people have got used to living with APPO - be it for good or for bad. Tourism has diminished, but the people's living sources have not been attacked. Of course, as soon as the Federal Police took the downtown areas, all sorts of reports of looting have been reported. The policemen are robbing even sodas and chips, and up to TVs and microwaves. As many people state, this is a very Kafkian country.
Of course, we don't know what will come next. Most of the city has been "freed", and the APPO is holding at the University. The University is autonomous, and the PFP commands have promised not to break its autonomy - but we don't believe that. There are fights very close to the University. The Rector himself spoke a couple of hours ago at Radio Universidad, the main broadcasting point for real news on this subject (I am following on the news thanks to KeHuelga, 102.9MHz FM in Southern Mexico City, or at their webpage, from where they link to many other underground or Internet radio stations joining in the broadcast), and the reports are dramatic. Dramatic, as well, is the way all of the commercial news sources are ignoring the facts.
I want to keep you updated, as one of the very few reasons things are not worse is the public opinion and, even more, the international pressure. I'm sorry I'm not giving more links right now, but I will soon. I don't want, of course, to flood people that read my blog through the different syndications with a technical profile, so updates via my blog will be quite sparse. If you can read Spanish, we have posted many articles at FeCal, and many other individual sites are also joining in. A couple of links, and I'm off for now.

30 October 2006

Benjamin Mako Hill: Software Freedom Curriculum

About a year ago, I was working on OLPC during most of the time and thinking a lot about software freedom in the context of the project. My blog post on OLPC and Charges of Technological and Cultural Imperialism from last December is a great example of my thinking out loud about some of the issues. The attractive thing to me about OLPC was the idea of students getting a real, free software, free hardware, truly open platform unlike phones, calculators, and eBooks: closed paternalist platforms that seem to be the only real alternatives. This is a goal that OLPC has not achieved yet but has already come quite close to. People say that because modifying technology is often difficult, only a small percentage of users -- especially young users -- will take advantage of the malleability or "hackability" of a product. They are probably right. But part of why this happens is because when computers are employed in education, we use them as tools to accomplish predefined and preprogrammed tasks. Even when students learn to program, it's in a window (quite literally in a box) separate from the rest of the things that the computer does. And for someone working on a project in part so that they can spread technological freedom, this is a problem. Consider the fact that with only a small number of exceptions, the only advocates of software freedom I know are programmers or hackers. I don't think that this is because of some "programmer's sensibility" but rather because programmers understand a set of things about the malleability of software and the nature, effect, and context of computation that gives them perspective to understand how a concept like freedom might apply to something like software. In other words, to understand software freedom, you must first understand -- really understand -- what software is and what it is not, how it makes things possible and impossible, and how changing it can have important effects. The mentality I've described is currently a "hacker's sensibility" but I don't believe that you need to be a hacker to understand why software freedom is important. Proof, I think, is the fact that people think that a free press is important even if they don't publish or write very well. As an exercise, I took it on myself to write the beginning of a curriculum that teachers could use to teach students about software freedom and the concepts that I think are key to understanding it. It tries to come up with models for framing discussions and a series of activities to help teachers teach relatively young (i.e., middle school students) about issues of computation, information goods, and ultimately about software freedom. I wrote the curriculum about a year ago, showed it to a few teachers and colleagues, and then sat on it because I wasn't sure what to do with it and because I was concerned by my own lack of experience teaching outside of Universities. I'm still not entirely sure about incredibly basic things like what form a curriculum should take for this age group. I noticed recently that Wikiversity launched in August and it seems like the perfect place to put my curriculum for consumption by the world and for collaboration, discussion, and further development. You can see what I've got from this page and the pages linked from it:
http://en.wikiversity.org/wiki/Software_Freedom
The project still needs lots of work. It needs to be threshed out on its own terms and it needs to be broken down and integrated into Wikiversity as a series of learning projects, learning activities, etc. I've looked at the documentation around Wikiversity and I can neither understand how to do this nor find examples of large curricula in Wikiversity to which this has already been done. If you have experience on Wikiversity, your help would be welcome. If you are interested in using part of the curriculum, I would love to hear from you and to see your edits on the wiki.

Adrian von Bidder: SuSE

(Let's test this planet thingy... Hello everybody!) Setting up a SLES 10 server at $WORK, for a change. Compared with my usual distribution, this means: LDAP authentication is easily set up, I don't even have to know about all the packages (PAM, NSS, LDAP server, ...), and when I then create a user in yast, it does create a user in the LDAP database automatically. Debian could learn a thing or two about integration here. But it also means a hideous apache configuration schema, with lots of configuration files, some parts of the configuration in /etc/sysconfig instead of /etc/apache2, and config file snippets generated by the init.d script (coming from SuSE 4.x days, I felt right at home. At least yast hasn't overwritten anything I didn't want it to so far.) And it also means that I had to compile subversion from source because I couldn't immediately find SLES 10 binary packages. Of course, I have to admit that Subversion is a truly exotic peace of software that no sane systems administrator would ever use on his server, so I can understand that. Conclusion so far: SLES10 is a nice piece of software, but some aspects can be called rough edges although I guess many would argue it's just my bias.

Jurij Smakov: Papers, please ?

Today I have witnessed an incident which involved a person getting kicked from #debian-devel, when he refused to disclose his real name (I did not notice any other disruptive behavior on his part). When I objected to that, I was quite surprised to find that quite a lot of people found this an acceptable administrative measure (the channel rules wiki page was promptly created to reflect that). While I find it totally acceptable, that a person must reveal his/her real name when becoming a Debian Developer, I think that having such a requirement in place for an unrestricted public Debian channel is completely inappropriate. In my opinion, the right to remain anonymous is fundamental, and I don’t care about the person’s real name, as long as he/she has something useful to contribute. I also believe that protection of this right is a part of the core Debian philosophy, as we refuse to recognize software as free, if it impedes on the person’s right to remain anonymous (”Dissident test” in the DFSG FAQ). Therefore, the support of fellow DDs (some of them actively involved in NM process) for such measures looks like nothing but pure hypocrisy to me. I have added a note stating my disagreement on this issue to the wiki page.

28 October 2006

Russell Coker: god on my side


Today I saw the movie God On My Side by Andrew Denton. It's an interesting movie about the televangelist industry in the US. I expected it to be about the shonky frauds who harm people, there was one scene in the start of a televangelist claiming to cure diabeties (a very dangerous claim that often results in serious injury to the victims of such frauds), but mostly it was about serious evangelists and not about the frauds.

What was scary was the level of advocacy of Armageddon. These people seemed very determined to have a great war between the US and Russia (haven't they realised that the USSR doesn't exist any more?). They advocated taking all possible measures to defend Israel (not ruling out the use of nuclear weapons) and didn't want any compromise with Palestine (no land for peace - after all peace gets in the way of Armageddon).

One insightful comment by an evangelist pointed out that many Christians have gone wrong in their advocacy in being based on what they are against rather than what they are for. It's a sad trend that most Christians are not able to express any positive things that they are for and only focus on things that they oppose. On most occasions when they say they are for something it is really a disguise for being against something else, EG supporting Family Values means oppressing homosexuals, preventing freedom of speech (bad language), and banning abortions (even for rape victims).

I am looking forward to the DVD release of this. I'm sure that the out-takes and some further footage post release will be interesting.

Above is the day 21 beard picture.

27 October 2006

Scott James Remnant: Having Left Debian

It’s been over a year now since my last proper upload to Debian, and nine months since I announced my intent to put aside working on Debian for a while. With Matthew Garrett’s resignation from Debian, several people have compared it to my own “resignation” from Debian. It has got my thinking about whether I currently intend to ever end my “Sabbatical” and return as an active Debian Developer. I think that the end of my love-affair with Debian started at Debconf last year where several developers treated those of us who also worked on Ubuntu quite rudely. Someone was attacked for wearing an Ubuntu t-shirt at the conference, while someone else was applauded for wearing a “Fuck Ubuntu” t-shirt. That’s where I realised that maybe I didn’t have as much in common with these people as I thought I did. I still don’t understand why Debian singles Ubuntu out for this kind of treatment, we’re still the only derviative distribution that makes all of our patches to Debian available, yet Ubuntu is claimed to not do anything at all. Another example is that Ubuntu is being asked to change the Maintainer field of every package, something no other derivative is being asked to do or has ever been asked to do. Martin Krafft has had some interesting things to say about this strange relationship in the past. If that was the start of my falling out with Debian, I think that Debian considering removing documentation and firmware from the distribution, especially the documentation, was another point I started wondering whether I shared anything in common with the project anymore. Call me strange, but I think that one of the fundamental purposes of a Linux distribution is to be useful to its users. If nobody can use the distribution because it doesn’t support their hardware, and even if it did, all the documentation has been stripped out; I started to wonder what it’s aims are. It became increasingly apparent that the only users Debian was considering a priority were its own developer. And the third thing is simply a matter of Fun. Fun for me, at the moment at least, has been to build a system that fits together extremely nicely with each component doing the right thing. For Ubuntu this has meant being a driving force for it being Linux 2.6 only, with reliance on udev for hardware, etc. Upstart is just a continuation of these goals, getting a system which all “just works”, even if it means throwing out a few things people were previously fond of. All of these things would have been impossible to do in Debian itself. Getting upstart installable required changes to twelve different packages, including sysvinit itself; at a worst case, this would have required the agreement of twelve different maintainers in Debian. It’s often exhausting just persuading one of the reason for the change, persuading a dozen would have been a herculian effort. Perhaps Matthew is right, what Debian lacks is a single leadership. There’s nobody in Debian I could have gone to for approval over the changes I wanted to make, whose decision developers cannot overrule. Ubuntu has such people (the Technical Board and sabdfl), which gives the project an obvious direction instead of a couple of hundred people all pulling in different directions. In a way, I don’t feel that I’ve left Debian. I feel like I was happily going along, only to realise the mob had gone in a different direction and with no easy way of rejoining the group.

Scott James Remnant: Upstart in Universe

upstart is a replacement for the init daemon, the process spawned by the kernel that is responsible for starting, supervising and stopping all other processes on the system. The existing daemon is based on the one found in UNIX System V, and is thus known as sysvinit. It separates jobs into different “run levels” and can either run a job when particular run levels are entered (e.g. /etc/init.d/rc 2) or continually during a particular run level (e.g. /sbin/getty). The /etc/init.d/rc script is also based on the System V one (and is in the sysv-rc package), it simply executes the stop then start scripts found in /etc/rcN.d (where N is the run level) in numerical order. Why change it? Running a fixed set of scripts, one after the other, in a particular order has served us reasonably well until now. However as Linux has got better and better at dealing with modern computing (arguably Linux’s removable device support is better than Windows’ now) this approach has begun to have problems. The old approach works as long as you can guarantee when in the boot sequence things are available, so you can place your init script after that point and know that it will work. Typical ordering requirements are: This worked ten years ago, why doesn’t it work now? The simple answer is that our computer has become far more flexible: We’ve been able to hack the existing system to make much of this possible, however the result is chock-full of race conditions and bugs. It was time to design a new system that can cope with all of these things without any problems. What we needed was an init system that could dynamically order the start up sequence based on the configuration and hardware found as it went along. Design of upstart upstart is an event-based init daemon; events generated by the system cause jobs to be started and running jobs to be stopped. Events can include things such as: In fact, any process on the system may send events to the init daemon over its control socket (subject to security restrictions, of course) so there is no limit. Each job has a life-cycle which is shown in the graph below: The two states shown in red (“waiting” and “running”) are rest states, normally we expect the job to remain in these states until an event comes in, at which point we need to take actual to get the job into the next state. The other states are temporary states; these allow a job to run shell script to prepare for the job itself to be run (“starting”) and clean up afterwards (“stopping”). For services that should be respawned if they terminate before an event that stops them is received, they may run shell script before the process is started again (“respawning”). Jobs leave a state because the process associated with them terminates (or gets killed) and move to the next appropriate state, following the green arrow if the job is to be started or the red arrow if it is to be stopped. When a script returns a non-zero exit status, or is killed, the job will always be stoped. When the main process terminates and the job should not be respawned, the job will also always be stopped. As already covered, events generated by the init daemon or received from other processes cause jobs to be started or stopped; also manual requests to start or stop a job may be received. The communication between the init daemon and other processes is bi-directional, so the status of jobs may be queries and even changes of state to all jobs be received. How does it differ from launchd? launchd is the replacement init system used in MacOS X developed as an “Open Source” project by Apple. For much of its life so far, the licence has actually been entirely non-free and thus it has only become recently interesting with the licence change. Much of the goal of both systems appears initially to be the same; they both start jobs based on system events, however the launchd system severly limits the events to only the following: Therefore it does not actually allow us to directly solve the problems we currently have; we couldn’t mount filesystems once the “filesystem checked” event has been recived, we couldn’t check filesystems when the block device is added and we certainly couldn’t start daemons once the complete filesystem (as described by /etc/fstab) is available and writable. The launchd model expects the job to “sit and wait” if it is unable to start, rather than provide a mechanism for the job to only be started when it doesn’t need to wait. Jobs that need /usr to be mounted would need to spin in a loop waiting for /usr to be available before continuing (or use a file in a tmpfs to indicate it’s available, and use that modification as the event). This is not especially surprising given that Apple have a high degree of control over both their hardware and the actual underlying operating system; they don’t need to deal with the wide array of different configurations that we have in the Linux world. Had the licence been sufficiently free at the point we began development of our own system, we would probably have extended launchd rather than implement our own. At the point Apple changed the licence, our own system was already more suitable for our purposes. How does it differ from initng? Initng by Jimmy Wennlund is another replacement init daemon intended to replace the sysvinit system used by Linux. It is a dependency-based system, where upstart is an event-based system. The notion of a dependency-based system is interesting to talk about at this point. Jobs declare dependencies on other jobs that need to happen before the job itself can be started. Starting the job causes its dependencies to be started first, and their dependencies, and so on. When jobs are stopped, if running jobs have no dependencies, they themselves can be stopped. It’s a neat solution to the problem of ordering a fixed boot sequence and the problem of keeping the number of running processes to a minimum needed. However this means that you need to have goals in mind when you boot the system, you need to have decided that you want gdm to be started in order for it, and its dependencies, to be started. Initng uses run levels to ensure this happens, where a run level is a list of goal jobs that should be running in that run level. It’s also not clear how the dependencies interact with the different types of job, a dependency on Apache would need the daemon to be running where a dependency on “checkroot” would need the script to have finished running. Upstart handles this by using different events (“apache running” vs. “checkroot stopping”). Again while interesting, Initng does not solve the problems that we wanted to solve. It can reorder a fixed set of jobs, but cannot dynamically determine the set of jobs needed for that particular boot. A typical example would be that if the only dependency on the job that configures networking is the mount network filesystems job, then should that job fail or notbe a goal (e.g. because there are no network filesystems to be mounted) the result is that network devices themselves will not be configured. You could make everything a goal, and just use the dependencies to determine the order, however this is less efficient than just ordering the existing sysv-rc scripts (which can be done at install time). Another example is that often you simply don’t know whether something is a dependency or not without reading other configuration, for example the mount network filesystems may be a dependency of everything under /usr or may just be a dependency of anything allowing the user to login if it just mounts /home. The difference in model can be summed up as “initng starts with a list of goals and works out how to get there, upstart starts with nothing and finds out where it gets to.” How does it differ from Solaris SMF? SMF is another approach to replacing init developed by Sun for the Solaris operating system. Like initng it’s a dependency-based system, so see above for the differences between those systems and upstart. SMF’s main focus is serive management; making sure that once services are running, they stay running, and allowing the system administrator to query and modify the states of jobs on the system. Upstart provides the same set of functionality in this regard, services are respawned when they fail and system administrators can at any time query the state of running services and adjust the state to their liking. Will it replace cron, inetd, etc? The goal of upstart is to replace those daemons, so that there is only one place (/etc/event.d) where system administrators need to configure when and how jobs should be run. In fact, the goal is that upstart should also replace the “run event scripts” functionality of any daemon on the system. Daemons such as acpid, apmd and Network Manager would send events to init instead of running scripts themselves with their own perculiar configuration and semantics. A system administrator who only wanted a particular daemon to be run while the computer was on AC power would simply need to edit /etc/event.d/daemon and change “on startup” to “on ac power”. What about compatibility? There’s a lot of systems administrators out there who have learned how Linux works already and will not want to learn again immediately, there’s also a large number of books that cover the existing software and won’t cover upstart for at least a couple of years. For this reason, compatibility is very important. upstart will continue to run the existing scripts for the forseeable future so that packages will not need to be updated until the author wants. Compatibility command-line tools that behave like their existing equivalents will also be implemented, a system administrator would never need to know that crontab -e is actually changing upstart jobs. Does it use D-BUS?
“To D-BUS people, every problem seems like a D-BUS problem.” —Erik Troan
The UNIX philosophy is that something should do just one job, and do it very well. upstart’s one job is starting, supervising and stopping other jobs; D-BUS’s one job is passing messages between other jobs. D-BUS does provide a mechanism for services to be activated when the first message is sent to them, thereby starting other jobs. Some people have taken this idea and extended it to suggest that all a replacement init system need do is register jobs with D-BUS and turn booting into a simple matter of message parsing. This seems wrong to me, D-BUS would need to be extended to supervise these services, provide means for them to be restarted and stopped; as well as deal with being process #1 which means cleaning up after children whose parent’s have died, etc. It seems far simpler to arrange for D-BUS to send an event to init when it needs a service to be started, and focus on being a very good message passing system. The IPC mechanism used by upstart is not currently D-BUS because of various problems, however it’s always been expected that even if init itself doesn’t communicate with D-BUS directly, there would be a D-BUS proxy that would ensure messages about all init jobs and events would be given to D-BUS and D-BUS clients could send messages to init to query and change the state of jobs. What is the implementation plan? Because this is process #1 we are changing, we want to make sure that we get it right. Therefore instead of releasing a fully-featured daemon and configuration to the world, we’re developing it in the following stages:
  1. Principal development; at the end of this stage the daemon has been implemented and can manage jobs as described.
  2. Replacement of /sbin/init while running the existing sysv-rc scripts. This is the shake-down test of the daemon, can it perform the same job as the existing sysvinit daemon without any regressions?
  3. /etc/rcS.d scripts replaced by upstart jobs. These consitute the majority of tasks for booting the system into at least single-user mode, and contain many of the current ordering problems and race conditions. If the daemon solves the problems here, it will be a success.
  4. Other daemon’s scripts replaced by upstart jobs on a package-by-package basis; this will be an ongoing effort during which upstart will continue running the existing sysv-rc scripts as well as its own jobs. During this time the event system may be tweaked to ensure it truly solves the problems we need.
  5. Replcement of cron, atd, anacron and inetd. This will happen alongside the above and result in a single place to configure system jobs.
  6. Modification of other daemons and processes to send events to init instead of trying to run things themselves.
The current plan is that we will be at least part of the way into stage #3 by the time edgy is released, with that release shipping with upstart as the init daemon and the most critical rcS scripts being run by it to correct the major problems For edgy+1 we hope to have completed stage #5 and be at least part of the way into the implementation of stage #6. From the start of development of edgy+2, no new packages will be accepted unless they provide upstart jobs instead of init scripts and init scripts will be considered deprecated. What state is it in now? The init daemon has been written and is able to manage jobs as described above, receiving events on the control socket to start and stop them. This has now been uploaded to the Ubuntu universe component in the upstart package for testing before it becomes the init daemon. We welcome any experienced users who want to help test this; install the package and follow the instructions in /usr/share/doc/upstart/README.Debian to add a boot option that will use upstart instead of init. If your system boots and shut downs normally (other than a slightly more verbose boot without usplash running) then it is working correctly. Other types of events will be added as required during development and testing. Currently only a basic client tool (initctl) has been written, compatibility tools such as shutdown will be written over the next week or two before it replaces our sysvinit package.

26 October 2006

Mike Hommey: Facts about Debian, Mozilla Firefox and Ubuntu

or How Mozilla Corporation is FUDing on Debian. Again. This time, Christopher Beard, Mr Mozilla Marketing is talking about Firefox in Ubuntu, that it’s great, Ubuntu is a good boy, that it cooperates with Mozilla , and that by cooperating, it can use the great Firefox name and logo. To be honest, I don’t care that Ubuntu calls Firefox Firefox instead of Iceweasel or whatever. I don’t care that Ubuntu doesn’t care about freedom as much as Debian does. I could not care less. But, indeed, I do care about (yet other) false claims about Firefox in Debian. Let’s see what Christopher has to say about it:
I understand that Ubuntu is based upon Debian. Is that the same or different than the IceWeasel browser that Debian is shipping with their latest release?
It’s different. The patches that Debian applied to the Mozilla source code (which then resulted in their IceWeasel product) are more significant in scope than those in what Ubuntu is shipping (and branding as an official Mozilla Firefox release). Firefox in Ubuntu represents a somewhat more modest set of divergences from original Mozilla source code.
Let’s check out what it is about. And as I don’t want people to doubt my words, I’ll give you, readers, the ability to check for yourself what it is all about. First, please download the latest currently available patch for Firefox 2.0 beta 2 in Debian. It has been in experimental for some weeks now. It is a bit different from the patch I described earlier, so I’ll also tell you what has been changed since this 2.0b2 patch: (Also note that another change has been done since then, which is actually reverting a previous patch on gfx/src/gtk/mozilla-decoder.cpp, that was adding code that became dead code when we changed the way to fix the bug.) Next, please download the official and supported Firefox diff from Ubuntu. Uncompress both these diff files, and create two directories (let’s call them ubuntudiff and debdiff) which will contain the individual patches for each file. To fill these directories, please use the following commands:

$ filterdiff --strip=1 firefox_2.0+0dfsg-0ubuntu3.diff > ubuntu.diff
$ filterdiff --strip=1 firefox_1.99+2.0b2+dfsg-1.diff > deb.diff
$ cd ubuntudiff
$ splitdiff -d -a ../ubuntu.diff
$ cd ../debdiff
$ splitdiff -d -a ../deb.diff
If you don’t have the splitdiff and filterdiff utilities, you can get them from the patchutils tools (you will also need another of these tools later). Now, let’s have fun with these split patches… Files that are only patched in Debian: (excluding any file that would be in the debian subdirectory, that contains maintainer scripts for build and installation)

$ LANG=C diff -ru debdiff/ ubuntudiff/ grep "^Only in deb" grep -v debian wc -l
6
So, that’s 6 files that Debian patches that Ubuntu doesn’t. Let’s check what they are:

$ LANG=C diff -ru debdiff/ ubuntudiff/ grep "^Only in deb" grep -v debian

(reordering result for convenience)

Only in debdiff/: browser_base_content_aboutDialog.xul

Adds rows=5 to the user agent textbox so as to display the user agent string uncut by default

Only in debdiff/: content_html_content_src_nsGenericHTMLElement.cpp
Only in debdiff/: content_html_content_src_nsHTMLInputElement.cpp
Only in debdiff/: dom_src_base_nsGlobalWindow.cpp

It’s a patch I submitted in bugzilla #343953 and that got applied in Firefox 2.0. No surprise the patch is not applied on Ubuntu.

Only in debdiff/: extensions_reporter_Makefile.in

Patch I submitted in bugzilla #354413 and that got applied in Firefox 2.0.

Only in debdiff/: security_coreconf_rules.mk

Patch from bugzilla #325148 that got applied in Firefox 2.0 (see above), and a small patch to build the NSS library with debugging symbols (put -g in CFLAGS). That leaves only 2 small patches : CFLAGS = -g added to security/coreconf/rules.mk and rows=5 to browser/base/content/aboutDialog.xul Files that are only patched in Ubuntu: (same exceptions as for Debian)

$ LANG=C diff -ru debdiff/ ubuntudiff/ grep "^Only in ubuntu" grep -v debian wc -l
45
Yes, that’s right, that’s 45 files that Ubuntu patches that Debian doesn’t. Most are windows sizes and similar things that upstream can’t get right because they are values adapted to Windows, but that also includes some changes to the code and some other things. Let’s now check differences in files that are patched in both. It’s a bit of shell black magic, but you can check by hand that it does nothing wrong :

$ LANG=C diff -ru debdiff/ ubuntudiff/ filterdiff -p1 -x configure -x debian"*" lsdiff --strip=1 while read f; do diff -u debdiff/$f ubuntudiff/ awk "! /^--- ^\+\+\+ ^ ^[-+]*\@\@/ print \"$f\"; exit "; done

That gives a list of patch files that have more differences than line numbers changes, and that do not apply to the debian directory or the configure script (which is generated from configure.in), which is what we really want to compare here. You can take this list and run interdiff between these files from the ubuntudiff and debdiff directories. I’ll explain for you what these differences are: Overall, Ubuntu applies the same set of patches as Debian, plus some more. A somewhat more modest set of divergences, huh ?!? For what it’s worth, Ubuntu, like Debian, builds its Firefox with flat chrome and pango enabled.
What’s different in the shipping Ubuntu version of Firefox than the proposed Debian version of Firefox (that didn’t ultimately ship)?
Technically, changes include fixes to the User Agent string and the feed preview, a well as addressing issues of coherent branding. More significant than any specific difference in code, however, is Ubuntu’s commitment to work together with Mozilla and our community on releases going forward to insure product quality and integrity.
Why are you working with Ubuntu when you wouldn’t work with Debian?
We did try to work with Debian and would prefer a situation in which we work together. Ultimately, Debian took a position that was consistent with their own policies, and not compatible with some of the exceptions to Mozilla trademark policies that we offered. While we understand and respect their decision not to work with us under our branding guidelines, Mozilla believes that brands like Firefox are important for consumer protection. In any event, Ubuntu developers are working closely with Mozilla developers to insure product quality and features that are what users expect when they use Mozilla Firefox, which means that they’ll ship (and will continue to ship) a fully branded version.
Reading between the lines, that means Debian is not working with Mozilla. It’s not like we’re submitting patches. No. Never. Ever. I’m also glad to hear from Asa Dotzler, in comments to Mr Beard’s article, that this great collaboration with Ubuntu will lead to patches applied to Firefox (I guess the paid Canonical employees having more time to deal with Mozilla than the volunteer Debian maintainers may have helped, especially considering they didn’t have to do all what we already prepared). Anyways, it’s not like some of the patches we sent got applied. So, while I’m at it, here is an exhaustive list of the bugs where we took or sent the patches that are applied to Iceweasel: #51429, #161826, #252033, #258429, #273524, #287150, #289394, #294879, #307168, #307418, #314927, #319012, #322806, #323114, #325148, #326245, #330628, #331781, #331785, #331818, #333289, #333308, #343953, #345077, #345079, #345080, #345413. These don’t cover the following patches (see the rationale for these in my previous article): It’s so great to spend a great amount of time on a package, send patches, try to understand how things work to get patches applied, and yet, see such denial and false claims about our work. So please, Christopher, Asa, and the others, just stop talking about Debian, it will be better for everyone. PS for Rob in comments out there: No, ColorZilla won’t work on Ubuntu, because of the ABI incompatibility I explained in my previous entry, that Mozilla doesn’t seem to care much about.

Bernhard R. Link: "a speech for policy"

If you have to name a single thing that singles out Debian over all the other distributions in practical quality, then you cannot come up with anything but Debian having a policy, packages have to follow.

The little things make something feel raw or polished. Those things that one by itself look to unimportant by itself have real importance in their magnitude.

As with all rules, rulesets can become too large and become a obstacle. This can be avoided by being conservative and minimal in those rules, which Debian always already practised to the extreme.

Limiting this further down to things people deem as "important" will only futher reduce the overall quality. Instead of removing those few things that are in the policy, we should rather extend to make everything in current policy not met to be a bug (which can still be tagged wontfix or help) instead of reducing the rules found in policy or making more things non-binding.

25 October 2006

Simon Richter: Redirecting to the preferred hostname

Evan thinks that Planet Debian should redirect people to the preferred hostname, and gives a set of rules for mod_rewrite to do it. Since I got fed up with writing complex rewrite rules for hosts that exist in multiple TLDs and both with and without the "www.", I hacked up an Apache module that does this. You list the preferred hostname as ServerName and all the others as ServerAlias, and then set "RedirectToServerName On". The package lacks documentation at present, but on the other hand it is not that difficult to use if you can describe the usage in one sentence. :-) Update:Corrected the name of the option. Thanks to Jeff Waugh for pointing me at the mistake

24 October 2006

Russell Coker: economics of nuclear power

It's interesting to note in this press release from the Australian Greens that Dr Ziggy Switkowski (head of the Prime Minister's nuclear taskforce) that nuclear power is not economically viable in Australia without a carbon tax. As the government has refused to consider such a carbon tax this seems to rule out nuclear power for Australia. I expect that other countries have similar economics.

I imagine that nuclear power would be viable for a country that lacks adequate wind for wind power, is not very sunny so solar power doesn't work, has few rivers so hydro-electric power can't be used, and which has no option of geo-thermal power. Is there such a country?

Evan Prodromou: 2 Brumaire CCXV

As a little side project I got interested in adding a MicroID extension for MediaWiki. MicroID is a teensy little format for asserting that the owner of a particular Web user account is also the owner of another account (like an email account or an OpenID). Adding support to MediaWiki means that Wikitravel users can verify their accounts with claimID or other similar services. Fun stuff, relatively easy, and useful for everyone -- the best kind of hacks. tags:

Confidential to Mako So, one thing that makes a Web site WebSoftwareFriendly is making sure (as best as possible) that each page has one and only one URL. It makes it easier when doing summaries and statistics and such for Web software to know that one page has One True Identity. Otherwise, it divides that page&aposs count of hits, incoming links, citations, etc. etc. between the two (or more) different URLs. The Web software then has an incorrect view of the world and is less useful for human beings. Planet Debian is a site like that. You can get to the same front page either through http://planet.debian.org/ or http://planet.debian.net/ . It may be a good idea to use a 301 redirect (moved permanently) to tell browsers and other Web software that one or the other URL is the definitive one. (I&aposm partial to the .net one, but not for any good reason). The following code somewhere in the Apache configuration for Planet Debian should do the trick:
RewriteCond % HTTP_HOST    !^planet\.debian\.net [NC]
RewriteCond % HTTP_HOST    !^$
RewriteRule ^/(.*)         http://planet.debian.net/$1 [L,R=301]
It just says, "If the client requests an URL that doesn&apost use our preferred hostname, redirect them with a 301 HTTP code to the same URL at the right hostname." Web software like blog aggregators, Firefox (or Iceweasel) extensions, or any other software that does HTTP stuff at a low level will benefit. tags:

Geograph Quick link here: the Geograph British Isles project is totally cool. Creative Commons-licensed photos for every map square in the wt:United Kingdom and wt:Ireland. Their coverage is already quite good. tags:

Next.

Previous.