The computer which hosts this host is a venerable Pentium 150Mhz, with 64Mb of physical memory and two decently sized disks. It has been running non-stop mostly without hiccups for several years, and I'm quite happy with it, even if the processing power is so scarce I've been having to tune down some services as Debian has gotten more resource hungry, dist-upgrade after dist-upgrade. Natura is my 2nd oldest Debian install, coming back from Ham, and after a while it became a home server when it was replaced by an Athlon 700Mhz at my father's house. The only hardware incidents are all related to blackouts or storms: two dead disks and one power supply. The CPU died years ago, but I discovered that many months later. I guess it wasn't so necessary. :) It is time to replace natura, though. The components are aging and they have become quite noisy, despite my attempts to cleanup the dust. Lately it is so loud that I can't understand how my dad can actually get work done with that persistent noise in the room. Besides, it'd be good to get just a little bit more of CPU power to do a few things that have been postponed for a while now. I have been looking for offerings in the embedded devices market. I am looking for a device with the following characteristics:

• Silent: this is a must. If fans aren't involved, that's great, but I know there are some devices with just one fan for the hard drives, etc. which are really silent too. Noise is the #1 reason I want to get a replacement.
• CPU power and RAM: it doesn't need to be too powerful, but of course an improvement over a Pentium 150 Mhz is expected. :) The minimal RAM would be 128Mb, I guess, and if it's expandable/replaceable, that'd be a big plus.
• Power consumption: I have other boxes around which I haven't used to replace natura to get more CPU power because I've always assumed that it'd be hard to match the Pentium's power consumption. As it's up 24/7, I want it to be good in this area. AFAIK, the devices I'm looking for do quite well on this area, though.
• Hard drives: many offerings accept two or four HDs inside the case. I won't need four, but the possibility of setting up RAID is quite attractive.
• Hackable: should be supported by GNU/Linux, and if d-i does a good job on it, bonus!
• Price: last, but not least, I'm willing to spend some money on this, but I probably don't aim for the most expensive devices...

I've found that the Thecus YES Box N2100 is one of the most interesting offerings: 2 Gigabit ethernet ports, two internal SATA HD bays, 3 USB ports... but is a bit too expensive: 350 (without disks). tbm also told me to look at some cheaper PowerPC devices, but I forgot the name right now. So, dear Lazyweb, what would you recommend as a natura replacement for a home server?

After much more work than was necessary, I managed to get Asterisk to blat on the TV the caller ID information of an incoming call. Next I need to see if I can pause the TV, and resume it when the call ends. The MythTV side just needed to be configured to listen on the UDP notify port, the XML templates and whatnot were already there for it (I think installed by MythPhone), so all I had to do was get Asterisk to run this script when a call came in:

#!/usr/bin/perl
use Asterisk::AGI;
use IO::Socket;
# Set this to the broadcast address for your network
$netbroadcast = "172.16.0.255";
$AGI = new Asterisk::AGI;
my %input = $AGI->ReadParse();
my $num = $input 'callerid' ;
my $name = $input 'calleridname' ;
($sec,$min,$hour,$mday,$mon,$year,$wday,$yday,$isdst) = localtime();
$date = sprintf("%02d/%02d/%4d %d:%02d:%02d",$mday,$mon+1,$year+1900,$hour,$min,$sec);
$sock = IO::Socket::INET->new(PeerPort  => 6948,
                              PeerAddr  => $netbroadcast,
                              Proto     => udp,
                              Broadcast => 1 ) or die "Can't bind : $@\n";
print $sock <<EOT;
<?xml version="1.0"?>
<mythnotify version="1"><container name="notify_cid_info"><textarea name="notify_cid_line"><value>Unused</value></textarea><textarea name="notify_cid_name"><value>NAME: $name</value></textarea><textarea name="notify_cid_num"><value>NUM : $num</value></textarea><textarea name="notify_cid_dt"><value>$date</value></textarea></container></mythnotify>
EOT
close $sock;
exit(0);

That was accomplished by just adding an AGI(mythcid.agi) application call to one my existing extensions that handled incoming calls. Future enhancements will involve displaying who the caller wants to speak to after they've selected the appropriate response from the menu we give most callers. The Asterisk::AGI Perl module was a bit hard to track down. I've made a 2 second (dh-make-perl) Debian package of it, available here. If I get sufficiently motivated, I'll consider cleaning it up and uploading it to Debian.

