To follow up on yesterday’s MBTA philippic, I received a response from the T’s customer service regarding my complaints. Although it doesn’t give me hope that things will improve, it’s nice that they have at least hired someone to write personalized, polished replies. At least they can do that right:

Dear Mr. Kessel, Thank you for your email concerning service on the Needham Line. The past couple of months have been difficult for our passengers, and I want you to know we are very sorry for the inconveniences this has been causing. The causes of these delays have ranged from signal and mechanical issues to long stops boarding passengers at stations, and even track work on other lines. I know that it may seem odd that trains on other lines can impact your trains, but I assure you that is true. The Franklin, Needham, Providence, and Stoughton lines, as well as Amtrak all share the rail between Hyde Park and Boston. All it takes is one delayed train in this area to cause a cascading effect that delays other lines. There’s also the fact that trains may come in from one line to go out as another. For example, a train on the Worcester Line comes to Boston, and either the train set, or the crew (sometimes both) head out as an outbound Needham train. If the inbound is late from Worcester, then the outbound Needham will be late, which also means that its “turn,” the next inbound, will be delayed. In response to your comment about the doors not all being opened, even with a full compliment of conductors, crews are not able to staff every door, and especially at ground level stations we want to ensure that all customers are able to board and detrain safely. This is why conductors do not open all doors to the train. I contacted our Mechanical Department, asking that the PA system on train 625 be checked out to make sure everything is working properly. Please know that delays in service are not something that we take lightly, and all departments are committed to working together to ensure that our customers receive timely, safe, and reliable service. Once again, I am sorry for the inconvenience this has caused you. Thank you for writing. Sincerely, Linda Dillon
MBCR Customer Service Manager

Share This

I just released new version of Gammu. It just adds compatibility with more OBEX phones by providing fallback to AT commands and index based IrMC access. Full list of changes:

