This is mainly a comment on the BBC report of the Get Safe Online campaign - the campaign seems to have some good advice, such as securing wireless networks (WPA at least now!), and their website is more useful than other gov.uk ones I've seen, but some comments in the report just seem strange, like "a date of birth and address details were enough for someone to set up a credit card in another name" - if that false credit card would affect us, then we need to fix the credit card issuers, not stop posting details online! Trying to hide details is well-known as security by obscurity and it's not much security at all. I'm disappointed if that's a major focus of Get Safe Online's message. What about trust and encryption advice? Also, many people don't have a choice whether our details are posted online. They are already posted by government agencies like Companies House and then that information is bought and republished by private companies. So, we're not adding much to the risk by using social networking. Finally, it's rather amazing that some Secured Web Browsers can't access much of the content on www.getsafeonline.org because of their careless use of Flash and client-side scripting on their site. Are they safe themselves? Get Safe Online will be travelling around the country offering advice on how to stay safe and secure when using the internet. They're in Bristol tomorrow - if I don't feel nearly as bad as this any more, maybe I'll go visit them and see if the reports are accurate.

I've just gotten a 256slice from Slicehost and I will deleting my UML instance with Bytemark. I was a customer of Bytemark's for a number of years, and I was happy with them. I had the smallest VM they offered and was just using it to run my DNS, postfix (and clamav and amavis) and a couple of tiny websites. The 75M of RAM the VM has just isn't up to these tasks anymore, with fairly frequent OOMing. Although they upgrading their smallest VMs to 150M six months ago, I still hadn't been upgraded to that new size, which is one of the main reasons I looked for other options.

So Slicehost seems to have a good reputation and having gotten my slice last week I can say that's it's wayyy faster than my setup with Bytemark. Even if I had stayed with Bytemark I would have 100M less RAM and it would have been more expensive (darn you weak American dollar). I really liked Bytemark, they've been supporting DebConf for at least a couple of years. I wish them success, but at this point they're offerings just competitive anymore.

The one thing I really miss from Bytemark is their DNS slave service. You could run your own BIND and have Bytemark's nameservers be slaves to it. Slicehost only has a hosted DNS service. But this is a small quibble compared to all the upsides.

Last week ended in a rather annoying way. Apparently my car had developed a flat tire overnight one night, and I left while it was still dark the next morning, and didn't notice it. I had driven on it all the way to work with it fairly flat, which damaged the tire (but not the wheel). So that needed to be replaced, and it was still under warranty from the place I bought them, which is 45 minutes away. We had a family gathering on Saturday, but couldn't be there all that long because we had to get to this place before it closed.