The computer which hosts this host is a venerable Pentium 150Mhz, with 64Mb of physical memory and two decently sized disks. It has been running non-stop mostly without hiccups for several years, and I'm quite happy with it, even if the processing power is so scarce I've been having to tune down some services as Debian has gotten more resource hungry, dist-upgrade after dist-upgrade. Natura is my 2nd oldest Debian install, coming back from Ham, and after a while it became a home server when it was replaced by an Athlon 700Mhz at my father's house. The only hardware incidents are all related to blackouts or storms: two dead disks and one power supply. The CPU died years ago, but I discovered that many months later. I guess it wasn't so necessary. :) It is time to replace natura, though. The components are aging and they have become quite noisy, despite my attempts to cleanup the dust. Lately it is so loud that I can't understand how my dad can actually get work done with that persistent noise in the room. Besides, it'd be good to get just a little bit more of CPU power to do a few things that have been postponed for a while now. I have been looking for offerings in the embedded devices market. I am looking for a device with the following characteristics:

• Silent: this is a must. If fans aren't involved, that's great, but I know there are some devices with just one fan for the hard drives, etc. which are really silent too. Noise is the #1 reason I want to get a replacement.
• CPU power and RAM: it doesn't need to be too powerful, but of course an improvement over a Pentium 150 Mhz is expected. :) The minimal RAM would be 128Mb, I guess, and if it's expandable/replaceable, that'd be a big plus.
• Power consumption: I have other boxes around which I haven't used to replace natura to get more CPU power because I've always assumed that it'd be hard to match the Pentium's power consumption. As it's up 24/7, I want it to be good in this area. AFAIK, the devices I'm looking for do quite well there, though.
• Hard drives: many offerings accept two or four HDs inside the case. I won't need four, but the possibility of setting up RAID is quite attractive.
• Hackable: should be supported by GNU/Linux, and if d-i does a good job on it, bonus!
• Price: last, but not least, I'm willing to spend some money on this, but I probably don't aim for the most expensive devices...

I've found that the Thecus YES Box N2100 is one of the most interesting offerings: 2 Gigabit ethernet ports, two internal SATA HD bays, 3 USB ports... but is a bit too expensive: 350 (without disks). tbm also told me to look at some cheaper PowerPC devices, but I forgot the name right now. So, dear Lazyweb, what would you recommend as a natura replacement for a home server?

Dear friends and teammate,

I'm writing to you from the front of the guerilla, near the bug tracking system. I don't know if you will receive this message, because the cabal is trying to make us silent. It's rough these days. Our autobuilders are overloaded. We already succeeded in delaying the freeze, but it's getting harder and harder. The opponent is now avoiding our attacks by ignoring them. I hope we will still be able to win, but we may need backup.

Yours faithfully,

Julien

Morning! I know, cyrus-sasl2 is a horror for some people because its lack of documentation. So I decided to write this little tutorial. In my example I will use “pam” authentication, I use exactly the same pam rules as I use for the system login, which means pam_ldap. It’s also possible to authenticate directly on LDAP with cyrus-sasl2, but I don’t want this because the “normal” users which I haven’t in LDAP should also be able to use my postfix. Only the users which have access on all machines in my network are stored in LDAP. Ok, first of all: apt-get install postfix-tls (you need -tls, because only this one is compiled with SASL support) apt-get install libsasl2 libsasl2-modules (in -modules is the “pam” module included, for special ones there are other modules, for example -modules-kerberos-heimdal). Then go ahead… add the following lines into /etc/postfix/main.cf which enable authentication: smtpd_sasl_auth_enable = yes
smtpd_tls_auth_only = no # (this is optional, but I want to be able to authenticate without encryption) smtpd_recipient_restrictions = permit_mynetworks, permit_sasl_authenticated, reject_unauth_destination # (means that all machines in mynetworks and the external clients may relay over the server, the external ones have to authenticate) Ok, postfix is now more or less ready. Because postfix on Debian runs in a chroot (/var/spool/postfix) and cyrus-sasl “works” in /var/run/saslauthd you have to make a binding which enables postfix access from the chroot to saslauthd, the following line in /etc/fstab solves the problem: /var/run/saslauthd /var/spool/postfix/var/run/saslauthd auto bind 0 0 Then you have to specify the sasl options to postfix, create a directory “sasl” in /etc/postfix and edit /etc/postfix/sasl/smtpd.conf, there you could enable sasl with mysql, sasl with kerberos, ldap whatever, but as I said I just use pam for it: saslauthd_path: /var/run/saslauthd/mux
pwcheck_method: saslauthd
mech_list: plain login
Last but not least you have to specify the pam rules when used by smtp (because I use pam ), for this you have to edit /etc/pam.d/smtp, because I have LDAP and local users enabled in the /etc/pam.d/common-* files I just include them: @include common-auth
@include common-access
@include common-password
Yes, and that’s already all, not so difficult, is it?

