Steve Kemp: Some thing
- The Debian Administration website now allows users to submit adverts which will be intermixed with the Google Adsense ones.
- I’m looking at renting a dedicated host to share out as a semi-co-op with about six people.

No, jo tampoc t'espere
Of course, the amount of Vatican flags outnumbers us greatly, in a ratio of
at least 1:100, but anyway. There are so many Vatican flags that this looks
more like St. Peter's Square. Others have taken the opportunity to exhibit
Spanish flags all over the place, something that probably had not happened
in Val ncia since the most obscure years of Franquism. Oh well, this is
Val ncia.
One piece of good news: due the chaos starting in just two hours, we're
allowed to leave offices early today, so we can actually get back home.
As soon as I get home and have lunch, I'll flee away to the mountains, like
a maqui until the madness is over. The 1.5 million pilgrims can
have my holy city. Have a
nice time, Ratzinger!
A major point of friction I've gathered from many (Debian) sides stems from the fact that many developers are largely unsatisfied with how Canonical/Ubuntu cooperates and "gives back" to the Debian community: essentially, at the moment all we get are monolithic patches describing the differences between Debian packages and their Ubuntu counterparts. Even though Mark has claimed that the patches should be modular if the underlying package uses a modular package management system (such as dpatch), this does not seem to be the case at first glance (c.f. e.g. squid). You have to look inside the monolithic patch to note that its changes are compartementalised into dpatch files. Yet, Canonical/Ubuntu continuously claims to be "good" and to "give back" to the Debian community, but that's just not happening in that way. Canonical/Ubuntu either has to start giving back according to their own claims, or stop pretending that it does, and it's good that I have heard this voiced by one of the Canonical employees as well.
The perception that Canonical/Ubuntu is taking advantage of Debian seems to prevail. Taking advantage in this definition entails using but not giving back, as well as dragging integrative work out of Debian, something Joey Hess described as the supermarket thing, which has the potential to ruin the Debian project. Whether this is true or false, intentional or unintentional, it is important to recognize that these sentiments do exist among a number of members of the Debian community. There's a related point, namely jealousy about Ubuntu's success, and the fear that it steals Debian's users. In response, it is often said that while Ubuntu depends on Debian, the reverse is not the case: Debian does not need Ubuntu. This is false and true at the same time. Debian surely need derivatives like Ubuntu, for derivatives bring users, and users bring improvements and weight. However, Debian does not need any one derivative more than any other, and in fact it has been considered harmful if any derivative stands out.
Many of those with whom I've spoken perceive that Canonical/Ubuntu do not acknowledge Debian enough, nor give credit where credit is due. And this lack of credit and acknowledgement further amplifies the fear. Two examples seem to stand out:
The "universe" community that gathered around Ubuntu's core surprisingly often does not know about Debian, or do not know how Ubuntu and Debian relate. I do not have any data on this, unfortunately (see below). This is something to take up with the Ubuntu Community Council.
On the ubuntu.com front page, Debian is not mentioned at all; if you actually follow the About Ubuntu link, you can find Debian mentioned once in the first paragraph (albeit without a link), and if you did notice the right hand menu expanding, you may even decide to click on Ubuntu and Debian, where the relationship is finally illustrated from the Ubuntu point of view. To many, this is just not enough. Update (+6h): the About Ubuntu page now links to the Debian homepage. Thanks!
Canonical people, and Mark especially, draw an important line between Ubuntu (which is mostly free/open-source), and Canonical with its other products (Launchpad, Rosetta; which are non-free). However, from the outside, this line does not exist, or at least it appears as if there's a much stronger relationship between the Canonical and the Ubuntu project. This impression casts a corporate shadow over Ubuntu which deters many developers, even if it's undeniable that Ubuntu is a project of its own (to a large degree).
There's no question about Mark being on an agenda, for which he has assembled an impressively powerful team (which indirectly includes many Debian developers) at an (even more impressively) cheap cost. It's not my business to speculate about other people's finances, but those that do conclude that Mark is very likely not running too much of a risk with what he does at the moment and could basically pull out at any point in time. To some, who have dedicated large parts of their lives to Debian, this seems like an unwelcome way to play a game.
When Canonical entered the market and hired some developers to work on a Debian-related project, a lot of jealousy boiled up among those who didn't get a job, because back then it seemed that Canonical was out to pay people to work on Debian -- which is a common dream among us developers; at least people hoped that's what it would be. Many fundamental contributors felt left out and confronted with the question why they should continue their work for free when others are now getting paid for it. The twist is that nobody wanted to ask themselves that question, because money was never the reason why they started to work on Debian. The situation has leveled by now (I think). More and more people realise that Canonical is taking Ubuntu into a direction where many Debian developers do not want to go. Nevertheless, it seems that some of the frictions we are currently facing between Debian and Ubuntu still have their roots in the bad feelings from those times (which may well still exist in the individual case). Canonical/Ubuntu (and some Debian developers) need to realise (and get over) this, and somehow I think they've got a long way to go.
Debian Debian Kenshi Muto Junichi Uekawa Debian Kenshi pbuilder Junichi Debian Kenshi Junichi honsho ga minasama no ochikara ni narereba saiwai desu.And here for all those who cannot understand the signs from the land of the rising sun:
I have only had the chance to visit Japan once to date, but the trip left some unforgettable memories, which make it all the more an honour for me to see a Japanese translation of my book on the market. The Debian operating system is gaining popularity fast in Japan, and it is my hope that the book you are holding in your hands will help to accelerate this growth. Please allow me at this point to express my gratitude towards Kenshi Muto, a Debian book author himself, and Junichi Uekawa, author of pbuilder, a vital component in the making of my book! Kenshi and Junichi are both renowned Debian developers and have been instrumental in the coordination of this Japanese translation. As you will notice while reading my book, I invested a lot of energy into making it a quality reference. It was thus very difficult for me to accept a text with my name on it that I could not read, as is the case with the Japanese version you are holding in your hands. However, knowing the translation in the capable hands of Kenshi and Junichi quickly put my mind to rest and I am now incredibly proud to see my work translated into the language of the fast-moving and innovative culture of Japan. honsho ga minasama no ochikara ni narereba saiwai desu.That last sentence means "I hope the book will be helpful to you," and was translated by Shuhei, a friend who's working on his Ph.D. at Zurich's AILab. Apparently Kenshi and Junichi thought it was so cute that they simply left it as is and did not translate it. In other news, my book's also available in German (and has been since late February), the French edition is on the verge of being released by Eyrolles (no link yet), and the Chinese translation is still work in progress (also, no link yet). The book's website needs a rework to integrate the other languages, and to fix up all the shortcomings I've encountered during one year of uptime with an average of around 200 unique visits per day. It's also still using Plone 2.0.5, but I just have not had the time yet to fix it all up in a migration to Plone 2.5, mainly because I've lost synchronisation with the Plone development team over the past year. Oh well. That ToDo list just keeps getting longer...
It's pretty and people buy it.
scenes of stone cottages, lighthouses, cobble stone streets, rustic villages, and other vistas, with emphasis on the glittery ornamentation in the play of light and natural foliage. His work is meant to be sentimental, patriotic, quaint, spiritual, and inspirational.
Kitsch appealed to the crass tastes of the newly moneyed Munich bourgeoisie who, like most nouveau riche, thought they could achieve the status they envied in the traditional class of cultural elites by aping, however clumsily, the most apparent features of their cultural habits. ...
... in being too beautiful and democratic it made art look easy, non-involving and superficial. ...
In some sense the goals of democratization succeeded, and the society was flooded with Academic art, the public lining up to see art exhibitions as they do to see movies today. Literacy in art became widespread, as did the practice of art making, and there was a blurring between high and low culture. ...
The subjects and images presented in academic art, though original in their first expression, were disseminated to the public in the form of prints and postcards.
Washington's Bavarian village, and seems to be part of the complete Seattle experience -- everyone around here has visited it at least once. The short description is that while the Bavarian theme is a bit of a gimmick, there's good hiking in the area and some good food (if you don't mind the touristy atmosphere).
Another craggy mountain with snow-spotted alpine meadows, thousand-foot waterfalls, and blankets of pine forest? You woke me up for THAT?But even by the standards of the Pacific Northwest, this is a scenic drive.
I can only please one person per day. Today is not your day. Tomorrow doesn't look good either., kitschy statues (women holding beer tables on their breasts), etc. However, while I see very little that's recognizably Bavarian in town, there are some stores with nice selections of work by local craftsmen and artists.
mh@namakemono:/mnt/test$ while true; do date; sleep 1; done > log
That fills a 'log' file every second with the current date.
mh@namakemono:/mnt/test$ tail -2 log
2006 7 4 20:48:02 CEST
2006 7 4 20:48:03 CEST
The file keeps growing and growing. Now, let’s remove it.mh@namakemono:/mnt/test$ rm log
The file is not in the directory any more, but remains in the filesystem. It is actually readable through /proc:mh@namakemono:/mnt/test$ ls -l /proc/10724/fd
5
lrwx------ 1 mh users 64 2006-07-04 20:52 0 -> /dev/pts/1
l-wx------ 1 mh users 64 2006-07-04 20:52 1 -> /mnt/test/log (deleted)
lrwx------ 1 mh users 64 2006-07-04 20:52 10 -> /dev/pts/1
lrwx------ 1 mh users 64 2006-07-04 20:45 2 -> /dev/pts/1
lrwx------ 1 mh users 64 2006-07-04 20:52 255 -> /dev/pts/1
mh@namakemono:/mnt/test$ tail -2 /proc/10724/fd/1
2006 7 4 20:52:45 CEST
2006 7 4 20:52:46 CEST
As you can see, it kept filling while deleted. The usual technique to recover such a file is to copy it from /proc. I happen to have done so some times before, it works pretty well for static files. But that doesn’t in our case: we’ll get a new copy of the file, frozen at some point in time. Here, we’d want to ‘re-link’ the file.
Basically, that can be done with debugfs. The problem is that I didn’t find a clean way to get the inode number from the /proc/10724/fd/1 file. But that can be worked around. You need root access (what a surprise), and hope your filesystem was mostly clean before removing the file.
namakemono:/mnt/test# e2fsck -n /dev/namakemono/tmp
e2fsck 1.39 (29-May-2006)
Warning! /dev/namakemono/tmp is mounted.
Warning: skipping journal recovery because doing a read-only filesystem check.
/dev/namakemono/tmp contains a file system with errors, check forced.
Pass 1: Checking inodes, blocks, and sizes
Deleted inode 113570 has zero dtime. Fix? no
(…)
Don’t worry, the -n option will make the filesystem opened read-only, so there’s no risk for your data.namakemono:/mnt/test# debugfs -w /dev/namakemono/tmp
debugfs 1.39 (29-May-2006)
debugfs: cd test
debugfs: ln <113570> log
debugfs: q
And see how it worked:namakemono:/mnt/test# tail -2 log
2006 7 4 20:58:40 CEST
2006 7 4 20:58:41 CEST
You can tail again, it will show you the file is being appended to.
I guess you can do something along these lines to restore a file from ext2. I don’t know for other filesystems.
If someone knows how to get the inode number without e2fsck, comments are opened :)
Update: Well, it didn’t take long for me to actually find a better way:namakemono:/mnt/test$ lsof -p 10724 -a -d 1
COMMAND PID USER FD TYPE DEVICE SIZE NODE NAME
bash 10724 mh 1w REG 254,3 13552 113570 /mnt/test/toto (deleted)/proc/$pid/fd/$fd, run lsof -p $pid -a -d $fd.
psgml-mode, which I use to edit HTML files wants to have access to the DTD declaration in use. Since Rails usually puts fragments in one directory (app/views/foobar/show.rhtml), and the "parent" template in another (app/views/layouts/foobar.rhtml), it means that the "child" template doesn't have access to the DTD in use, and so autocompletion of tags is not as accurate as it should be. Luckily, psgml mode provides a way to tell it that the parent is elsewhere. Utilizing this, I wrote a bit of elisp that automatically goes looking for the parent .rhtml file when you load up a fragment. It's just an initial cut, and could use some improvement, but it seems to work for me:
http://www.dedasys.com/freesoftware/files/rhtml-minor-mode.el
On the TODO list:
@content_for_layout.Next.