After we got home, there was a bit of work to do out in the yard. Jacob was tired of being indoors, so I took him out with me. He came with me as I put air in our 5-gallon air tank, and watched as I used the tank to do the monthly tire inflation on our pickup. (When you paid $75 for the vehicle, fixing a tire that only has to be inflated once a month doesn't seem all that cost-effective)

And then he got his first ride in the pickup. We were just moving around trash on the yard, and he enjoyed it. We hopped in and out several times to load or unload things. Though he was very annoyed that I didn't let him use the stick shift while I was driving. My parents said that he sounds like his dad.

We have a bedtime routine for Jacob, and I read a book to him right before putting him to bed every night. This morning, Terah got out the book that I read to Jacob last night. I was in a different room, but Terah is quite sure she heard him say "dada read this!" That's his first sentence (that one of us heard, anyway)

Some of you may have read that my relative Venita had a brain aneurism recently, and remarkably, seems to be recovering from it. Today in church, our pastor said, "I'm happy to report that this morning, Venita called me, asked me to thank everyone for all the prayers, and to ask the choir to sing up to heaven -- and they have." She's still very weak, and just sitting up to eat is a struggle, but she is improving.

Terah and I had invited my two aunts that grew up in what is now our house over to help decorate for Christmas. They were here today, and we spent all afternoon decorating, and we had spent the last couple of days finding decorations. It was a fun time, and the house looks great and feels more like home. We're happy to have had the help thinking about where to put everything, and actually putting things there. The tree isn't up yet, but it will be soon. We're thinking that it will be nice to be decorated early this year, rather than our usual just-before-Christmas decoration event!

It was neat to hear a few stories about how my grandma decorated the place; she died when I was young, and I don't remember her. Jacob, of course, was in on all the action. He watched, played, and threatened to make the nativity scene quite unpeaceful, but more interesting to a 13-month-old.

The Goerzen Christmas will be here this year. The last time Goerzens celebrated Christmas in this house was 7 years ago -- a month or so before I met Terah, as it happens. It seems so long ago in some ways. The house has changed; the 1970s yellow wallpaper is gone, as is the drop-ceiling tile that grandpa had installed to save on the heating bills, as is his wood stove and the metal tractors that he had in his closet that I used to play with when I was little.

But as I sit here typing this post, I'm looking at the spot where I used to play air hockey on grandpa's table during family gatherings -- and whenever else I could convince grandpa to get out his air hockey table for a game. Over in the corner is where he always had his Christmas tree, with the woven wheat ornaments my grandma had made. Terah decided that corner would be perfect for the tree, before she ever knew where it used to be.

Here's a picture I took at that Christmas 7 years ago:



Sitting here right now, looking at all that has changed, and all that hasn't... 7 years wasn't that long ago after all. I'm sure this year will be the first of many happy Christmases to be celebrated in this place.

I’m currently evaluating Olivier Sessinks jailkit to maintain a small cvsd CHROOT with an included SSH server. The cvsd-buildroot command e.g. doesn’t handle the libpam-modules dependency in the CHROOT. So I tried to update the Debian packaging files included in the jailkit source. During this work I found some issues with the build environment - e.g. no DESTDIR support and some other stuff (another user already complained, that there might be problems with the SUID installation part for jk_chrootsh, jk_uchroot and jk_procmailwrapper of the Makefiles). So I began to check and “fix” the Makefiles and the configure script and then sent everything to Olivier. I did not only add the DESTDIR variables. I also made use of built-in rules, common variables (also for implicit rules), … and such stuff to make the Makefiles shorter and easier to maintain. My fault: I tested everything with GNU make. Now Olivier complained, that BSDs make doesn’t work anymore. So we began a short hack session to check for the problems. My first issue: I had to find some BSD make to test it myself. I found it in the freebsd5-buildutils, that contains the freebsd-make command. Then we began to check for incompatibilities and that’s the result:

1. ifdef statements differ in syntax
   • GNU make uses ifdef VAR
   • BSD make uses .ifdef VAR
   solution: We replaced the statement with a construct similar to AM_CONDITIONAL. But we do not use this macro, because it would need to be shipped in aclocal.m4, which is currently not necessary. The code simply sets a variable foo_TRUE to ‘# ‘, if the condition is wrong, or the variable is left empty, if the condition is true:

   if test "x$my_condition" != "xno" ; then
       AC_SUBST([foo_TRUE], [])
   else
       AC_SUBST([foo_TRUE], [# ])
   fi

   FILES = bar
   @foo_TRUE@FILES += foo

2. prerequisite variables differ in syntax
   • GNU make uses $<, $^, $@, …
   • BSD make uses $ .IMPSRC , $ .ALLSRC , $ .TARGET , … (note, that both *SRC variables hold a list of source files)
   Unfortunately both make implementations doesn’t seem to share a variable for the list of prerequisites. So the only solution is to list all prerequisites in the rule again. A variable would be much more comfortable. Maybe one could write a function, that first tests $ .IMPSRC and falls back to $^. Maybe that’s an alternative, but it’s IMHO not a very good solution. We’ve chosen to write down all prerequisites in a rule instead of using a variable. This is a little bit “harder” to maintain, but it works.
3. built-in rules are not shared and do not use the same variables
   • GNU make ships built-in rules to build objects from sources and link them; rules consider CPPFLAGS
   • BSD make ships built-in rules to build objects from sources, but there are no rules to link them; rules do not consider CPPFLAGS
   In the case of GNU make, one can simply write:

   myprog: foo.o bar.o

   and GNU make will automatically create foo.o from foo.c (.c.o:, ditto for bar.o) and at least link myprog (.o:). But BSD make will only create the object files. There is no final link-step. So we had to include the rule to link the program in the Makefile.

Finally we got it and it looks good now. I/We learned a lot of new things (I learnd a lot about BSD make) ;), but it took us 1-2 hours to understand and fix the problems. Here a list of URLs, that might give some more information about the programs, their syntax and limitations:

• GNU make’ manual
• FreeBSDs make
• Autoconf: Limitations of make

I'll be in New York State for the second half of this coming week. On Thursday, I'll be in New York City giving a talk as part of a interdisciplinary colloquium discussing free software and structured around Decoding Liberation, the recent book by Brooklyn College professors Samir Chopra and Scott Dexter. The talk will be Thursday, November 15, 2007 between 10:50 and 13:30 in the Glenwood Lounge in the Brooklyn College student center. See this flier for details. I'll be heading straight to Ithaca where I'll give a talk the next day at Cornell for the Code Review student group. My talk will try to introduce and discuss free software issues in the context of the OLPC project. The talk will be on Friday November 16th at 17:00 in Rockefeller 115. There's some more details on the Code Review website. Folks should feel free to attend either event. I'll be leaving soon after on a bit of a Balkan tour being organized by some of my friends from mi2 and will be spending a couple weeks in or based out of Zagreb. The details are still being ironed out but I'll be sure to post them here once I know dates, places, and times.

David H rdeman has contributed two really valuable guides to my Debian on NSLU2 site that will be of great interest to many NSLU2 users:

• The first guide is for people running Linux on a flash device, such as a USB flash stick. Since flash only supports a limited number of writes, it is important to reduce the wear and tear on the underlying flash device. David's guide gives some practical advice of how to achieve this.
• The second guide gives a few tips and tricks that can be used to reduce the amount of RAM a system uses. This is particularly interesting to NSLU2 users since 32 MB of RAM is not a lot.

These guides mention Debian but most of the advice applies to other NSLU2 firmware flavours and to Linux in general.

I have had some fun during these 2 rainy days thanks to VirtualBox. I have first tried the latest Fedora 8 (upgrading from the previous release). Though the upgrade was painless, I was stucked with the Linux Guest Additions which weren’t working, due to SELinux being enforced (by default or by mistake, I am not sure). I had even opened a bug for this issue… Then I have tried OpenSuse, which also needs tweaking so that the additions run ok - the solution was on the VirtualBox forums (disabling concurrency for init scripts by changing RUN_PARALLEL=”yes” to “no” in /etc/sysconfig/boot file). Well, I haven’t extensively tested these distributions, but I particularly like the new Nodoka theme used by default in Fedora. I have even begun to work on Debian packages for both the GTK+ and the Metacity themes (I know there is already someone working on this, I will e-mail him to propose a co-maintenance if he accepts). On the other hand, I was very surprised that OpenSuse uses GNOME as default WM (maybe it isn’t new, but I haven’t seen a Suse desktop for years). Their gnome-main-menu is really nice, but really unusable for me! I guess I will try more distros in the coming weeks to compare with Debian - for now, I get the feeling I have made the good choice, except maybe for the default artwork, which is hopefully improving…

My friend Martin has started a blog on usability, Yes, No, Cancel? (or in German, Ja, Nein, Abbrechen). He appears to have stalled after a good start so perhaps this mention will get him going again. He offers usability consulting through his company, Ept Computing.
Martin, an early victim of the new camera

Once ftp-master is back, several important X updates should arrive. The first one is a Xserver pre-1.4.1 snapshot (the official 1.4.1 is expected soon). It will bring many input fixes, for instance for broken LEDs (reported 12 times). Unfortunately, there are still some input bugs in there, for instance upstream bug #13114 which is kind of annoying (I can't play xmoto anymore). A new release of the Intel driver is coming soon. The first release candidate, 2.1.99, has been uploaded to experimental. The most noticable changes include some fix for VT switch and the support for some rare LVDS chipsets (ch701x). Also EXA is now enabled by default, which is good news since XAA had some bugs that won't ever be fixed (for instance when using XV in Compiz, see upstream bug #10912). Before 2.2 is released, we might get a fix for backlight support which got fixed on some boards while broken again on some others in the past (see upstream bug #11527). The new Mesa 7.0.2 release might be worth taking a look too since it brings many fixes, including a working __gluInvertMatrix() which should solve many GLU-related problems that have been reported, and some fixes for several Blender crashes. Not much activity on the xserver-xorg-video-ati side recently. But given how well it works these days, I am seriously thinking of uploading the next snapshot to unstable (1:6.6.193-3 didn't help a lot there).

Best wishes to everyone in the Free Software community for the new year Vikari (VS 2064) Diwali/new year this time was kind of anticlimatic compared to last year when we were actually in India. It is cold and gloomy in NJ, and fireworks are hard to come by. (Though I did manage to scrounge up some so not a total loss in that department.) And we arrived late at the mandir for Annakut Darshan today so they were out of thor which sucks. The presents front has been the usual maddeningly practical things. The kids of course got better stuff. Shailu, for instance, got Hungry Hungry Hippos and we've been having fun playing that. So I shouldn't complain. Ma Lakshmi has blessed me tremendously over the past year and I just know this year will be even better.

The next upload of the MySQL packages to Debian (both branches, 5.0 in unstable and 5.1 in experimental) will disable binary logging in the default configuration file. I think most users of the MySQL packages in Debian don't really need it, and otherwise (e.g. on a replication master, or for point-in-time recovery) they know how to enable it.

This change only affects you when you're doing a fresh installation of the mysql-server package, or if you're still running the default configuration file shipped with the package. If you modified the configuration file in the past already (which should be the case when using replication, because the server_id line is disabled by default), the change will not be applied during an upgrade without explicit confirmation.

I recently wrote some suggestions about appropriate swap space sizes [1], the main point being that the advice to use 2* RAM size never really applied to Linux and a system that actually has swap space equivalent to 2* RAM in use will usually be too slow to use (and you are better off having the kernel OOM handler kill some processes). There were a number of responses to that post, Ingo suggested that significantly larger amounts of swap can be used for compiling [2]. I have had similar experiences when compiling KDE long ago on a machine with 96M of RAM. Even in 1999 96M was not a lot of memory for a machine running KDE, and when compiling MICO (the CORBA system) a single G++ process could use more than 96M of memory. Obviously a lot of swap was used, but performance didn’t seem too bad. I avoided touching the keyboard or mouse (so most of the X server was paged out) and allowed all memory to be used by the build process. It seems to me that the build process is not as intensive as other processes in terms of swap use because it is a chain of processes that call each other. You may have several instances of make running (launching a new instance for each directory as you descend the build tree is common) and then a gcc process that launches some child processes. But unless you use the -j option to make at most times during the build there is only one process with any serious work to do. So the parent processes can be entirely paged out to make room for the process that is doing the work. A counter example is a shell server that has many interactive users, on such a machine if it runs slow then the users start opening more sessions so that they can perform other operations while waiting for a slow command to complete, opening more sessions uses more memory and makes the problem worse. Ingo notes that he uses several hard drives to give good performance. The priority of swap spaces is listed in /proc/swaps and can be set by pri=N in the options field in /etc/fstab. If you have multiple hard disks then the performance of swapping on a system that is being used intensively for multi-tasking will increase significantly at a rate that would hopefully be close to linear scaling with the number of disks. If a system only has one active process that is being paged (which might be reasonably common as part of a build process) then the performance benefits for reading will be significantly reduced.

• [1] http://etbe.coker.com.au/2007/09/28/swap-space/


• [2] http://blog.windfluechter.net/index.php?/archives/71-Swap-sizes.html

Share This

N810 maemo submission accepted

Congratulations! You have been accepted to the N810 maemo device
program. We will send your discount and instructions as soon as the
device is available in your selected shop (soon).

As the title says i have to thanks maemo and nokia for giving me this chance. I can't wait to put my hands on my new toy!

SLO2 (FTA 13e) is advertising a sports documentary called RAAM 2007 today (Saturday 10 November) at 1630 CET - that might be the Race Across AMerica and there’s no telling what language it will be in! RAI Sport Sat (FTA 13e)
has coverage of the 4 Days of Milan stage from Montichiari to Castellana on Sunday 11 November at 1700 CET. I can’t find this race on the UCI calendar - does anyone know it?

Only an outline so far but most of this code already exists in Emdebian SVN.

1. C/C++ application: langupdate using libapt-pkg and libglib2.0-0
   
   • Reads supported locales and silently installs only the supported translations for all installed packages, with fallback support where configured.
   
   
   • Silently removes all translations for all unsupported locales.
   
   
   • First run in langupdate postinst
   
   
   • Removes package translations on the next run after package removal.
   
   
   • Separate /etc/langupdate/tdeb.sources.list and /var/cache/langupdate/lists/ to keep apt cache size down. Manual changes will be overwritten so maybe it ought to live in /var/ or /usr/share/.
   
   
   • One source for each locale root, main_en, main_fr, main_pt etc. All sources maintained by langupdate directly, according to the list of supported locales.
   
   
   • Each source contains all translations for locales within scope: en_GB in en, pt_BR in pt etc. to support fallback correctly.


2. XS-Package-Type: tdeb with a file suffix of .deb (not .tdeb) to reduce the number of patches needed for a working implementation.


3. Server-side perl script: langmigrate that parses the .changes file:
   
   • Removes tdebs from existing repository.
   
   
   • Moves incoming tdebs into new layout.


4. No descriptions, no dependencies. All tdebs are Priority: extra and Architecture:all. Possible support for a tdeb1 version suffix for updates that are not yet in Debian. (Allows for translation updates without package uploads.)


5. Plan to remove (or support an alternative package) dependency on libglib2.0-0 but OK for Emdebian at the moment due to targetting of GPE.


6. langupdate itself Priority: optional and not part of the default emsandbox


7. langupdate is a native package, uploaded to and maintained in Emdebian. Migrate into Debian once infrastructure is ready.


8. langupdate has little or no output, only a help option and possibly support for --clean but everything else automated.

This is built on the emlocale method (from emdebian-tools) and emlocale will be modified to fit this plan in 0.5.4.
langupdate (and langmigrate) cannot be part of emdebian-tools themselves, so will be separate packages.
(and yes, it is 4am, I'm not sleeping well due to a viral infection.)

Ian Lance Tailor started a discussion that has in the meantime reached Planet Debian via Miry and Giacomo. The single-threaded memory model is the only sane choice for languages that are as close to the "metal" as C and C++ are. For a multi-threaded model to work, the compiler needs to have intrinsic knowledge of "locking", and it needs to emit the appropriate code around all accesses to variables that cannot be accessed atomically (which also means that signal handling does not work — the signal might arrive in a critical section). Java uses such a model. In the language, there is the "synchronized" keyword, which can be used either as a modifier on a method definition (locking the object the method is called on), or before a block (locking an explicitly specified object). The lock is recursive, so calling another "synchronized" method on the same object works fine, leaving the last one finally unlocks the object. Memory consistency is achieved by flushing the object before unlocking (so accessing an object that another thread may use without locking it is still undefined behaviour — but class authors can avoid that by allowing access only through "synchronized" methods). I doubt we want the same in C/C++. For one, it adds a recursive lock to each instance of a class or struct, whether needed or not, since the compiler cannot rule out that some code might want to use this object as a lock. Also, the object inclusion and inheritance rules are quite different, as Java does not have inclusion, and only allows simple inheritance. Basically, if I were to emulate Java's rules, I'd need a "virtual" base class to provide the lock, which is a lot of extra overhead since every derived class now needs to keep the offset to the most derived class. The other two big show stoppers are the "intrinsic" knowledge of locking that the compiler must have (it needs to know how to embed a recursive lock into an object, which is an operating-system dependent structure as it stores some thread identifier for the current holder of the lock) and that it becomes a lot more difficult to write signal handlers, as you need to avoid any code that might implicitly lock some object (which is true already, but there is no implicit locking). Java can do that, as they have a virtual machine that provides locking primitives and object lookup (so they can keep the lock separate). There is a change to the memory model I'd like to see though: the concept of an I/O buffer that behaves like regular memory (so load/store coalescing/reordering is allowed), but will be flushed before volatile accesses and re-read afterwards (optionally, with finer grained control). This would work for both hardware accesses (where the volatile access triggers some hardware) and for "hosted" environments (where the compiler assumes that system calls perform volatile accesses), and still allow most optimisations like writing in the hardware's natural bus width. If you want to write reliable multi-threaded code with current compilers, there are two simple rules:

1. any data structure shared by multiple threads needs to be marked volatile
2. any access to a shared data structure needs to be guarded by a lock

The accesses to the shared data structure are ordered with regard to the locking functions and cannot be optimized out, which is exactly what you want. The appropriate mental model is that anything that is not declared volatile (or handled by a platform locking primitive) cannot be seen by the other threads.

As I stand in a near cattle-car packed South Station, waiting while no trains arrive and no trains depart (”signal difficulties”), I wonder if forces are conspiring to make MBTA service so poor that it enters a death spiral of poor reputation for reliability, increasing fares, lower ridership, less revenue, etc.. One or two long delays or canceled trains in a short time span can be ignored, but after a while it may become impossible for the T to recover the lost goodwill. There’s a saying in trademark law, “once you’ve lost a customer, they’re often gone forever.” Are signal difficulties for real, by the way? More on this topic: this excellent op-ed in the Globe about the importance of mass transit to the local economy and life sciences in particular; contrast with this news about what the T plans as its next big project (hint: “T TV”). Not much good news here, either. Is anyone listening? Technorati Tags: MBTA, Boston, Mass Transit

Share This

As I stand in a near cattle-car packed South Station, waiting while no trains arrive and no trains depart (”signal difficulties”), I wonder if forces are conspiring to make MBTA service so poor that it enters a death spiral of poor reputation for reliability, increasing fares, lower ridership, less revenue, etc.. One or two long delays or canceled trains in a short time span can be ignored, but after a while it may become impossible for the T to recover the lost goodwill. There’s a saying in trademark law, “once you’ve lost a customer, they’re often gone forever.” Are signal difficulties for real, by the way? More on this topic: this excellent op-ed in the Globe about the importance of mass transit to the local economy and life sciences in particular; contrast with this news about what the T plans as its next big project (hint: “T TV”). Not much good news here, either. Is anyone listening? Technorati Tags: MBTA, Boston, Mass Transit

Share This

My parents, both physicians, have frequently talked about running a bed and breakfast when they retire. Perhaps on the off-season, they will be doctors without boarders.