I feel a little stupid for my last post about my unstable machine. It was the hardware to blame and my hard drive finally crashed during a Linux conference in Mendoza, Argentina. Typical. At the conference there wasn´t much new for me and I regret that I didn´t get organised enough to give a talk about the Web and WHATWG stuff. Though I did manage to meet good people and talk about some topics that are of interest to me. As usual the fabulous friendly CafeLUG geeks from Buenos Aires were there, led by the wonderful DD Marcela. I also met an inspiring guy from Cordoba who founded a successful software company that works with free software. His brother gave a great talk about it at the conference. I really love to see Free software power people to start a business. Oh and about my thinkpad X40 hard drive replacement. With the help of another new friend Fredrico from Mendoza, we called up IBM in Buenos Aires and arranged a new hard drive and a battery within 5 days! I didn´t know if my machine was under warranty still, phew. Unfortunately IBM called the next day saying they didn´t have any stock and the wait from the US is about 2 weeks. Since I have no idea where I will be in two weeks (ok, probably Sao Paulo, Brazil) I cancelled that request and now I have found a free Windoze (hopefully not trojaned) terminal just over the Andes, in Santiago Chile. Tough life!

I feel a little stupid for my last post about my unstable machine. It was the hardware to blame and my hard drive finally crashed during a Linux conference in Mendoza, Argentina. Typical. At the conference there wasn’t much new for me and I regret that I didn’t get organised enough to give a talk about the Web and WHATWG stuff. Though I did manage to meet good people and talk about some topics that are of interest to me. As usual the fabulous friendly CafeLUG geeks from Buenos Aires were there, led by the wonderful DD Marcela. I also met an inspiring guy from Cordoba who founded a successful software company that works with free software. His brother gave a great talk about it at the conference. I really love to see Free software power people to start a business. Oh and about my thinkpad X40 hard drive replacement. With the help of another new friend from Mendoza, we called up IBM in Buenos Aires and arranged a new hard drive and a battery within 5 days! I didn’t know if my machine was under warranty still, phew. Unfortunately IBM called the next day saying they didn’t have any stock and the wait from the US is about 2 weeks. Since I have no idea where I will be in two weeks (ok, probably Sao Paulo, Brazil) I cancelled that request and now I have found a free Windoze (hopefully not trojaned) terminal just over the Andes, in Santiago Chile. Tough life!

To try and make it easier for non-Francophone Anglophones to understand this complaint and response in English, an attempt at translating the email is below. Errors are all mine:-

Our community (Debian) has a defect: the noisiest (and evidently the most extreme) are always the most visible. It is very regrettable that the people who say they represent Debian at JDLL, who are always only some of the 70 French developers of a thousand-developer project with many thousands of contributors, can have given you this totally false image. Their provocation was totally purile, even if the subject is a true subject of discussion. Unfortunately, this sort of position will always exist. I hope simply that the people who have been shocked by this childish behaviour and the also-totally-purile comments appearing in 24 hours on various blogs will have the intelligence not to fall in the same trap as their opponents, notably the easy amalgamation. Extremism doesn't always win in Debian (and not even as often as that), compare the last votes: http://lists.debian.org/debian-devel-announce/2006/10/msg00018.html http://lists.debian.org/debian-devel-announce/2006/10/msg00017.html and so on. I would appreciate it if this appears in your blogs to temper a little the unacceptable comments that you have received from certain people... and I allow myself to give you respectively meetings at the next Solutions Linux to discuss all this calmly over $BEVERAGE. [ENDS]