• Automatically fall back to AT commands when OBEX does not work.
• Initial support for IrMC index access.
• RunOnReceive is now also supported on Windows.
• Handle correctly case when memory is full (OBEX) (bug #404).

PS: I also created Jabber conference room for Gammu, see Wammu support page for details.

Last Sunday, the 30th Chicago Marathon took place. This was meant to be the year to make this marathon even bigger: the field had increased substantially to 45,000 registrations yet it still sold out way earlier than in previous years. As it turns out, the weather did have its own surprises in store. Earlier in the preceding week, the forecast changed from overcast and rainy to sunny. And sunny it was. While we had a bit of cloud cover at the start at 8:00am, temperatures were already in the 70s and keep increasing. This year's marathon is now on the books as the hottest ever: the clouds dissipated and it was a scorcher. Needless to say, it was a rather challenging race. I finished in 3:41:39, which is my slowest time by some margin for the by now seven marathons I've ran. It was not the day for running fast. Of course, I didn't quite grok that at the start and ran ten miles reasonably hard in a quick pace, but then paid for it, and then paid some more. That said, apparently around 10,000 registered entrants didn't even start, and another 10,000 did not make it to the finish. With the heat, several hundred were treated by the medical teams. Worse still, one 35-year old runner from Michigan died (though the autopsy claims he had a heart condition; other reports say that alone cannot have been lethal). The race itself was aborted, and those who had not reached the half-way point by 12:00am were diverted to the finish and urged to walk rather than run. According to the (by now fairly extensive) news coverage, this whole experience left quite a few people mad and bewildered. As of today, a good 48 hours after the race, the City seems to be in some sort of crisis management mode to prevent damage for the oh-so-important bid for the 2016 Olympics. For some flavour of the news coverage, see an early report, some stunning pictures and some suggestions to prevent another one like this, all from the Chicagoist blog.

Problem present in openscenegraph 1.9.x and 2.x series: bug #425837. Looking at the build logs of unstable or experimental for the hppa architecture, there's a linking problem around. Shorten error message:

/usr/bin/g++ -fPIC -shared -Wl,-soname,libosgUtil.so.6 
    -o ../../lib/libosgUtil.so.6.0.0 "many *.o"
    -L/build/buildd/openscenegraph-2.2/build/osg/lib  -losg
    -lOpenThreads -lGLU -lGL -lSM -lICE -lX11 -lXext -lm -lpthread
    -Wl,-rpath,/build/buildd/openscenegraph-2.2/build/osg/lib 
/usr/bin/ld: CMakeFiles/osgUtil.dir/Optimizer.o(.text._ZNSt8_Rb_tree 
     IjSt4pairIKjSt3setIPN3osg9Texture2DESt4lessIS5_ESaIS5_EEESt10_S 
     elect1stISA_ES6_IjESaISA_EE9_M_insertEPSt18_Rb_tree_node_baseSH 
     _RKSA_("unmangled name"): cannot reach 0000393f__ZNSt10_Select1 
     stISt4pairIKjSt3setIPN3osg9Texture2DESt4lessIS5_ESaIS5_EEEEC1Ev+0,
    recompile with -ffunction-sections
/usr/bin/ld: final link failed: Bad value

First, just in case demangling is needed (that's not the case, but imagine), there's a nice tool to get the signature back (output skipped, it is very huge, that C++!). That's c++filt from the binutils package:

c++filt _ZNSt8_Rb_treeIjSt4pairIKjSt3setIPN3osg9Texture2DESt4lessIS\
5_ESaIS5_EEESt10_Select1stISA_ES6_IjESaISA_EE9_M_insertEPSt18_Rb_tr\
ee_node_baseSH_RKSA_

Then, one tends to trust the compiler. Added the following to the cmake command in debian/rules:

-D CMAKE_CXX_CFLAGS='-ffunction-sections'

But not much better. Oh wait, there's a quite interesting string in the build log now: cannot handle R_PARISC_PCREL17F, which looks like quite arch-dependant and perfect to be searched through the internets. Some old bugreports came out: bug #334959 and bug #416496 and the solution: use -mlong-calls. From http://www.projectblackdog.com/3rdParty/gcc/HPPA-Options.html, the relevant parts: Generate code that uses long call sequences. This ensures that a call is always able to reach linker generated stubs. [ ] It is normally not desirable to use this option as it will degrade performance. However, it may be useful in large applications, particularly when partial linking is used to build the application. It looks like it might do the job. And indeed it does. Conditionally added for the hppa architecture. And -ffunction-sections isn't even needed. Thanks to the http://www.parisc-linux.org/ folks for the access to their cluster, which really helped finding out a fix very quickly! And it looks like the number of blockers for the transition to testing has been reduced. \o/

Actually, granny rage against the machine….

In a comment on my previous post about SE Linux and worms/trojans [1] a user enquired about which methods of gaining local root are prevented by SE Linux. A local exploit is one that can not be run remotely. An attack via TCP or UDP is generally considered a remote exploit - even though in some cases you might configure a daemon to only bind to localhost (in which case the TCP or UDP attack would only work locally). When compromising a machine it’s not uncommon for a local exploit to be used after a remote exploit or social engineering has been used to gain non-root privileges. The two most common types of local root exploit seem to be those which attack the kernel and those which attack a SETUID process. For a non-SE Linux system it usually doesn’t matter much how the local exploit is run. But a SE Linux system in a default configuration will be running the Targeted policy that has almost no restrictions on a user shell session. So an attacker who wants to escalate their privileges from local user to local root on a typical SE Linux system has a significant benefit in starting from a user account instead of starting from a web server or other system process. In the SE Linux model access is granted to a domain, and the domain which is used for a process is determined by the policy based on the domain of the parent process and the labelling of the executable. Some domains are not permitted to transition to any other domains, such as the domain dhcpd_t (used for a DHCP server). Other domains are only permitted to transition to a small set of domains, for example the domain httpd_t (used for a web server) can only transition to a small number of domains none of which has any significant privileges. On a machine running without SE Linux a compromise of a DHCP server is game-over as the server runs as root. A compromise of a daemon such as Apache on a machine without SE Linux gives unrestricted access to run applications on the systems - if a SETUID-root program has a security flaw then you lose. The same bug in a SETUID program on a machine running SE Linux is not fatal because SE Linux will prevent the program from doing anything that it’s parent could not do - even if an attacker made Apache run a buggy SETUID program the broken program in question could do nothing other than what Apache is normally permitted to do. A security flaw in a SETUID-root program on a SE Linux system can still be exploited by a local user (someone who has logged in) when running the Targeted policy. When running the Strict or MLS policies many such vulnerabilities will not be exploitable by local users (for example exploiting PING would only permit network access). As a rule of thumb you should consider that a kernel security flaw will make it possible to bypass all other security features. However there are some situations where SE Linux can prevent local exploits. One example is a bug discovered in July 2006 which allowed the creation of SETUID files under /proc [2], the targeted policy of SE Linux prevented this from working. Another example is CVE-2003-0127 [3] (a kernel security flaw that was exploited by triggering a module load and then exploiting a race condition in the kernel module load process), the commonly used exploit for this did not work on a SE Linux system because the user process was not permitted the socket access used to trigger the module load (it is believed that an attacker could have written a version of the exploit to work on a SE Linux system - but AFAIK no-one ever did so).

• [1] http://etbe.coker.com.au/2007/10/08/selinux-storm/


• [2] http://lwn.net/Articles/191954/


• [3] http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2003-0127

Share This

Paul Russell writes about his 3-yearly laptop replacement at IBM [1]. It probably makes some sense to replace laptops periodically for a large company, but if you are buying for personal use then it makes sense to try and get a longer life out of an expensive machine. I think that aiming for 6 years is quite reasonable with today’s hardware - you should be able to buy a new machine now and have it last 6 years or buy a 3yo second-hand machine and hope to have it last 3 years (most second-hand laptops on sale in every place other than Ebay were trophies for managers and never had any serious use). If you are going to buy a second-hand laptop the first thing to consider is PAE support. If you get a laptop without PAE support (I think that means all Pentium-M CPUs) then you will not have proper Xen support (it seems that all distributions have abandoned Xen support for PAE for the moment). This may not be a big deal if you don’t want Xen, but if you are a programmer then you probably do want Xen (even if you don’t realise it yet). The next issue is support for the AMD64 instruction set. 32bit laptops are going cheap at the moment but if you buy one you will be significantly limited as to what software you can run at some future time (my 32bit laptop is doing well at the moment apart from the lack of PAE support). If you are buying a new laptop then the first thing to consider when planning a long life is the warranty. In my experience most computer gear does not need a long warranty, if it survives 3 months then it’ll probably last until it’s well obsolete. Laptops however periodically wear out if used seriously, I average one warranty replacement of a Thinkpad keyboard every two years and I have had a few motherboard replacements (the lighter Thinkpads flex and they eventually break inside if you use them on enough trains, trams, buses, planes, etc). On one of the Lenovo T series Thinkpads that I saw advertised (one that I would consider if I wanted a new laptop now) there was an offer to spend an extra $350AU to get extend the warrantee from 1 year to 5 years (according to my understanding of the confusing text on the web site) on a laptop that cost $3050. An increase in the purchase price of 12% for the extra warranty is a bargain (I know that for my use they would lose money on the deal). Repair of a laptop is generally very expensive, any serious damage to a laptop that is more than 18 months old will generally mean that the replacement cost is less than the repair cost. The next thing to consider is the screen resolution. After purchasing a laptop you can upgrade the RAM and the hard drive, the CPU power of all modern machines is great enough that for most typical use it’s difficult to imagine any need to upgrade. But screen resolution is something that can never be good enough and can never be improved after purchase. Lenovo is offering T series Thinkpads with 1920×1200 resolution for $4000AU and 1680×1050 resolution for $3050AU. That’s 31% more pixels for 31% more money and seems like a good deal to me. I believe that a larger display can significantly increase productivity [2] so it seems that the extra expense would be a good investment if you plan to earn money from work you do on your laptop. As a point of reference a desktop monitor from Dell (who seems to be the cheapest supplier for such gear) with resolution of 1920×1200 will cost at least $1000AU. The hard drive capacity should not be an issue, it seems that 100G is about the minimum size. The 60G drive in my current Thinkpad is adequate for my development work (including several Xen instances and some ISO files for a couple of distributions) so unless you plan to collect MPEG4 files of TV series and store them on your laptop I can’t imagine 100G being much of a limit. Also external storage is getting quite cheap, 2GB USB flash devices are now in the bargain bin of my local electronics store and USB attached hard drives with capacities of 40G or more are getting cheap. Also with a Thinkpad replacing a hard drive is really easy and does not risk damage to the drive or the rest of the laptop (I don’t know how well other brands rate in this regard). For RAM you can buy a model with a large memory module in socket 0 (or attached to the motherboard). Adding new RAM later is easy to do. Just try and avoid purchasing a memory capacity that involves having all sockets filled with modules that are not of the maximum size - it’s annoying if you have to try and sell modules on Ebay after you buy a memory upgrade. Finally one mistake I made in the past was to not get all the options for the motherboard. Make sure that every option for Ethernet ports and 802.11 type protocols is selected. It might sound like a good idea to save $100 or so on not getting one of those options, but if you end up repeatedly plugging a CardBus or USB device for many years you will regret it. Also external devices tend to break or get lost. Rusty documents his laptop replacement as a time for spring-cleaning. I use LVM for the root filesytem on my Thinkpad so that I can easily install a new distribution (or a new version of a distribution) at any time. I’ve been through that spring-cleaning a couple of times on my current Thinkpad without needing new hardware. From a quick view of the Lenovo site it seems that an ideal new Thinkpad that would last me 6 years would cost about $4500 while one that would last me 2 years would cost $1600 (and have a significantly lower screen resolution). A Thinkpad that would last 6 years and not be so great (but still better than the cheap option) would cost about $3500. Update: One significant issue is the life expectancy of laptop batteries. If you use a laptop for mobile use (as opposed to just moving between desks occasionally) then you are probably familiar with the problem of laptop batteries that discharge after 10 minutes. Last time I checked the warranty on Thinkpad batteries was 1 year or 300 charges (whichever comes first). My experience is that after 300 full cycles a Thinkpad battery will only last for a small fraction of the original charge time. When buying a laptop I suggest getting a spare battery at the time of purchase. The spare battery may last longer than the battery that is shipped with the laptop and two batteries means that you have twice the number of charge cycles before they are both useless. Batteries apparently don’t last long if completely discharged, so charge them up before storing them and periodically charge them if they have been left unused for any length of time (maybe every second or third month). With a Thinkpad it seems quite safe to change the battery while the machine is plugged in to mains power and running (I expect that Lenovo doesn’t recommend this though). You should probably plan to have a battery die every three years of use (or sooner if you do a lot of travelling). So one spare battery may last you 6 years of use but you will need two spare batteries if you travel a lot.

• [1] http://ozlabs.org/~rusty/index.cgi/2007/10/07#2007-10-07


• [2] http://etbe.coker.com.au/2007/01/04/monitors-for-developers/

Share This

This is a pretty good take on Tim Bray vs Erlang. However, I'd like to focus on something said at the end:

The fact is, all languages optimize for particular problem domains and I don't think that a universal programming language exists that would perform well on all tasks. Bray rapidly found out that Erlang isn't optimized for doing line-oriented I/O and it's regex library sucks. So what? While those problems could be eliminated from Erlang, the fact that Ericsson has deployed large telecom gear without having to fix those issues means that Erlang is ideally suited to its original programming domain.

The problem is that learning new languages is difficult for many people. They're not going to bother starting from 0 with a new language if what they've got is only 10/20% worse than the other guys. For companies, developing expertise (and trying to maintain it) in lots of languages is probably less productive than picking a few (Google only has four: Java, Python, Javascript and C++, and they're not exactly lacking in brainpower or cash). This is why "the right tool for the right job" works for things like saws and hammers, but not for complicated, idiomatic things like programming languages. Therefore, it's important that languages that aim to be widely used do lots of things pretty well, and try to avoid doing anything really badly. This is something I've always admired about Python, even if I don't use it anymore. It's a language that you can do a very wide variety of tasks with, and you can be sure there's probably some code out there already, and that Python will be ok for your task, even if it's not the best thing. Performance is a weak point compared to compiled languages, but even there, get the libraries right and things aren't *so* bad. In any case, my point isn't to bash Erlang (which I like), or put Python on a pillar (I prefer Ruby and Tcl), but to say that a widely used programming language doesn't need to be the best at everything, but it should aim to make people comfortable using it, safe in the knowledge that they can probably do most things *ok* if needs be. That's a far better situation than being able to do one thing realy well, and perform poorly at many other tasks, forcing its users to look elsewhere for solutions to those tasks. Personally, I think that for concurrency, Erlang is in a bit of a race right now - they're pretty far ahead in terms of concurrency (and also fault tolerance, but fewer people care about that), but behind in other areas (less library code). Other languages don't have as good a tools for concurrency, which isn't an easy problem. So, what will happen first - Erlang catches up elsewhere, other languages get "good enough" concurrency solutions, or a new language (like Scala) comes along and takes the lead?

Bruce Schneier has just written about the Storm Worm [1] which has apparently been quietly 0wning some Windows machines for most of this year (see the Wikipedia page for more information [2]). I have just been asked whether SE Linux would stop such a worm from the Linux environment. SE Linux does prevent many possible methods of getting local root. If a user who does not have the root password (or is not going to enter it from a user session) has their account taken over by a hostile party then the attacker is not going to get local root (unless there is a kernel vulnerability). Without local root access the activities of the attacker can be seen by a user logged in on another account - processes will be seen by all user sessions if using the SE Linux targeted policy and files and processes can be seen by the sys-admin. If while a user account is 0wned the user runs “su -” (or an equivalent command) then in theory at least the attacker can sniff this and gain local root access (whether enough users do this to make attackers feel that it’s worth their effort to write the code in question is something I couldn’t even guess about). If the user is clueless then the attacker could immediately display a dialog with some message that sound urgent and demand the root password - some users would give it. If the user is even moderately smart the attacker could fake the GUI dialogues for installing updated packages (which have been in Red Hat distributions for ages and have appeared in Debian more recently) and tell the user that they need to enter the root password to install an important security update (oh the irony). In conclusion I think that if a user is ill-educated enough to want to run a program that was sent to them in email by a random person then I expect that the program would have a good chance of coercing them into giving it local root access if the user in question had the capability of doing so. Even if a Linux trojan did not have local root access then it could still do a lot of damage. Any server operations that don’t require ports 1024 (which means most things other than running a web, DNS, or mail server) can still be performed and client access will always work (including sending email). The trojan would have access to all of the user's data (which for a corporate desktop machine usually means a huge network share of secret documents). If a trojan only attempts to perform actions that SE Linux permits (running programs from the user's home directory, accessing servers for DNS, HTTP, IRC, SMTP, and other protocols - a reasonable set of options for a trojan) then the default configuration of SE Linux (targeted policy) won't stop it or even log anything. This is not a problem with SE Linux, just a direct result of the fact that in every situation a trojan can perform all operations that the user can perform - and if the trojan only wants to receive commands via web and IRC servers and send spam via the user's regular mail server then it will be a small sub-set of the permitted operations for the user! If however the trojan tries more aggressive methods then SE Linux will log some AVC messages about access being denied. If the sys-admin has good procedures for analysing log files they will notice such things, understand what they mean, and be able to contain the damage. Also there have been at least two cases where SE Linux prevented local root exploits. Finally, in answer to the original question: SE Linux will stop some of the more aggressive methods that trojans might use. But there are still plenty of things that a trojan could do to cause harm which won't be stopped or audited by SE Linux policy. When Linux gets more market share among users with a small amount of skill and no competent person to do sys-admin work for them we will see some Linux trojans and more Linux worms. It will be interesting to see what methods the trojan authors decide to use.

• [1] http://www.schneier.com/blog/archives/2007/10/the_storm_worm.html


• [2] http://en.wikipedia.org/wiki/Storm_Worm

Share This

So the new NAS is happily running Debian now, and I'll write a long blog for anyone who wants to do the same once I have one remaining problem sorted out... Avahi doesn't work. If I start Avahi on the NAS other machines see the announcement and the names it provides will resolve, but after a few minutes they fail to resolve as they timeout. Unless my router is incredibly brain-dead it can't be the cause, because the old NAS is connected in exactly the same way and it works fine. For extra fun, the NAS can't see the rest of the mDNS network. It's almost like the network driver is dropping incoming multicast packets. Before anyone asks, there is no firewall running on the NAS. Does anyone have any ideas? NP: Remembranza, Murcof

Hmm. Quick update of life: Last weekend Leif pushed out a third tooth. This weekend, I fed him for the first time. So far it's been Angie actually putting things in his mouth, but on a visit to Cha Ya, I fed him some miso soup. Totally fun. Our current experiment with him is to get him to sleep at night without nursing to sleep. It used to be that I could get him to sleep just by lying next to him in a dark room, and lately I haven't been able to. So, he's now nursing just before and then switching to cuddling to sleep. It's not ideal but it at least moves us from something only Angie can do to something both of us or a babysitter can do.

That's right, we're starting to think about babysitters. We don't know people here well enough that we can leave him with, but when we do, baby, there's a bottle of port with our name on it. (Yes, it's the same bottle of port I got for my 30th birthday. I didn't want to pass a sip for each of the 100 people that were there at the time, and the next major event that came along was Angie getting pregnant)

A quick geek moment: current Ubuntu Gutsy now suspends and resumes on both of my laptops with reasonable consistency. For a long time, I could suspend my Toshiba once, and the second time, it would lose keyboard but that seems to be fixed. My work laptop has suspended and resumed generally fine all along, but Network Manager still occasionally forgets the settings. This is really annoying when there's a pile of 802.1x stuff to key in. I can't reliably reproduce it, but maybe during the next Gnome cycle, I'll try to figure out why it does that. Other than that it's working really well. The wine that's in Gutsy claims to support iTunes, but it doesn't. Even if it did, it probably wouldn't work with the iPhone, but I'm sure that'll get fixed sometime. Or perhaps the lawsuit will yield something useful and make hacking it safe. Given that it's pretty trivial to get the browser into a state where it's worth power cycling the phone, I'm not willing to forgo updates in the meantime. Assuming I could do one, that is.

Lastly a happy Thanksgiving to everyone! We were attempting to meet a pile of people this weekend, but amazingly enough 4 different people ran into trouble getting here. It'll be a cozy event then.

When running SE Linux you will notice that most applications are not permitted to run with an executable stack. One example of this is libsmpeg0 which is used by the game Freeciv [1]. When you attempt to run the Freeciv client program on a Debian/Etch system with a default SE Linux configuration (as described in my post on how to install SE Linux on Debian in 5 minutes [2]) then you will find that it doesn’t work. When this happens the following will be logged to the kernel log and is available through dmesg and usually in /var/log/kern.log (Debian/Etch doesn’t have auditd included, the same problem on a Fedora, RHEL, or CentOS system in a typical configuration would be logged to /var/log/audit/audit.log):
audit(1191741164.671:974): avc: denied execstack for pid=30823 comm=”civclient” scontext=rjc:system_r:unconfined_t:s0 tcontext=rjc:system_r:unconfined_t:s0 tclass=process The relevant parts are in bold. The problem with this message in the message log is that you don’t know which shared object caused the problem. As civclient is normally run from the GUI you are given no other information. So the thing to do is to run it at the command-line (the avc message tells you that civclient is the name of the failing command) and you get the following result:
$ civclient
civclient: error while loading shared libraries: libsmpeg-0.4.so.0: cannot enable executable stack as shared object requires: Permission denied This makes it clear which shared object is at fault. The next thing to do is to test the object by using execstack to set it to not need an executable stack. The command execstack -q /usr/lib/libsmpeg-0.4.so.0.1.4 will give an “X” as the first character of the output to indicate that the shared object requests an executable stack. The command execstack -c /usr/lib/libsmpeg-0.4.so.0.1.4 will change the shared object to not request an executable stack. After making such a change to a shared object the next thing to do is to test the application and see if it works correctly. In every case that I’ve seen the shared object has not needed such access and the application has worked correctly. As an aside, there is a bug in execstack in that it will break sym-links. Make sure that the second parameter it is given is the shared object not the sym-link to it which was created by ldconfig. See Debian bug 445594 [3] and CentOS bug 2377 [4]. The correct thing to do is to fix the bug in the source (not just modify the resulting binary). On page 8 of Ulrich Drepper’s document about non-SE Linux security [5] there is a description of both the possible solutions to this problem. One is to add a line containing “.section .note.GNU-stack,"",@progbits” to the start of the assembler file in question (which is what I suggested in Debian bug report 445595 [6]). The other is to add the parameters “-Wa,--execstack” to the command-line for the GNU assembler - of course this doesn’t work if you use a different assembler. In the near future I will establish an apt repository for Debian/Etch i386 packages related to SE Linux. One of the packages will be a libsmpeg0 package compiled to not need an executable stack. But it would be good if bug fixes such as this one could be included in future updates to Etch.

• [1] http://en.wikipedia.org/wiki/Freeciv


• [2] http://etbe.coker.com.au/2006/12/08/se-linux-on-debian-in-5-minutes/


• [3] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=445594


• [4] http://bugs.centos.org/view.php?id=2377


• [5] http://people.redhat.com/drepper/nonselsec.pdf


• [6] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=445595

Share This

...and I like that one, as one may expect. With only 30% ball possession, France won against New Zealand. They transformed the very few occasions to score tries and finally, thanks to a magic inspiration by Fred Michalak, relayed by Yannick Jauzion, their last try made them win 20-18. The french defense was....close to heroic (179 tackles, whiles NZ tackled 36 times!), particularly at the end of the match, where the NZ bulldozer was trying to score one very last try. Not everything was perfect in this match (particularly a disaster in line-outs: I have never been fond of Rafael Ibanez, but it seems to be time for him to retire...), and only the courage made them win. I really wish I could have been in Cardiff to celebrate this. Champagne... So, rendez-vous to our English friends next week-end, in Stade de France. Given their match today, that will be though, again. Tomorrow, South-Africa-Fiji (yet another suprise?) and Argentina-Scotland. Eh, why not France-Argentina as final?

At Debconf, we (the i18n crowd) discussed about the NMU campaign we ran before the release of Etch (roughly from September 2006 to March 2007). We concluded that running a campaign slightly earlier in the release process would be likely to save us some work. Indeed, experience shows that the initial pings sent to maintainers often trigger uploads to fix the pending l10n issues. So, let's start thinking about it now. For those who don't remember, the rough process is described here. As one sees, it is deeply respectful for maintainers and takes great care to avoid unwanted NMUs. So, to begin, please check the list of the pending po-debconf l10n issues ranked by...a pretty complicated mathematical formula which aims to put packages which would most benefit from an upload in first position... In case one of your packages is listed near the top of that list, just consider uploading it soon. PS: of course, the mathematical formula includes a secret pondering scheme aimed at giving French translations more weight, as anyone would have guessed.

There is ongoing debate about the issue of security cameras, how many should there be, where should they be located, and who should be able to access the data. I spent about a year living in London which probably has more security cameras and a greater ratio of cameras to people than any other city. I was never bothered by this. I believe that if implemented correctly security cameras increase public safety and will not have any serious problems. A while ago I witnessed a violent assault (which could potentially have ended up as a manslaughter case - it was merely luck that ~200 people got off a train at the right time to scare the attackers off). AFAIK I was the only person who identified themself to the police and was prepared to stand as a witness, without security camera footage the case would not have gone anywhere (I only saw the attackers from behind as they ran off). Security camera footage allowed the police to identify the attackers, my testimony was not required and I was never informed as to how the case proceeded - but I know for a fact that the police investigation depended on security camera footage and that they did make progress in the case based on such footage. There are current plans to increase the scope of security cameras in many cities under the guise of the “war on terror”. The problem is that once a terrorist is involved in an attack it’s too late for security cameras. Security cameras are really only good for catching criminals after an attack, in most cases they will be entirely ineffective against suicide bombers as the issue of catching them is moot. There have been cases where security cameras have enabled the authorities to identify people with terrorist ideas who were investigating military bases (but I wouldn’t call such lamers “terrorists” as all the available evidence suggests that they would be incapable of succeeding in an attack). However no-one is disputing the fact that military installations need to have good security. Given that security cameras do provide significant benefits to public safety I don’t think it’s reasonable to oppose them as long as they are implemented in a sensible and responsible manner. Most of the current plans to install security cameras don’t seem to be sensible and have few controls on who can access the data. This makes them good targets for oppressive government actions, organised crime, and even terrorists. The countries that have serious terrorist problems always have problems of terrorists infiltrating government departments and bribing government officials. A centralised system that allows the police to watch anyone at any time would probably do more good for al Quaeda and the Mafia than it would for regular police action. For the fastest possible response a security camera system needs to have humans able to monitor it’s output in real-time. Having a control-room where police officers can randomly switch between public cameras to see if a crime appears to be in progress is a good thing (and works well in the UK). Of course the actions of such police need to be monitored to make sure that they are actually doing their job (not checking out hotties on the camera - an ongoing problem with security cameras). Finally there’s the issue of what level of surveillance can be expected in a public place. I think that most people agree that when you enter a government building it’s reasonable to expect that you will be on camera, and many private buildings have security cameras with a condition of entry being that you permit yourself to be watched and no-one seems to be boycotting shopping centres because of this. Significant public spaces such as main roads and public transport also seem like reasonable locations for security cameras. One location that is widely disputed is that of streets in residential areas. Most people who are happy to be photographed when entering and leaving public buildings such as train stations and shopping centres are not happy to be photographed when entering and leaving their own home. I think that a reasonable solution to these problems requires the following:

1. Restrictions on the duration and scope of surveillance in residential areas (EG require police to get court orders for such surveillance that must be periodically renewed).


2. Restricting the duration for which records may be kept by the police. Keeping any records for longer than the period in question (which would be a few weeks at most) would require a court order.


3. Prohibiting private organisations from handling surveillance data from government property (including public roads, train stations, etc). There are problems with having a private company aggregate surveillance data from multiple private properties but I don’t think we can address this at the moment.

Share This

I’ve recently spent some time on Facebook, primarily out of professional interest (all the cool attorneys are doing it). (I’m also on LinkedIn, but that seems less cool.) Among other odd results, I’ve been getting lots of friend requests from people I’ve had no contact with in ten — and sometimes twenty or more — years. I’m surprised by this because I’ve always been so easy to find. I started my first “home page” in 1994, and as long as the idea of search engine rankings has existed, I’ve been at the top in searches for my name. I’ve also never made any attempt to hide my email address, and retained all addresses for nearly 15 years. Yet, people contact me on Facebook who never before did. I have two nonexclusive theories:

• Facebook just induces more searching for old friends than “the web at large.”
• Facebook allows you to reconnect with people for a minimum activation energy. You don’t have to write them an email, tell them about your life, or engage in conversation. You just click “add to friends” and you’re done. Maybe these people had found me in the past but just didn’t bother to let me know. In fact, in the case of some of these people with whom I haven’t communicated since middle school, I still haven’t communicated with them. We’re just Facebook friends.

Other ideas? I should add that I have made some genuine connections through Facebook as well. Earlier this week, I met a college friend (whose website promises to return to service soon) for dinner whom I hadn’t seen in nearly ten years. I found out he was in town through Facebook.

Share This

In a lot of talks or blog posts (like Sam’s talk at RMLL, or Rapha l’s blog posts - both in french), people have been talking about what people could do inside Debian, and how it would help Debian. That doesn’t sound like the best approach to me. When describing tasks with the objective of getting potential contributors to pick them up, we should try to make them sexy, to tell users what is exciting about them, what they will learn doing those tasks, where satisfaction will come from. We really need to sell them better. Of course, some Debian tasks are mainly grunt work. And for some of them, people just do them because someone has to do them. But I believe that most tasks inside Debian are actually more interesting than outsiders would expect. For example, I would be very interested in reading why an i18n expert (hint: Christian!) finds i18n sexy … and I should probably try to write about QA myself. (As you might have noticed now, the subject of this blog post was misleading on purpose — chosen so that a lot of people would read the post :P)

MJ, each French NPO is free to establish its own regulation rules, which may include a differential voting system if they want to. That should of course respect the French law (for instance, no discrimination based on sex, religion or any other genetic factor) but, as far as I know, nothing prevents deciding that "personnes morales" (ie non physical people) have a higher or lower vote than others. However, this is certainly not common, but many NPO simply don't have non physical members anyway (some don't authorize non physical people to be members). For those who care, Debian France (which is a NPO, but not regulated by 1901 law, but by the special NPO law for Alsace and Lorraine, inherited from the 1810-1918 years) admits physical and "moral" members with an equal voting right. The only special case is a rule that allows Debian developers to have a veto right on any decision of the organisation. See that official regulation rules of Debian France for details (French only). PS: Debian France is currently inactive, due to a longstanding dispute with the French Tax collecting organisation (Direction des Imp ts) who initially refused to consider us as a non profit organisation...because "we sell an operating system" (doh!).

Updated: Soci t G n rale (FR) with gnucash QIF importer

Although I predicted that I'd be a busy boy with my bushfire brigade on Tuesday, I wasn't expecting to get our first "Bush Alight" fire call so quickly. But, yesterday (Wednesday), a few minutes after 1800, off goes the pager, and off I go to the station. Thankfully the high winds that had been a major feature of the day had settled down quite a bit, so it was relatively easy to control and stamp out (we were back at the station by around 2015) I still found it a little overwhelming -- "I'm supposed to help Stop This Fire". At a couple of hectares in size, it wasn't too massive, and it wasn't visually "spectacular" (like the fires you always see on the news) but still... given that my only experience of fire in the past has been small campfires and the occasional bonfire, having an area the size of a football field in front of you glowing with embers and flaring with small clusters of flames, it was certainly a very different experience. The heat, the smoke, the noise (those truck pumps are loud), and the adrenalin, it's a hell of a mix. Being that I'm the newest and least experienced crew there, I got given the unglamourous but important job of controlling traffic, as we had one lane of the one-each-way 100km/h road closed to give our crews more working space around the trucks. Let me just say that I now have an infinitely greater respect for road repair crews, and I think that every person should do an evening of traffic control with a group of their mates on the road behind them, so that they know what it feels like outside their car. Car drivers do the darnedest things. So, I've popped my bushfire-fighting cherry now, and I'd be more than happy if there's nothing more impressive than that awaiting me for the rest of the season.