Search Results: "beh"

10 April 2009

Joey Hess: Racing the Beam

I devoured Racing the Beam last night. It does a great job at getting inside the Atari 3600 platform and explaining how it affected the early games that ran on it. Full of great examples, like Yars Revenge displaying its own code onscreen as a visual effect, to avoid needing a random number generator. Teaches how to analyse screenshots of 3600 games and see how the crazily limited hardware was coaxed into drawing them. Highly recommended, just wish it were twice as long. (I also enjoyed that the book itself is a nice recursive hack. Its (fairly cheap) printing process didn't allow reproducing the detailed color photos of the games needed for reference. So they printed them on the inside of the dust jacket instead.)
While I just missed out on the heyday of the Atari 3600, I was writing similar games on my 130XE a bit later, mostly limited by having to use slow BASIC. This was probably the first video game I ever wrote, judging by its filename ("VIDIO").
You're the green dot, zipping across the screen. Each time it reaches the right side, it wraps back to the left, leaving a wall behind. Crash into the wall and you lose a life.
As I've mentioned before, I still enjoy VIDIO, both its simplicity and gameplay. And the key to its gameplay is that the dot moves fast and the controls are not very precise, making it hard to go thru a given hole in the wall. And the controls are not very precise because of a limitation of the platform. The BASIC program can only sample the joystick position occasionally, and so there's little fine control. So, Racing the Beam has helped me realize that the platform made this game what it is.
BTW, here's the code to VIDIO. (more)

Daniel Leidert: (WW) AllowEmtpyInput is on, devices using drivers kbd or mouse will be disabled.

Maybe you will observe a changed mouse and keyboard behaviour after updating X.org recently in Debian Sid. Then you will probably discover the warning mentioned in the title in your X.org server log /var/log/Xorg.0.log. The very short and dirty solution to get things working for the moment is to put this into your /etc/X11/xorg.conf: 
Section "ServerLayout"
    Option "AutoAddDevices" "off"
EndSection
See the first entry in /usr/share/doc/xserver-xorg/NEWS.Debian.gz and follow the mentioned links for more information. However, the above solution should only be a temporary workaround: Try to migrate things (I will post changes for my system asap).

9 April 2009

Mohammed Sameer: Bye fglrx...

Thanks to all the hard work by the fglrx packaging team, DRI, MESA, Xorg, Radeon,... etc people!

I've been using fglrx with my laptop since I've had it:

01:00.0 VGA compatible controller: ATI Technologies Inc Radeon Mobility X1400

And to the people behind the Debian packaging..
* xserver-xorg-video-radeon from testing.
* libdrm-intel1 and libdrm2 from unstable
* libgl1-mesa-dri and libgl1-mesa-glx from experimental

vader:~# apt-get --purge remove fglrx-driver fglrx-kernel-src fglrx-kernel-2.6.26-1-686 fglrx-sourceReading package lists... Done
Building dependency tree
Reading state information... Done

The following packages will be REMOVED:
fglrx-driver* (9-2-2)
fglrx-kernel-2.6.26-1-686* (9-2-2+2.6.26-13)
fglrx-kernel-src* (9-2-2)
fglrx-source* (9-2-2)
0 upgraded, 0 newly installed, 4 to remove and 17 not upgraded.
After this operation, 38.8MB disk space will be freed.
Do you want to continue [Y/n]?

I probably lost the ability to suspend and resume but I don't usually do it with that laptop.

Now let's hope my lapop at work will be adapted easily too :)

UPDATE: Seems you lose OpenGL 2.0 if you use the free driver. If you are doing OpenGL stuff like me then you are in trouble ;- read more

8 April 2009

Eddy Petrișor: About the protests in Moldavian Republic

Many people in the western world are completely unaware that in the Moldavian Republic there is an ongoing protest against the current Communist Party which is at power after the parliamentary elections held on Sunday. The protestants accuse the Communists of election fraud and there are numerous reports of dead people being recorded as voters, people which, by religion, chose not to vote, and other several people which couldn't have voted.

Tuesday the protests took a violent turn, apparently "aided" by some instigators which were reported to be seen as recording the protesters, taking notes and, generally, not fitting the picture. During the day the national television broadcasted absolutely no information on the events, and aired documentaries, cartoons and no news on any of the protests. To me, this looked very much alike what the Romanian Television aired during the Romanian Revolution in December '89 when during the fights in the streets of Bucharest the Television aired no images from the centre of Bucharest.

But, back to Moldavia, at the end of the day, sadly, the Parliament and Presidency buildings were devastated, making it easy for the Communist leaders to produce some disinformation propaganda based on real footage.

Yet again, sadly, but it seems under the protection of some of the aforementioned instigators, the flags of the EU and Romania were waved at the highest levels of the Parliament building during the time the protesters allegedly took over that building (there were several reports that the Police forces actually simply let them in, without actually needing/being forced to do that; also the passivity of the policemen seen in the footage from Romanian televisons was obvious).

As many Moldavian students live and study in Romania, some of them wanted to go home and take part at the protests happening in Chi in u. To their surprise, many of them were denied the right to enter their home country. Many, if not all, Romanian journalists were also denied access in the country accusing alternatively technical issues, lack of proper papers (although only the passport or the ID card was officially required), lack of safety, or simply refusing without reason.


Today, the Moldavian president Voronin, accused Romania as being behind the manifestations in Chi in u, Moldova's capital and said it will declare as a persona non grata the Ambasador of Romania in Moldova, and thus forcing him to leave Moldova within 24 hours. He went even further and said that visas will be required from now on for Romanian nationals. As soon as this was announced, it was one of the most invoked reasons by the Moldavian customs as a rejection reason, although, according to Moldavian Embassy officials in Romania, no rules or procedure were known for the release of visas for Romanian nationals.

Also, during Wenesday, Moldavian crossing points were opened and closed alternatively but incosistently accros the entire border for Moldavian nationals. Romanian nationals were denied in most cases (although some Romanian truck drivers were reported as allowed to cross). At some point during the day the Moldavian officials from the customs told the Moldavian students awating at the border that they are offered access on the condition they go direclty home with the buses provided by the Moldavian customs and were warned that going to Chi in u wasn't a smart choice for them. Some of the information from students which managed to enter their home country suggested that is advisable to not enter the country since they were going to be denied of the right to leave the country later, when they were to return to Romania to their studies (after Easter).

What's sadder is that the Moldavian voting system is built in such a way that the vote counting, in the end is done by Government officials behind closed doors, inside a Ministry. OTOH, the international official observed the things which happend in public, but did not see any of the dead voter lists (since they were not present when those votes were casted), and declared the vote as mostly legal and without major or significant incidents.


According to the media, before the elections, the Communists were credited with 35-37% of the votes in an independent poll, while in the exit poll conducted by the Communists themselves they were credited with 42-45% of the votes. In the end the last official partial results credited them with approximately 51% of the votes.

About Vladimir Voronin, it is a known fact that he has double citizenship, Moldavian and Russian and is a reserve general within the Russian Army and currently has a pretty nice pension from the Russian state.


All I can say is that, although the Moldavians' desire to have a real democracy is a legal and reasonable request, the western world chose, due to the international circumstances, to look the other way around and not to incommodate Russia in any way. Moreover, to accuse Romania to have unionist desires an act upon those desires is planly stupid since now Romania is part of the EU and Moldova uniting with Romania is simply impossible now, since Moldavia's economy would sunk even more the fragile and regressing Romanian economy and Romania would instantly fail the EU requirements which would mean disaster for us.

Mike Hommey: Detecting per-process namespaces

Back with per-process namespaces. This time, I will give several methods to more or less reliably detect their use, some requiring root access, some not. We will, though, limit ourselves to mount namespaces , that is, not PID, UTS or network namespaces. The first method, which is based on the contents of /proc/pid/mounts should work on any kernel supporting namespaces (since 2.4.19):
$ md5sum /proc/[0-9]*/mounts awk -F [ /]* ns[$1] = ns[$1] ? ns[$1] , $3 : $3 END for (n in ns) print n, ns[n]
/proc/[0-9]* is used instead of /proc/* to avoid listing self, too. The awk script displays a summary : a md5 sum followed by the PID of all processes which /proc/self/mounts file has this md5 sum.
This method relies on the fact that the /proc/pid/mounts files may be different between namespaces, even when the same mount points are used because the ordering may differ. This method is obviously unreliable, except when all namespaces have different mount points. During my tests, it has been reliable to detect whether a process uses the same namespace as the init process, but different processes with different namespaces were reliably listed together as having the same namespace. The next method, based on the contents of /proc/pid/mountinfo will work on any kernel implementing this file (since 2.6.26):
$ md5sum /proc/[0-9]*/mountinfo awk -F [ /]* ns[$1] = ns[$1] ? ns[$1] , $3 : $3 END for (n in ns) print n, ns[n]
The script is essentially the same, only pointing at mountinfo instead of mounts.
This method is quite reliable, as /proc/pid/mountinfo does contain different information even when no mount point was changed within a namespace. Unfortunately, chrooted processes can have a different content while not being in a separate namespace. I ve not investigated further, but you may be able to spot chrooted processes by comparing /proc/pid/mountinfo and /proc/pid/mounts. Both the above methods can be executed as unprivileged user, which alleviates the fact they are not totally reliable. The last method, on the other hand, is reliable, but requires root privileges, and cgroup filesystem support in the kernel (since 2.6.24).
$ mkdir -p /dev/cgroup/ns
$ mount -t cgroup -o ns /dev/cgroup/ns
$ find /dev/cgroup/ns -name tasks xargs -l1 sed ':a;N;s/\n/,/g;ta'
The output here is a group of PID on separate lines for separate namespaces. The sed one-liner replaces all carriage returns in the tasks files with a comma.
You don t actually need root privileges for the last command, if the cgroup filesystem is already mounted. But there has been no normalization as to where the cgroup filesystems should be mounted yet, and they aren t mounted by default on most GNU/Linux distributions, I believe. Cgroups (Control groups) allow to put sets of processes together to give them special behaviour (cpu provisioning, memory limitations, namespaces, etc.). They also allow to do so in a hierarchical way, such that a cgroup can inherit the properties of its parent cgroup. As its name and the way it is mounted indicates, our /dev/cgroup/ns is specialized for namespaces cgroups. The directory itself contains a few files, most notably a tasks file containing a list of processes in the current set/cgroup (in our case, namespace). It also contains a subdirectory for each child namespace. Each of these subdirectories is similarly structured, so that it also contains a tasks list and possible subdirectories for its own children. This means that not only can you spot different namespaces, but you can also spot how they relate to each other. There are a few glitches, though. As with other cgroups subsystems, you can create new cgroups by creating a directory in the cgroup filesystem, but it happens not to create a new namespace in the case of the namespace subsystem. With all the kind of namespaces that now exist in Linux, this is not a big surprise, but there doesn t seem to be neither a feedback in the cgroup filesystem to know what kind of namespace is involved, nor a control to force creation of a really separate namespace. You also can t move processes from one mount namespace into another by writing a PID in the tasks file in a given namespace ; that just gives an Operation not permitted error. On the other hand, contrary to the second method, chrooted processes are not separated out. I will investigate further cgroups with PID, UTS and network namespaces and will post my findings.

7 April 2009

Steve Kemp: A mystery of open questions

Date 30th March 2009 All being well the Debian Administration website now fully supports UTF-8. This change was a long time coming, considering the amount of time the site has been live. Most of the changes have been present for a while: The only missing part was ensuring the at the text input by visitors/users was correctly decoded and treated as UTF-8. This was handled by updating changing the Perl CGI module to explicitly call charset appropriately. Since the code behind the site masks the database, memcached, and CGI handles behind singletons the change itself was pretty trivial: I made more changes this evening to tie it all together, and to ensure that my Database connection is always forced to use UTF but I think that wasn't so important. I hope this is vaguely useful the next time I have to fight with character sets & encodings. It is just all so nasty. Failing that these pages are vaguely useful: ObFilm: Run Lola Run

Manoj Srivastava: Manoj: Not your father's kernel-package

A few hours ago, a new version of kernel-package was uploaded to experimental. This is a major change,and I would appreciate it if folks took it out for a spin, kicked the tires, and provide feedback about where this version is lacking. This is only part of the way along in this development cycle. I would like to add a debug-info separation, either in a different directory than / in the image packages, or a separate package by itself. I would also like to create an overlay directory for /usr/share/kernel-package/, so people can inject code or override the defaults for kernel-package easily. I am also willing to make any changes to standardize the handling of hook scripts for kernel packages in Debian.
Table of Contents

./debian/ is ephemeral
make-kpkg removes and re-creates ./debian on every invocation. This started as an exercise to protect ourselves from the upstream builddep functionality, that randomly cleaned out ./debian whether or not it had created it, effectively making it impossible to run dpkg-buildpackage easily (which is ok, if all you care about is the image package) This does make the kernel-package far more nimble; we now offer less surprise to users who did not expect stampts that the kernel-packagge used to not do duplicate work. Now, if you edit a couple of files in the kernel source, and run make-kpkg, the kernel will build as expected. There are no more version mismatch errors, and the kernel version can be modified using localconfig as one desires. With this, kernel-package can routinely be used to build kernels out of the git tree. The con is that we no longer cater to official kernels, or to anyone who expected content in ./debian to persist. At some point, there are plans to implement an overlay directory that will shadow /usr/share/kernel-package/ruleset, but that is not yet implemented. In any case, the kernel team in Debian regards kernel-package to be broken, and have been bad mouthing it and deprecating it for a few years now, so this will not be a loss for them.

Get rid of the facility to patch kernel sources
The patch the kernel facility was adding complexity, and failing to provide the flexibility required for a generic patching facility. It used to be useful at one point, but in the modern parlance, witht he widespread use of distribute version control systems, and various facilities to manage source and patch them, the built in version was clunky. This means the --added-patches option of make-kpkg is gone, the work-around is to prepare the kernel sources before calling make-kpkg.

Remove special case code for official kernels
For the longest tine (well, ever since Herbert Xu too over building kernel images from me), kernel-package has carried specal case code for official images. This has caused some problems, recently, since the need to preserve ./debian has caused no end of problems when the version changed out from under ./debian, or when people wanted to edit a file and expected kernel-package to do a minimal recompile. However, sometime in the Etch release cycle, the kernel team deprecated kernel-package as the means of building official kernels. They have recently started saying they think kernel-package is broken, and have their own recommendation for how to build kernel packages. Therefore, a full release cycle later, we can get rid of the special case rules used for official packages. Also, this allows us to drop ./debian at the drop of a hat, and recreate it with an version that reflects the current state of the kernel sources.

Header package no longer create symbolic links in /usr/src
Instead, ship an example shell script that replicates the old behaviour. This script can then be deployed on the target machines, and could be a part of a locally created kernel configuration package, if one needs to deploy the same behavior across a cluster of machines.

The postinst no longer manipulates symlinks
This is a shift from previous behaviour. Any symbolic link manipulation must now be done with hook scripts in /etc/kernel/*.d directories. Firstly, modern boot loaders scan the boot directory for kernel images, and the user no longer has to code in the path to the symbolic links that the kernel image package used to manipulate. Secondly, hardcoding the behaviour into the postinst made for a very rigid policy; and user wanted more flexibility than that. There is an example shipped with the package that shows a more flexible scheme that kept two symbolic links for version 2.4 kernels, and two symbolic links for 2.6 kernels; it can be easily modified to keep two links for 2.9 kernels and two links for 2.8 kernels, or one of each, or whatever the user wants.

Image postinst no longer runs a boot loader
Please note that this was already the case for grub, one of the more popular boot loaders. Now that we have a mechanism for running arbitrary scripts when the image packages are manipulated, we can stop embedding the boot loader actions in the package itself. This means that lilo, elilo, etc will no longer be run directly by the post install script, and all the code related to detecting the boot loader, managing the configuration, and adding bits about bootloader documentation is all removed from the postinst. This allows the image package to be more flexible, since the end user is no longer restricted to the actions encoded in the image package. This is a fairly large change. It also opens the door for the user to easily use non-standard bootloaders, if they so desire.

The image postinst no longer creates an initramfs
Instead, there are example scripts provided that will perform the task. These scripts will work for official kernel images as well. The initramfs scripts provided work with the make-kpkg images as well as the official images, and are thus better than the script shipped with initramfs-tools themselves, as they offer a super set of functionality. This also demonstrates how the posts install script communicates with the initramfs creation scripts so that no initramfs is generated in case you do not want it.

5 April 2009

Biella Coleman: End of an era

New York City is home to fantastic set of libraries, including the the mothership of libraries, the NYPL. My favorite library is one that is much smaller, located in the north of Manhattan on the campus of Columbia University: East Asian Starr. Quiet and compact, there are tall ceilings, dark wood, stained class windows, and reading nooks. When I enter, it feels like I step back in time (if I ignore the laptops, at least). When I was an undergraduate there, it was my library of choice and I logged many hours there and have yet to find a library I so love. I also was fond of the place because of their discreet open door policy. When I was a student there, over a decade back, they were supposed to ask for you ID but they never did. When I returned back to NYC in 2007, I was thrilled to find this practice of ethical inattentiveness was still followed by the student works behind the desk. I always wanted to find out more about what sustained this practice but I never dared or was too lazy to do so. So I was pretty saddened when I popped in the library on Friday to discover a new security system that requires you to scan your ID to get in. There were large signs also indicating such, clearly seething with some passive aggressive anger expressing disbelief that this library had managed to evade security for over decade. So while it is a real shame that this gem is no longer a place that one anyone can enter at will, it is nice to know that it took so long for someone to notice.

Jose Carlos Garcia Sogo: Backup your system for a desktop user

While Linux and Debian are plenty of programs for backing up your system, things change when you need a backup system for a common desktop user. In this area there is a lot of room for improvement, as programs for KDE and GNOME are years behind what programs for Windows and Mac OS X are offering.
There has been some programs intents of writing a good program, full featured and with a nice graphical interface, as Simple Backup, and its fork Not So Simple Backup, pybackpack, or TimeVault, an intent to clone Apple s TImeMachine, and it s fork TimeVaultNG written for KDE. Those are projects that start with a great impulse, even some of the mentored by Google Summer of Code, and when they reach some basic functionality, they get abandoned or not being properly maintained.
What I would like to see for a backup system for desktop user is: A lot of improvement and innovation has taken place in Linux Desktop during all these years, but backups are also important for SOHO users, and they need a well integrated program for doing that, as console based solutions usually require configuration skills which desktop users don t have.
Updated 6th April 22:26 CEST: I have been recommended in comments to try Back in Time and D j Dup. Both are in active delopment, which is a bonus. The first one works in a similar way to TimeVault, while the second one works using duplicity as backend, but has support to upload the resulting files to a remote server using SSH or to Amazon S3. I will investigate more on these apps.

2 April 2009

Filip Van Raemdonck: Some like it hot others just are

This week brought some really nice weather. Too nice already for some people, it would seem.<br /> While most people would likely enjoy a ride home on a sunny afternoon, for certain hotheaded ones the temperature appears to set their brains and blood boiling and remove the inhibitions for juvenile behaviour.<br /> Driving home I encountered a truck driver hanging out of his window having a heated argument with a car driver standing straight up through his sunroof. I couldn't hear what they were arguing about, as it happened a few cars before where I stood, but in the meantime they were blocking the two lane drive. I'd almost be surprised if it wasn't one or the other accusing his adversary of doing exactly that, blocking his trajectory.<br /> Luckily the scene didn't take too long and they drove on before others could join in on the argument.<br /> <br /> One pattern that I've observed so far in all incidents of traffic aggression that I witnessed, is that at least one of the parties was accompanied by a female passenger. I have to wonder if female company is in fact an influencing factor

MJ Ray: A Question of Debian ClamAV, Freshclam and Volatile

I m not a big fan of virus-scanning on the mailservers (I think you should bolt your email-sending computers right down so that viruses and spambots can t send email), but it seems to be a necessity these days. So, I was a bit late starting on mailserver-antivirus and mainly pay attention to it when it goes badly wrong. I ve got clamav installed where needed, but recently I m seeing clamav hang, eat CPU and cause postfix to defer all emails while logging nothing useful. Often this seems to be soon after freshclam kicks in. Anyone else seen this problem? Moreover, anyone managed to narrow it down and fix it? On some systems, instead of having freshclam, we have clamav-data from volatile which seems to work better, but are they missing out on anything by doing that? Does it lag a bit behind and download a bit more? Is there a third option, either another way of feeding clamav, or an alternative debian package, which you think people should consider?

31 March 2009

Sven Mueller: Link collection 2009/03

Well, I normally despise of thinks like this link collection, but I thought I might add it anyway, since these are useful links for me and if I don t post them here, I m likely to forget where to find them in the near future:
  1. Sean Finney has a nice post about storing the list of parameters a (shell) script got in a way that it can be restored later. Quite handy if your script walks through the arguments parsing them (and consuming them while doing so) but you want to be able to display them in a helpful way if the parsing fails at some point.
  2. A while ago, Ingo J rgensmann had a post that helps retrieving files from lost+found after a filesystem check, provided that you run his helper script on a regular basis. The same approach can also be used if you have a backup of all files, but lost the sorting work you did after the backup was done. This is possible because running the script can be done more often then you would normally do backups.
  3. He also has a small post about mtr oddities when IPv6 comes into play
  4. Adeodato Sim wrote about databases and when timestamps that store the timezone information really are more useful then timestamps that don t.
  5. Adeodato also has a short post on using ssh as a socks proxy, which can be quite handy if you are behind a firewall.
Update: Fixed link to Ingo s file retrieval from lost+found article. Thanks to Patrick Schoenfeld who pointed me at the wrong link.
Also thanks to the anonymous poster who found an alternative way to store and (in a way) restore commandline parameters. The solution doesn t work in an as general way as that by Sean Finney et al., but it is much shorter and therefore interesting for where it can be used (when you control how commandline parameters are processed). See comments on this post for details.

30 March 2009

Gustavo Noronha Silva: WebKitGTK+ 1.1.4 released!

So, we have been able to keep up with releasing every two weeks. I can t say I emptied my wishlist for this release, but we did get a good load of good new features, and bug fixes. Go get it, and come back to read about what s new. Those of you who hate when you middle-click a link and it opens in another window will be glad to know that this version clears the only lasting missing piece of API required to allowing the browser to concede your wish. If you get irritated with weird scrolling behavior when using the keyboard, this release also fixes most of the remaining pet peeves, with a proper GtkBinding implementation for our WebView, done by Xan. Font rendering has also received some much needed love, and we have chased and killed most of the problems with WebKitGTK+ wanting to download stuff instead of displaying them because of bad headers provided by the server. There is still work to be done in this area, but most of it will probably go into libsoup, instead. You may have heard about HTML5 media tags support. Well, we have sharpened some of the rough edges of the code that already existed, making it able to play some basic ogg examples, such as the ones used by the Mozilla guys for testing. Now on to make 1.1.5 rock even more!

Russell Coker: Inhaling Petrol Fumes

Tonight at 6PM the channel 7 news will have a special report about the dangers of inhaling fumes while filling cars with petrol. I m blogging now because based on past experience I expect almost no technical content in the report and that the advert for the news show contains everything that is useful. The advert showed that they had used some film technique to show the fumes leaving the petrol tank while fuel is pumped in. It was obvious that the fumes were rising past the face of the man who was filling the tank. Not that this is really news, if you observe closely when fuel is pumped into a car you can see where the vapor escapes as the slight difference in density causes whatever is behind it to shimmer slightly. For a long time the Prius has had a bladder inside the fuel tank which expands and contracts to match the fuel volume [1]. This greatly reduces the evaporative loss of fuel when the car is parked and the ambient temperature changes and also when fuel is pumped in. So it seems that in regard to the issue of fuel vapor poisoning the driver, the Prius has been better than other cars for about 10 years. Apparently Toyota have developed a new system that they have implemented in the Hybrid Lexus and the new Hybrid Camry which involves vapor recovery , this is supposed to give similar benefits in terms of not releasing petrol fumes into the environment but without limiting the capacity of the fuel tank in cold weather (a common complaint about the Prius). I have not been able to find any technical information on how this works (please let me know if you know a good web page about it). The next issue is that any car which gives good fuel efficiency and has a reasonable size petrol tank will be better in regard to vapor releases. The less frequently you need to refuel your car the less fuel vapor you will inhale. I predict that channel 7 will not suggest that people drive fuel efficient cars, they are probably more likely to go for hand-wringing about the inevitable health problems, or make vague claims that the government should do something about it. The fact that the news show in question is immediately followed by Today Tonight (one of the tabloid TV shows) is an indication of the likely quality. A final issue is the puddles of fuel that you commonly see at petrol stations. People regularly spill reasonable quantities of petrol and Diesel fuel and it just accumulates on the concrete. It s not uncommon that I will have to drive with my car windows open after buying petrol due to the petrol that I stood in evaporating from my shoes. Apart from training people to not be stupid when refueling their vehicles I can t think of any way of solving this problem. A petrol station employee once told me that it s not uncommon for people to refuel cars with their young children standing within splash range of the fuel nozzle. If people can t manage to avoid splashing their children with fuel then it seems that it will be impossible to get them to do anything reasonable or intelligent regarding the refueling process.

27 March 2009

David Welton: CodingHorror and Open Source Economics

Jeff Atwood writes about the economics of open source software: http://www.codinghorror.com/blog/archives/001247.html Well, he actually doesn't say as much, but that's what it's about. Someone really ought to do a book about this subject. I have some ideas - any takers? It's always tough to write about because there's so much material. It's a topic that is near and dear to my heart - almost 10 years ago, I joined the Free Software Business mailing list, as I got curious about the intersection of free software and business, and how the whole thing worked. I've learned a lot in the meantime, including a stint at Linuxcare, which was one of the Linux companies during the dot com boom, and am still fascinated by the subject. Before we get started, let's reiterate something:
  • It's clear that open source software works. There's just no doubt about it - it's been through ups and downs, the dot com boom and bust, and it will trundle happily (well, as happy as anyone is with this economy) through the recession too.
That point bears repeating. Everything else needs to take it into consideration. Could it work better? Differently? Perhaps, but it does work, so you need to understand it very well before you fiddle with it. Jeff writes:
for the average user? Heck, how realistic is this for the average programmer? Even if you're the type of macho, gung-ho programmer who can master an alien code base just to get some small pet feature or bugfix in -- do you honestly have the kind of time it would take to do that? Sometimes, when people say this:
The source code is freely available. If you feel so strongly about this bugfix/tweak/feature/plugin, why don't you code it yourself?
They're really saying this:
F**k you.
Which is of course a terrible analysis of open source, and its pros and cons. I wrote the following comment on Hacker News:
Heck, how realistic is this for the average programmer? ...
"Actually, I have submitted lots of (mostly small and inconsequential) bugs and minor features over the years, to projects such as the Linux Kernel, Tcl, Erlang, Ruby, Rails, Apache, and probably lots of others I'm forgetting right now. I actually enjoy it quite a bit, come to think of it - there's something cool about diving in and studying something new and different, and a thrill that comes with nailing the bug. Sometimes, the knowledge required to actually fix it is too much, and you have to settle for sending in a good bug report, but in other cases it's very much possible to hack up quick, useful things despite not knowing much about the system in question. And, no, I'm not really that great a programmer... I'd consider myself fairly average." And I know I'm not alone, as I see similar sorts of people in Debian and the Apache Software Foundation. Debian, infact, is all about those kinds of tweaks to improve the operating system as a whole. And this sort of exchange goes on all the time, as evidenced by the huge success of a large number of open source projects. Now, granted, most projects are really driven by one or a few really committed hackers, who do the lion's share of the work. However, that large network of people who contribute, test, document, and suggest is certainly important to any open source project. As long as we're looking at my anecdote, let's look at it in a bit more depth - most of those projects are developer tools or closely related. A cynic might note that Jeff comes from the world of Microsoft, where the core developer tools are provided by a company and 'giving back' is limited to payments and bug reports. But leaving that be, I think the enormous success of stuff like Ruby, Perl, PHP, Python, Tcl, Apache, Linux, GCC, and on and on and on indicates that, at least in terms of stuff that developers share between one another, open source works. However, there are problems, one of which is that he (or, in unfortunately rather rarer cases, she) who writes the code does not necessarily get the money. And without money, he or she who writes the code must dedicate themselves to some means to actually accumulate a bit of money in order to pay for living expenses. Most likely, this is time taken away from the open source project, which is a loss for all the people who benefit from it. Proprietary software solves this feedback loop in a neater way (generally) - companies that create good products get money for their efforts, which can then be reinvested in development. Jeff suggests that "sponsorship seems like a constructive way for people who are unable or unwilling to write code to affect the direction of a project.", which is ok as far as it goes, and more or less works here and there, but hopefully he's not thinking about trying it on a larger scale. This sort of thing has been tried before, and never really seems to take off. Part of the problem is that it can work on a person-to-person basis, but is almost impossible to standardize in a way that it makes sense to have some kind of clearinghouse that operates as a business. There are simply too many factors - what kind of open source project it is, what motivates the people behind it, how the transaction costs of defining a specification, monitoring the results, sending money and so on compare to the actual value of a fix... the list goes on. Ultimately, it's a nice idea, but it doesn't seem to work out too well in practice. Anyway, while it's a good thought on Jeff's part, at the end of the day, it is fairly evident that he doesn't have a lot of first hand knowledge of open source business and economics. That said, to some degree, open source took everyone by surprise, and, lacking the nice, simple feedback loop that proprietary software has, can be a lot more difficult to get a handle on. I find it quite pleasant that way - it attracts both hard-headed business types and social-experiment idealist visionaries; both huge corporations (IBM!) and a huge number of individuals; both people who have gotten quite wealthy from open source as well as most of the rest of us who manage to make ends meet but still love it. It's not something that's easy to pigeonhole, and as such it's hard enough to figure out the many ways in which it does work, let alone figure out how to improve on it. Stay tuned for further installments: Software Economics - Public Goods

David Welton: CodingHorror and Open Source Economics

Jeff Atwood writes about the economics of open source software: http://www.codinghorror.com/blog/archives/001247.html Well, he actually doesn't say as much, but that's what it's about. Someone really ought to do a book about this subject. I have some ideas - any takers? It's always tough to write about because there's so much material. It's a topic that is near and dear to my heart - almost 10 years ago, I joined the Free Software Business mailing list, as I got curious about the intersection of free software and business, and how the whole thing worked. I've learned a lot in the meantime, including a stint at Linuxcare, which was one of the Linux companies during the dot com boom, and am still fascinated by the subject. Before we get started, let's reiterate something:
  • It's clear that open source software works. There's just no doubt about it - it's been through ups and downs, the dot com boom and bust, and it will trundle happily (well, as happy as anyone is with this economy) through the recession too.
That point bears repeating. Everything else needs to take it into consideration. Could it work better? Differently? Perhaps, but it does work, so you need to understand it very well before you fiddle with it. Jeff writes:
for the average user? Heck, how realistic is this for the average programmer? Even if you're the type of macho, gung-ho programmer who can master an alien code base just to get some small pet feature or bugfix in -- do you honestly have the kind of time it would take to do that? Sometimes, when people say this:
The source code is freely available. If you feel so strongly about this bugfix/tweak/feature/plugin, why don't you code it yourself?
They're really saying this:
F**k you.
Which is of course a terrible analysis of open source, and its pros and cons. I wrote the following comment on Hacker News:
Heck, how realistic is this for the average programmer? ...
"Actually, I have submitted lots of (mostly small and inconsequential) bugs and minor features over the years, to projects such as the Linux Kernel, Tcl, Erlang, Ruby, Rails, Apache, and probably lots of others I'm forgetting right now. I actually enjoy it quite a bit, come to think of it - there's something cool about diving in and studying something new and different, and a thrill that comes with nailing the bug. Sometimes, the knowledge required to actually fix it is too much, and you have to settle for sending in a good bug report, but in other cases it's very much possible to hack up quick, useful things despite not knowing much about the system in question. And, no, I'm not really that great a programmer... I'd consider myself fairly average." And I know I'm not alone, as I see similar sorts of people in Debian and the Apache Software Foundation. Debian, infact, is all about those kinds of tweaks to improve the operating system as a whole. And this sort of exchange goes on all the time, as evidenced by the huge success of a large number of open source projects. Now, granted, most projects are really driven by one or a few really committed hackers, who do the lion's share of the work. However, that large network of people who contribute, test, document, and suggest is certainly important to any open source project. As long as we're looking at my anecdote, let's look at it in a bit more depth - most of those projects are developer tools or closely related. A cynic might note that Jeff comes from the world of Microsoft, where the core developer tools are provided by a company and 'giving back' is limited to payments and bug reports. But leaving that be, I think the enormous success of stuff like Ruby, Perl, PHP, Python, Tcl, Apache, Linux, GCC, and on and on and on indicates that, at least in terms of stuff that developers share between one another, open source works. However, there are problems, one of which is that he (or, in unfortunately rather rarer cases, she) who writes the code does not necessarily get the money. And without money, he or she who writes the code must dedicate themselves to some means to actually accumulate a bit of money in order to pay for living expenses. Most likely, this is time taken away from the open source project, which is a loss for all the people who benefit from it. Proprietary software solves this feedback loop in a neater way (generally) - companies that create good products get money for their efforts, which can then be reinvested in development. Jeff suggests that "sponsorship seems like a constructive way for people who are unable or unwilling to write code to affect the direction of a project.", which is ok as far as it goes, and more or less works here and there, but hopefully he's not thinking about trying it on a larger scale. This sort of thing has been tried before, and never really seems to take off. Part of the problem is that it can work on a person-to-person basis, but is almost impossible to standardize in a way that it makes sense to have some kind of clearinghouse that operates as a business. There are simply too many factors - what kind of open source project it is, what motivates the people behind it, how the transaction costs of defining a specification, monitoring the results, sending money and so on compare to the actual value of a fix... the list goes on. Ultimately, it's a nice idea, but it doesn't seem to work out too well in practice. Anyway, while it's a good thought on Jeff's part, at the end of the day, it is fairly evident that he doesn't have a lot of first hand knowledge of open source business and economics. That said, to some degree, open source took everyone by surprise, and, lacking the nice, simple feedback loop that proprietary software has, can be a lot more difficult to get a handle on. I find it quite pleasant that way - it attracts both hard-headed business types and social-experiment idealist visionaries; both huge corporations (IBM!) and a huge number of individuals; both people who have gotten quite wealthy from open source as well as most of the rest of us who manage to make ends meet but still love it. It's not something that's easy to pigeonhole, and as such it's hard enough to figure out the many ways in which it does work, let alone figure out how to improve on it. Stay tuned for further installments: Software Economics - Public Goods

Ingo Juergensmann

I just discovered that mtr has some problems with IPv6 enabled hosts when using the GUI. Try the following:

1) enter "mtr ipv6-host" in shell -> works
2) enter then an IPv4 only host Hostname input line -> doesn't work

3) quit mtr

4) enter "mtr ipv4-host" in shell -> works
5) enter then an IPv6 enabled host in Hostname input line -> tracing IPv4 part of IPv6 enabled host


So, something is broken, at least for 2). One could argue if 5) might be OK or the expected behaviour, but I believe that mtr should query the AAAA records and trace for the IPv6 hostname, regardless of whether you started with an IPv4 only host first.

Is there already someone tracking IPv6 related bugs in Debian? A tag in BTS maybe? Anyway, the above is reported as #521415.

Ingo Juergensmann: IPv6: oddities with mtr

I just discovered that mtr has some problems with IPv6 enabled hosts when using the GUI. Try the following:

1) enter "mtr ipv6-host" in shell -> works
2) enter then an IPv4 only host in Hostname input line -> doesn't work

3) quit mtr

4) enter "mtr ipv4-host" in shell -> works
5) enter then an IPv6 enabled host in Hostname input line -> tracing IPv4 part of IPv6 enabled host


So, something is broken, at least for 2). One could argue if 5) might be OK or the expected behaviour, but I believe that mtr should query the AAAA records and trace for the IPv6 hostname, regardless of whether you started with an IPv4 only host first.

Is there already someone tracking IPv6 related bugs in Debian? A tag in BTS maybe? Anyway, the above is reported as #521415.

UPDATE: added blog title ;)

Matthew Garrett: Reducing disk use

UNIX filesystems generally store three pieces of timing information about files - ctime (when the file was changed in any way), mtime (when the file contents, as opposed to its metadata, was last changed) and atime (when the file was last accessed by any process). This is a usefully flexible system, but the semantics of atime can be troublesome. atime must be updated every time a file is read, causing a read operation to instead become a read/write operation. This results in a surprising amount of io being generated in normal filesystem use, slowing the more relevant io and causing disks to spin up due to atime updates being required even if the file was read out of cache. It also results in a lot of unnecessary activity on flash media which may reduce their lifetime.

One option is to disable atime updates entirely. The problem with this approach is that certain applications depend on atime. This is especially common in mail clients which compare atime to mtime in order to determine whether a mailbox has been read since it was last modified. So, unfortunately, disabling atime entirely is impractical as a default. Back in 2006, Valerie Aurora submitted a patch that worked around this issue. The new relatime option meant that atime would only be updated if it would otherwise be older than ctime or mtime. Mail clients became happy and the world rejoiced.

Unfortunately, it turned out that there was one other common case of atime being used. Applications like tmpwatch monitor files in /tmp and delete them if they appear unused. In this case, "unused" means "has an atime older than a certain date". Since merely reading files doesn't update the ctime or mtime, relatime wouldn't cause the atime on these files to be updated and tmpwatch would happily delete them - even if users were reading them on a daily basis.

Ingo Molnar submitted a patch to add a further heuristic to the relatime behaviour. With it, the atime of a file will be updated if it's older than mtime, older than ctime or (and this is the important one) more than 24 hours in the past. This deals with the tmpwatch case nicely, while still providing a significant reduction in the quantity of atime updates.

Fedora shipped this patch for several releases, and Ubuntu have used it by default since 8.04. Unfortunately there were some concerns over certain aspects of its behaviour (in respect to its interface as opposed to the relatime functionality itself) and it never got merged. I pushed a trimmed down version that purely implements the change to the relatime behaviour, and earlier today Linus merged it and a further patch that makes relatime the default behaviour on Linux.

Most users won't notice this change in behaviour at all, other than as a small improvement in io performance and a reduction in the number of drive spinups. For users that do have issues, a new strictatime mount option has been added - using this will require an updated mount command, but it's a trivial patch. I'd be surprised if there are any real world use cases that are negatively affected by this, especially since it's been default behaviour in several distributions for a while, but there's always the potential that someone will be tripped up by it. We'll see.

26 March 2009

Holger Levsen: Ada Lovelace naming scheme

Two days ago I read about the Ada Lovelace day, which was an event were men and women were asked to blog about the women in technology which made an impact on them, in an effort to present girls (and women) all over the world with female role models in technology.

In similar though more personal motivation I choose my machine naming scheme at home two years ago: my (virtual) machines at home are named after women who made a difference, mostly in IT, but also some in more general science. Even though this list is not 100% in the spirit of pointing out the one woman who made a personal difference to one self, I thought I share my list, as I found it very interesting to learn about these great women myself.

goldberg is named after Adele Goldberg, who pioneered the smalltalk programming language in the 70s. According to a sympathetic annecdote she refused to show the system to Steve Jobs and only did so after her superiors ordered her to do so. Thats were Apple got many ideas which made them famous for being innovative...

goldwasser is named after Shafi Goldwasser, who is a RSA professor at MIT, doing research in complexity theory, cryptography and computational number theory. She is the co-inventor of zero-knowledge proofs.

lovelace is named after Ada Lovelace, and is widely recognized as the first programmer, who wrote a program (something that manipulated symbols according to rules) for a machine which has not even been build at that time. Of course, some men on this planet object to her being the first programmer, as work by women is always insignificant... </irony or maybe sarcasm>

bunten is named afer Danielle Bunten Berry, who was a game designer and programmer best known for the games M.U.L.E. and Seven Cities of Gold.

holberton is named after Betty Holberton, who was one of the six original programmers of ENIAC, the first general-purpose electronic digital computer, during and after World War II.

hopper is named after Grace Hopper who wrote the first compiler ever, the A compiler. She was also heavily involved in creating COBOL and standardizing COBOL and FORTRAN.

koller is named after Daphne Koller who does AI research at MIT and who seems to behind the idea of bayesian machine learning, which you might know from your spam filters... (I can only state her involvement in bayesian learning so vaguely as I'm basically clueless about the topic :)

leveson is named after Nancy Leveson who is also an MIT professior and is an expert in systems and software safety.

Last but not least I like to remark that none of the women above is even nearly covered with what I wrote here or what is written in wikipedia, which I used as my main source for this blog post. It's simple impossible to sum up one life that brief and be close to accurate.

And then there is another group of women whose achievements are noteworthy as well and who choose to present themselves on that webpage to show others that Debian is not a mens club. Thank you (a lot) for that and for your other contributions to Debian! If you want to learn more about these giants, I recommend this talk. Guess who's achievements I admire most in this group ;-)

Somewhat unrelated I wish to shout cheers to Yvonne, who tought me many things and who died six years ago today. You will also not be forgotten, though the pain is mostly gone now (well, it's gone, except for days like today). Thank you, among other stuff, for teaching me to celebrate and cheer every day, even if not everything is cheerful. Wenn die Nacht am tiefsten, ist der Tag am n chsten! :-)

Next.

Previous.