I think posting the above without making it clear that it is a one-man initiative and apparently sent without consulting those criticised was downright sneaky and always going to offend. The daft acts of people at JDLL cannot be corrected honourably by more daft acts! The message also seems to me to suggest that it's somehow extreme to object to the Mozilla Corporation using trademarks to stop Firefox and friends being freely-modifiable free software (by requiring inclusion of material with no copyright permission to modify) and to try to dictate what goes into distributions. Unlike the firmware problem, Mozilla's trademark terminators are an obvious and active practical problem for debian maintainers and downstream. I hope the Mozilla fans who were upset by such a "childish" non-obvious reminder [JPEG, 70Ko] about the MozCorp trademark offensive will bring MozCorp into line. If not, I hope that the next time is better satire that informs more people and avoids the "purile" tag.

(update with stupid formatting errors fixed) Yes, partly. Julien implictely asks for apologies in his recent blog posting. Because I usually don't like to let conflict rot, I tried thinking about it and draw conclusions. I still think that the attitude of people who started the incident at the JDLL has been really bad and gives a poor image of the Debian project. This is what I intended to explain to the Mozilla representative in my mail. I definitely feel the need to explain that Debian is anything but a monolithic project and when I feel that this project is hurted by the attitude of some of its members, yes I feel the need to correct people's feelings. This mail was sent before Julien sent more explanations, privately and publicly, to me when he read my blog posting. I have to admit that Julien explanations have been clear and detailed and give another light on that story. So, maybe after reading them, I would not have sent that very mail he obviously violently reacts about, or it would have been worded differently. For this, yes, I apologize, Julien. On that very action, I haven't been as wise as I thought. I indeed failed the exact same way I think you guys failed. Probably because I was deeply hurted by seeing someone I've crossed in the french free software community for nearly 15 years (Daniel Glazman) having such a poor opinion of the project that counts the most for me. Does this change what I think? Probably not. Yes, it is a bit paternalistic to think that part of our community is unecessarily childish in its way to express its opinions. *This* is what IMReallyNSHO hurts the project and this deeply lowers the credibility of Debian in the overall community and, I'm afraid, more especially in our country. So, no, I will not apologize for my opinions and, yes, I claim some experience in conflicts solving, negotiation handling and managing the public image of the work I'm involved in. The general conclusion of all this is certainly that I should really have kept my current stance: focus on technical stuff and avoid wasting time, and maybe hurt the project, in "political" discussions. So, please Julien, consider this: is that really fair for people who appreciate your work as well as those who share your ideas, to lower your involvment because you have a conflict with another person? With no doubt, your work in Debian has received deep respect by a vast majority of our fellow Debian contributors. So is the work by Joss, who is probably among the persons I disagree the most with in our French community and who dislikes myself the same way you do. So what? Is that fair to hurt the project because you've been hurted by one of its members? I don't think so and I really hope that people whose opinions you have more respect for than mine will convince you to reconsider that stance. OK, this will sound paternalistic again, so I should probably stop by now. That blog posting is likely be the last non technical until we release Etch. And, as I don't like discussing technical stuff in blogs, it will probably be the last one until we release Etch.

I believe that adding blogging technology to bug tracking systems (such as the Debian BTS and the Red Hat Bugzilla) offers significant benefits for users and developers.

It seems that there is only one significant difference between the features offered by blog software and the features required by bug trackers, blog entries are owned by the person making the post (the owner of the blog) and BTS entries are owned by the package owner. This is a minor technical difference, adding the ability for anonymous users (or users who have authenticated via an email address or other method) to create new entries in a blog owned by someone else is a minor feature change. Once the entry is created only comments would be accepted, and comments could be made in the usual manner with moderation etc.

The benefits of using blogging software (or extending current BTS systems) would be to have RSS feeds of bug reports and comments on bugs, include a single feed of all bug reports (IE blog entries) and updates (IE comments on blog entries) for a single blog (IE package) - this functionality doesn't seem to be common in blog software but surely will be soon.

This would allow Planets of recent bug reports in distributions or in areas. EG a SE Linux planet installation could syndicate the bug feeds for packages in Fedora and Debian as well as other sources of SE Linux information. The SE Linux bug feeds could include all bugs with the selinux tag in all blogs on the BTS, thus a single Planet configuration could easily cover all new development and debugging.

Another configuration possibility would be to have a single blog for all bugs in a distribution and to have tags for each package, this would become messy though as tags have to be used for issues that are not specific to packages (EG a "selinux" tag would list bugs in all packages that relate to SE Linux).

Tags could be changed by any user (possibly with some restrictions), and there could be special tags for release-critical bugs or for bugs in different stages of QA (for example the Red Hat Enterprise Linux approval process could be managed by adding certain restricted tags to the bug - this would also allow getting a feed of all bugs that have passed certain approval milestones). This would make it easy to get a list of all bugs in a certain approval category.

Current BTS systems such as the Debian BTS and the Red Hat Bugzilla could be extended to syndicate content. As they already have web interfaces and support automatically sending updates by email it should be easy to add the basic level of such support to them. But it might give a better result to go the other way and modify a multi-user blog system such as Wordpress-MU to have extra features for bug management.

BTS systems typically have bug ID numbers that increase sequentially while blog software typically gives something like http://blog.example.com/YYYY/MM/blog-entry-name.html when it's often more convenient to have something like http://bug.example.com/number. Of course it would not be difficult to have a little database that allows creating sequential numbers to map to arbitrary URLs in a similar manner to tinyurl.com. This could be either integrated into blog software (so that it says "bug #1234 has been created" or be available on demand (click a link to get a sequential number assigned). Incidentally using characters and digits for the short name of the bug (as done by tinyurl.com) would allow four characters to represent 1679616 bugs, this is enough for all bugs in the Debian and Red Hat bug databases combined. With tinyurl type technology there is nothing preventing us from having a single system creating unique IDs for all bugs in all distributions of Linux with a four character index (which is easier to remember than the 6 sigit numbers used in Debian and Red Hat at the moment).

I realise that most blog software will store the entries in a database which has sequential numbers assigned. So doing a database lookup to convert a human-readable URL into a sequential index when we have just done another database lookup to convert a sequential index into a human readable form is inefficient, but that's the way of things, computers do things inefficiently so that humans can work in ways that are efficient for them.

Note that throughout this post I refer to the Planet aggregation system, but really any of the aggregation systems can be used. One of the benefits of this is that people can use mailing lists, Google's reader, Planet, or any other reader they wish with the feeds. RSS feeds can be read by many programs and the user gets to choose which works best for them.

Catching up on blogs, emails and Debian mailing lists I see that nothing really important has happened while I was off-line: the dunc-tank caboodle escalated and died down when the majority voted that it was not worth the commotion, some people got upset at some other people and decided stop working on Debian because of that, Mozilla went even more bonkers about its trademarks. The dunk-tank scandal ended just like I thought it would. As one could imply from my eternal unstable concept, I do not see making releases as a the main thing that Debian contributes to the society - it is more about the integration and cross-empowerment of all the packages that Debian has. In that context, making a release is a not the most important job in Debian, but it need to be done from time to time. Release management combines technical and social challenges - there is not much of novelty in it (I imagine). So, from this perspective, there is nothing bad in money being paid to do this mundane and hard work, if we really, really need to release in a specific time frame (IMHO the only reason to release Debian in 2006, as opposed to 2008, is the Lars tattoo bet). If we return to “release when its ready” paradigm and aim for about one release every 2-3 years (and I see nothing really wrong with that) then paying release manager will not be needed. Money is about getting things done on a schedule. It does not make things good (or bad). It does not make thing important (or not). It make things go by the schedule (unless you pay by the hour). It is the obvious solution to releasing Debian in December. Now two questions need to be answered - will it work? and do we really want to release in December? The second thing - in any group of 1000 people anyone can easily find a lot of people that he would not love/not respect/disagree with/disregard/hate and be unable to work with. It is no reason to stop working on Debian, unless one does it only to be universally loved. It is inevitable that we will need to learn to do what we like to do without paying attention to the irritations. And about the trademarks - in Debconf 5 in Helsinki I was giving a talk at the Debian Day, just after I helped to win the first big fight against software patents in EU, and Branden (who was GPL at the time) asked me what do I think Debian should do about its trademarks. Both then and now I strongly think that trademarks and any other litigation inducing concepts (except enforcement of GPL) have no place whatsoever in free software. I think Debian should lead the way and give up the “Debian” trademark. And Mozilla should follow the lead. So what if there is a pron site “Debian chicks”? You will not solve that with litigation anyway (at least not in a year or two) and why should we really care? So what if some one make a distro and calls it SuperDebian? If someone will really think that it is related to Debian but better (especially despite warnings to the contrary), then that someone will really deserve to get the trojan planted in that distro. And again, against a well prepared criminal, litigation will not help much. So, did I miss anything?

Yes, partly. Julien implictely asks for apologies in his recent blog posting. Because I usually don't like to let conflict rot, I tried thinking about it and draw conclusions. I still think that the attitude of people who started the incident at the JDLL has been really bad and gives a poor image of the Debian project. This is what I intended to explain to the Mozilla representative in my mail. I definitely feel the need to explain that Debian is anything but a monolithic project and when I feel that this project is hurted by the attitude of some of its members, yes I feel the need to correct people's feelings. This mail was sent before Julien sent more explanations, privately and "a href="http://blog.technologeek.org/2006/10/15/29">publicly, to me when he read my blog posting. I have to admit that Julien explanations have been clear and detailed and give another light on that story. So, maybe after reading them, I would not have sent that very mail he obviously violently reacts about, or it would have been worded differently. For this, yes, I apologize, Julien. On that very action, I haven't been as wise as I thought. I indeed failed the exact same way I think you guys failed. Probably because I was deeply hurted by seeing someone I've corssed in the french free software community for nearly 15 years (Daniel Glazman) having such a poor opinion of the project that counts the most for me. Does this change what I think? Probably not. Yes, it is a bit paternalistic to think that part of our community is unecessarily childish in its way to express its opinions. *This* is what IMHO hurts the project and this deeply lowers the credibility of Debian in the overall community and, I'm afraid, more especially in our country. So, no I will not apologize for these opinions and, yes, I claim some experience in conflicts solving, negotiation handling and managing the public image of the work I'm involved in. The general conclusion of all this is certainly that I should really have kept my current stance: focus on technical stuff and avoid wasting time, and maybe hurt the project, in "political" discussions. So, please Julien, consider this: is that really fair for people who appreciate your work as well as those who share your ideas, to lower your involvment because you have a conflict with another person? With no doubt, your work in Debian has received deep respect by a vast majority of our fellow Debian contributors. So is the work by Joss, who is probably among the persons I disagree the most with in our French community and who dislikes myself the same way you do. So what? Is that fair to hurt the project because you've been hurted by one of its members? I don't think so and I really hope that people whose opinions you have more respect for than mine will convince you to reconsider that stance. OK, this will sound paternalistic again, so I should probably stop by now. That blog posting is likely be the last non technical until we release Etch. And, as I don't like discussing technical stuff in blogs, it will probably be the last one until we release Etch.

There is currently a big debate in progress in Debian. I am not going to mention any specifics because too much of it has already been blogged (maybe in the same syndication in which you read my blog).

I think that the way things are going is more an illustration of the failings of mailing list culture than of failings of Debian. Maybe another mechanism would be more productive in leading towards a solution.

One option that occurred to me is debate via wiki. If each side had a wiki page that they could modify then in a small amount of time we should get a set of two main consensus opinions which would each be explained clearly and summarised well. Then with two options clearly expressed the people who have less strong opinions could decide which option they favor. For this to be a quick solution honorable behaviour would be required from all people involved, if people start trying to sabotage the other group's wiki entries then it would significantly increase the time taken to achieve things.

Another possibility that occurred to me is debate via blog. The quality of blog postings is expected to be a lot higher than that of mailing list discussions as all posts are tied to the author's public image. Writing content-free messages on a mailing list is easy, but every blog entry needs to stand on it's own to a certain extent and anyone who writes flames in most of their blog entries will probably find that the readers like it less than the readers of a typical mailing list.

Maybe when an issue is recognised as highly contentious a few people could blog about it and then form groups to develop wikis to promote their views. A debate might start out with five or more different competing views, some of them would merge until there were only two main opinions being pushed. Then once the two remaining groups had sorted out their positions a vote would be easier to arrange.

What do you think?

It's official, a friend and I have submitted our application to Y Combinator for the winter submission deadline. Hopefully within the next week we'll be lucky enough to make it at least to the interview process in MA. Unfortunately, my ANSI Common Lisp book is back in Ohio at the moment so I won't have a chance to bring it along and proclaim my inner fanboy when we meet with Paul Graham and Co. It will be interesting to leave work at my current internship early on a Friday to fly to MA for this opportunity though. I'm lucky I'm finished here in Washington by December.

Alas, I may never graduate at this rate. But at least the ride has been thrilling and informative. If anyone has participated in the Y Combinator program and has any advice / wisdom to impart I would be grateful if you passed it along to chris[at]nullcode.org.

There are a few things that I'd like to have in my fd.o-compatible system tray, but that do not seem to exist at this time (either that, or I haven't been looking too carefully):

• An application to manage my Kerberos tickets. It should display how much time I have left before the tickets expire, allow me to renew them with a click on a button, and (optionnally) pop up a window when the tickets are about to expire.
  The ability to log in to kerberos and/or to change my password is nice, but not required (I have PAM set up to do that).
• An application that will show me how much battery power I have left, in a PMU-specific way. I'm perfectly aware of the fact that there are a number of applications that can query the battery state on my powerbook by using the PMU driver's APM emulation, but I want to have the extra data that the PMU driver knows about (such as the amount of power I'm burning); that won't be available if I use the APM emulation. Additionally, I hate udev with a vengeance, so it must not use that (or hal, which depends on udev)

Anyone know of such a thing?

The word on the streets (in my comments really) is that Epiphany may be the future of reliable web browsing so I will have to check it out. I also got an excited email today about a firefox plug-in that is for the (academic) gods: zotero… It looks pretty nifty and handy but since I don’t even use a bibliographic program like End Notes, at least I am not missing out on huge functionality, which reminds me, does anyone have opinions on good GUI free software bibliography programs ?

As promised yesterday in my report about the Munich BSP, I'd like to talk some more about LiMux, the project being run within the City of Munich to replace all of their desktop Windows systems with Linux. The team kindly offered us the use of their offices in central Munich as a base for the BSP last weekend, and on Sunday afternoon they gave us a demonstration and answered lots of our questions. The following is from my (known-faulty) memory...

Jan-Marek and Florian talked us through their setup. They're using FAI to automate installation of systems, along with LDAP to store lots of configuration information and GOsa as a user-friendly front-end to that configuration. They've integrated these to enable some very clever management features so that all aspects of the city-wide system can be maintained from one central point. As new machines are introduced onto the network, they can be configured into one class or another: simple desktop clients up to so-called "depot" servers, used as seeds for further clients. Individual user profiles can be tweaked, giving users access to new applications as they are needed. Shared resources like network storage and printers are set up automatically from the LDAP database. Access to USB storage devices can be controlled on a per-device, per-user basis for security. That's quite an impressive feature list. Most of the work has been in configuration and systems work rather than custom packages on the clients themselves - the vast majority of the packages installed come straight from the standard Debian archive, with some backports (like a newer version of KDE). Building on top of standard packages means that they have access to a huge amount of Free Software without having to do all of the work themselves. A small team (10-ish at the moment, growing to 100 or so in the future) can effectively deploy and manage desktops and associated servers for a huge number of users - they're expecting to be supporting on the order of 30,000 systems 2 years from now. The team have just recently made their first stable release and are starting to roll it out across the city, one department at a time. There are the familiar issues involved in the deployment, of course. For example, users don't want to help test pre-release versions to help nail bugs, but then complain loudly when they find bugs in the first release. And in such a large project to migrate from predominantly Windows (NT4!) desktops to KDE on Linux, a major part of the effort needed is in user training. There is quite a bit of support and custom work needed to convert people's MS Office macros over to working on top of OpenOffice. And there are still quite a number of users who will remain using Windows for specific applications that still don't have Linux equivalents yet. Apparently the "Wine Cellar" group will help on that front. *grin* In terms of collaborating with Debian, the LiMux team are expecting to help in a few ways. As bug reports are filed against their applications (apparently very few so far), they'll be pushed upstream along with (hopefully) fixes for them. They will also be devoting some full-time developer effort to security work; it would be good for both sides if this effort can be shared.

It was quite striking to see Tux, the Linux penguin, as a visible logo in local government offices! The team have clearly made some excellent progress on this exciting project, and I'm sure that I can speak for all of Debian in wishing them the best of luck in the future. I'll be watching with interest...

The recent news from the UK gives us an example of invasive security. Preventing passengers carrying on any hand luggage (even wallets) and frisking all of them is the type of treatment you expect for criminals and visitors to maximum security prisons. It's not what you expect for people who are involved in routine (or what used to be routine) travel.

The security measures offered by SE Linux are sometimes described as invasive. I don't believe that this is an accurate description. I admit that sometimes minor tweaks are required (such as setting the correct context of a file). But for most users (corporate users and typical home users) the distribution takes care of all this for them. A default Fedora install should just work for the typical home user and a default Red Hat Enterprise Linux install should just work for the corporate user.

The main reason that it's so easy to use is that the default domain for user sessions and for daemons that are not specifically configured in the security policy is unconfined_t. This means that programs for which there is no policy and programs run from a user session do not have SE Linux access controls. The default configuration of SE Linux only restricts programs that are known to be at risk.

The most common case of SE Linux access controls causing inconvenience is the policy for Apache (the daemon with the most configuration options). There are a set of configuration options (known as booleans) that can be used to determine what aspects of Apache will be confined, generally it only takes a few minutes to determine and specify the correct settings to support the desired operation.

Next time you are being frisked at a UK or US airport and are facing the prospect of a long flight with books and all other forms of entertainment banned keep in mind that airlines have invasive security and should be avoided if possible. SE Linux offers security that is at most a minor inconvenience (usually not even noticed) and should be embraced.

An anti-spam measure that is used by a very small number of people is that of verifying the sender address by connecting to the sending mail server. For example when I send mail from russell@coker.com.au the receiving machine will connect to my mail server and see whether it accepts mail addressed to russell@coker.com.au and will reject my mail if that isn't the case.

The problem with this is that if I try to send mail to someone who has their mail server listed as a SPAM source then their efforts to verify my email address will fail and then my message to them will bounce with a confusing error message. This means that if one of the two mail servers involved in the communication is listed in a DNSBL or RHSBL service then all communication will be impossible. There will not be an option for one person to say "please phone me on this number if you can't send me an email".

This happened recently when someone from Italy asked me a question about SE Linux. So I will answer here (maybe they read my blog). In any case the answer might be of general interest:

Firstly I have to note that I have a B.Sc degree and no post-graduate qualifications, so it is not accurate to address me as Dr. Coker.

The question is: Let's imagine a user acquire root rights. Especially on Fedora Core, which modify su command to map it to sysadm_r role, couldn't he/she simply disable SELinux, delete logs, and so on?

If a user obtains ultimate privileges then they can do all things including deleting logs etc.

One thing to note is that there is no need for any process other than kernel threads to have ultimate privs, it would be useful in some situations to make log files append-only for all processes and the SE Linux policy language supports this.

The nearest any release policy comes to implementing such things is the separation between sysadm_r and secadm_r in the MLS policy in recent versions of Fedora.

Also note that it is possible to configure a SE Linux policy that does not permit any process to request that a new policy be loaded, the policy files be changed on disk, or the use of programs such as debugfs. Using SE Linux to enforce a policy that can not be bypassed by anything less than booting from installation media is quite easy to achieve.

One idea that I had was to have GPG implemented in the system BIOS and have GPG checks performed on the kernel before it's loaded (to verify that the kernel had not been modified). The kernel could be passed a decryption key for the root filesystem by the BIOS, and SE Linux would be enabled as soon as the root filesystem was mounted. Thus nothing less than disassembling the BIOS would allow a hostile person to access the data on the disk. This is all possible with technology that has been common for many years. I almost convincced a BIOS author to implement this in about 2002.

In the game show The Weakest Link competitors get voted off, usually not on whether they are weak but on whether the other contestents consider them to be a threat. It's mildly amusing as a TV game show but not funny at all when carried out on an airline.

Recently a flight from Malaga to Manchester was delayed because two passengers were considered to be suspicious by other passengers (either 6 or 7 passengers refused to get on the plane because of this). The passengers were thought to be speaking Arabic (as if there was anyone on the plane who would recognise Arabic when they heard it) and because they were wearing coats and looking at their watches. The two men in question had been searched twice and found to be clean, but a bunch of idiots on a plane thought they knew better and demanded that the passengers in question be removed.

Lessons to be learned from this for travelling to/from coalition of the willing countries:

1. Avoid the urge to check your watch when your flight is being delayed unless you are white. Non-white people who do what white people do in this situation are considered to be terrorists.
2. When travelling to a cold place (such as Manchester) you want to have a coat to wear when getting off the plane. The airline staff won't allow you enough hand-luggage space to store a coat so you will want to wear it when getting on the plane. This is fine if you are white, but if not white just deal with the fact that you will shiver when disembarking.
3. Learn to speak English for your travels. If you speak another language you will be considered to be a terrorist.
4. Whatever country you visit, stick to major cities as much as possible. Smaller cities have more racists and nationalistically bigoted people, there probably wouldn't have been a problem on a flight to London.
   

Also just avoid the coalition of the willing countries in your travels as much as possible. There are much less problems in this regard when the government doesn't depend on terrorism hysteria to justify going to war on the basis of lies.