Search Results: "ag"

1 October 2010

Russ Allbery: Productivity

For once, not using that journal entry title to talk about my own. Someone posted a pointer to an opinion piece looking at productivity differences between the US and Germany to a private hierarchy I read. I know productivity numbers like this are somewhat disputed, but I don't want to get into that. What I'm more interested in is the analysis. Whether or not the US does significantly better or worse than other countries in this regard is hotly debated, but what isn't is that the length of typical work weeks for employees, particularly in IT, is not going down. Fifty or a hundred years ago, it was common to expect that the growth of automation would mean more leisure for humanity. There was, at the time, some argument over whether that would be a good thing, but it seemed to be a trend. This didn't happen here. The above article argues that the amount of vacation that US employees take is going down over time. And in IT it's common to hear about 50 hour weeks (or 80 hour weeks in startups). Little of that promise of increased leisure from modern technology seems to have happened in the US, although it seems to have happened somewhat in Europe; about all we managed was to get down to a 40-hour work week, which is now honored in the breech for a lot of exempt employees. And that was seventy years ago. Most of the scientific research that we have available is quite clear that working longer hours causes diminished productivity. Standard time management advice is to focus more and work in shorter intervals. Hours of unfocused work are considerably less effective than much shorter periods of focused work, recovery time is vital, and forcing oneself to work long hours leads to bad decision-making. Even in less cerebral and more repetitive work, such as some assembly line work, we've known for many decades that working longer hours leads to more accidents and more bad decisions, and there the costs of an accident are often much higher. So, why are we so dead-set on doing the exact opposite of what available evidence says is the best way to work? I think this is to some extent a Rorschach blot question: you're going to see the answer in this that fits your pre-conceived notions about what's dysfunctional about US workplaces. I rambled elsewhere about my own pet peeve: the overwhelming focus on money and short-term profit and cutting cost, which I think leads to a lot of the nasty employment abuses in the US. But here I want to raise a different point: as the article says, we work long hours because that's what we're measured on and rewarded for. We work unproductively for many of those hours partly because it's impossible to be productive for that many hours. We get used to feeling intermittantly unproductive at work; it becomes normal. And in many jobs, particularly in IT, we don't measure ourselves by results because we have no idea what a reasonable level of results actually is. Management gets a lot of blame for failure to manage by results rather than by artificial measures like attendance and time worked (or tickets closed, or hours logged against customer requests, or similar trivially manipulatable and artifical measures). But I think this goes deeper than management. I think even we ourselves, with as good of knowledge as anyone could possibly have of what our jobs are and what good results look like, don't have a clear idea of how much to expect from ourselves on a daily basis. I know from time management exercises that I wildly mis-estimate tasks and don't have a good feedback loop to get better at estimates. I also tend to plan towards maximums rather than the average. If I have a very good day, I try to work at that level and hold myself to that level of work, rather than trying to find a long-term average. And my perceptions about what results constitute good results vary wildly based on the most recent events and surrounding context (such as whether a project is late), even though I know that my basic work capacity is not going to change significantly because a project is late. If we want to change how we measure work, I think this may be the place to start. We can't ask managers to measure us by results if we don't even know what that measurement would look like. I'm going to start asking myself some new questions: What is the average amount of work I can get done in a day? What's the standard deviation? Is there some way that I can measure this over time so that I'm not fooling myself based on circumstances or temporary surges of productivity, since my day-to-day productivity seems to have a lot of "noise"? What realistically constitutes finishing a week's worth of work? When am I "working" but not accomplishing something, and more importantly, why am I doing that? What broke when that happens? I'm firmly convinced that one of my personal breakthroughs in time management will happen when I can stop "working" when I'm not being productive. Whenever I manage this (rarely, right now), I both find I needed the break and find that I can return far more productive than I was before I took the break. But usually I continue to "work" unproductively, clocking hours without creating results, and feel both guilty about the lack of results and even less productive. That's the trap that I think this article is pointing at.

30 September 2010

Jordi Mallach: GNOME 2.32

Once again, the GNOME project has released a major release on time, to the day. Congrats! While it doesn't feel like a major release, due to the pushing back of GNOME 3.0 another 6 months in the middle of the cycle and the limited changes included, I believe it'll be a good one because it just adds on top of the really solid GNOME 2.30. GNOME 2.32 is out a bit too late for Debian squeeze, but the Debian GNOME team has a plan to incorporate new 2.32 versions for modules which don't include big, intrussive changes like migrations to dconf, or any other dependency on the new versions of GTK or GLib. The result is that Debian 6.0 will ship with most of GNOME 2.30, plus some cherrypicked new versions of 2.32 modules.

Evgeni Golov: What to flattr?

The month is coming to an end, and I d like to recommend you some things on flattr.com :)OpenRheinRuhr Ein Pott voll Software Die OpenRheinRuhr ist eine Messe mit Kongress rund um das Thema Freie Software . Die OpenRheinRuhr 2010 findet am 13. und 14. November im Rheinischen Industriemuseum in Oberhausen statt. Freie Software ist aus Firmen, Verwaltungen, Bildungseinrichtungen und Privathaushalten nicht mehr wegzudenken. In der bev lkerungsreichsten Region Europas bietet der OpenRheinRuhr e.V. durch Ausstellungen, Vortr ge und Workshops Informationen ber Freie Software. Auch Themen jenseits der Technik, wie B rgerrechte im Netz oder die Handhabung von Lizenzen werden behandelt. Vortr ge in mehreren Tracks sprechen Menschen mit unterschiedlichem Kenntnisstand an vom Anf nger bis zum Profi. Entwickler & Projekte bekommen die Gelegenheit zum Erfahrungsaustausch. Weitere Informationen und Anmeldem glichkeiten unter: http://openrheinruhr.deBitlBee The IRC geek s solution to instant messaging. Tunnels instant messaging traffic (supporting all popular IM protocols and Twitter) to a virtual IRC channel and virtual IRC queries. Can be installed locally, but also available as a public service for people who can t/don t want to install it.
KiBi s blog This blog mainly features Debian-related posts on various topics: X.Org package maintenance (including calls for help, and status updates towards users), Debian GNU/kFreeBSD (GNU userland running on a FreeBSD kernel), and Debian s Graphical Installer (now based on X.Org). Also some upstream stuff, like the bugzilla replica type for SD (Simple Defects).
phpMyAdmin phpMyAdmin is a tool intended to handle the administration of MySQL over the Web. It can create, rename, and drop databases, create/drop/alter tables, delete/edit/add fields, execute any SQL statement, manage keys on fields, create dumps of tables and databases, export/import CSV data, and administrate one single database and multiple MySQL servers.
Debian Backports Over the last years I did numerous backports for Debian and also run backports.org. Since September 2010 we moved backports.org to backports.debian.org so its an officialDescriptions shamelessly stolen from flattr.Some words on these things:

Michal Čihař: Getting rid of SVN

Around three years ago I've migrated my stuff to Subversion from GNU Arch. Last year I migrated most important/alive things to Git. Unfortunately not all, so I still needed to host SVN server on my own. I think it's now time to get rid of it :-). In past weeks I've moved most Debian packaging stuff to some team/collab-maint repositories (being it Git or Subversion), because I really don't see need for hosting that stuff on my own. The remaining repositories are mostly historical (with single exception of StarDict dictionaries conversion tools) and nobody will probably care if they are gone. Ah and there are some dead projects as well which were never finished and will never be :-). Anyway svn.cihar.com is going to disappear soon and nobody will miss it.

Filed under: Coding Debian 0 comments Flattr this

Jonathan Wiltshire: Locusts

I came across the mingetty changelog by chance while researching something totally unrelated. Paul Martin, you are a genius.
mingetty (1.07-2) unstable; urgency=high
   * Critical security patch: Fix unsafe chroot call. (Closes: #597382)
   * Checked dependencies for locusts. (Closes: http://xkcd.com/797/)
  -- Paul Martin <masked>  Sat, 25 Sep 2010 01:51:12 +0100
Original cartoon: http://xkcd.com/797/
Comments flattr this!

Erich Schubert: Oktoberfest mode for your browser

Check out this web hack I just did: Drunken mode for your browserThis should work in Firefox, Chrome, Safari, Opera and maybe even Internet Exploders (untested).This is a Bookmarklet; if you bookmark the link, you are supposed to be able to apply it to arbitrary web pages.Note: when reading this web page through a planet such as Planet Debian, the JavaScript will be filtered and therefore probably not work.

29 September 2010

Gunnar Wolf: Ruby dissonance with Debian, again

Lucas has written two long, insightful posts on the frustration about the social aspects of integrating Ruby stuff Debian The first one, on September 12 and the second one, on September 29. I cannot really blame (thoroughly) the Ruby guys for their position. After all, they have a vibrant community, and they are advancing great pieces of work. And they know who that code is meant for Fellow programmers. And yes, although it is a pain to follow their API changes (and several of the Gems I regularly use do often get refactorings and functionality enhancements which break compatibility but introduce very nice new features), they say that's solved with one of Gems' main features being the simultaneous installability of different versions. The key difference in Debian's worldview with Ruby's is they cater to Fellow programmers. Even leaving aside heaps of different positions and worldview/mindset, we have a fundamental difference: Debian cares about its users, whatever that means. So, our users should not even care what language a given application is implemented in They should only care that it works. We, as packagers, should take care of all the infrastructural stuff. And yes, that's where we find the conflicting spot: We don't want to ship many versions of a system library (that in this case would be a Gem). Specially if later versions fix known bugs in earlier versions and backports are not available or supported. Specially if upstream authors' only response to a bug in an older release will be "upgrade and rewrite whatever breaks in your application". As an example of this, I am not currently updating the gems I maintain, as Debian is on a freeze to get out the next stable release. Or if at all, I am targetting those uploads to our Experimental branch, in order not to create a huge backlog for me when the freeze is over (just a series of rebuilds targetted at unstable). And yes, I will have to be responsible for any bugs that will most likely not be supported by most of my upstreams during the next ~2 years. That's the role of a Linux distribution. And yes, as Lucas writes in the comments he got as responses to the first post This dissonance comes in no small part because the Ruby developer community is mostly made from non-linuxers. People coming from a background where (mostly propietary) applications bundle up everything they need, where static linking is more popular than dynamic libraries, where there is no coordination between parts of the system are much less likely to understand our work. And yes, the Perl community is a joy to work with in this regard. And that's the same I understand from the Python one. Because of their origins and where their main strength was grown and remains. PS - And yes, I will join the flock of people saying that... The specific person that attacked your work is a great programmer, but well known as intolerant and obnoxious. Fortunately, even if our respective cultures fail to mix so much, most of our interactions just end with a "sigh" of lack of understanding, and not with the flames you got targetted with :-/

Lucas Nussbaum: How to demotivate people (Re: Making Debian Responsible For Its Actions)

In my Ruby packaging in Debian and Ubuntu: Mythbusting and FAQ, I wrote The Ruby developers (or expert users) community is generally very hostile towards Debian. Many harsh words and insults are used in discussions mentioning Debian in the ruby-core@ mailing list, and there are frequent recommendations to avoid the Debian packages and install from sources, which is quite demotivating (Actually, what prompted that blog post is someone calling Debian-specific changes unforgivable). Zed A. Shaw just provided a very good example of that. Quoting the most juicy parts:
It s simply a tactic to make sure that you are stuck on Debian.
If we look at this problem from an open source perspective, Debian is at a minimum being a horrible citizen.
What is happening is control is not aligned with responsibility. Debian has taken control of the software package and recrafted it for their very narrow set of system administrator users. However, they refuse to take responsibility for the defect and quality problems they create. Instead I end up being responsible for their mistakes, which is wrong.
If Debian is in control, then Debian should be made responsible. That s the only way to get them to change it. If they don t want to be responsible, then they should let me be in control.
I m imagining a mass petition, maybe some funny ad campaigns, in-person confrontations meant to embarrass package maintainers, SEO tricks to get people off Debian, promotion of any alternative to Debian, anything to make them pay, apologize, and listen.
If you write software and you re sick of Debian screwing up your gear, then shoot me ideas for how we can make this happen. I think that if enough of us band together to make Debian responsible for its actions we can actually get them to start asking us before they package our software to find out how we think it should be packaged.
On the technical part of the post: The problem that Zed is experiencing is unknown to me, and also to the Debian and Ubuntu bug trackers. To my knowledge, rubygems doesn t not require openssl or net/scp to work, and a simple grep through the sources kind-of confirms that. But of course, that blog post was written as a rant, not as a proper bug report. My best guess is that the gem that Zed is installing requires openssl and net/scp. But of course, rubygems can t just depend on all the libraries that applications or libraries installed via rubygems could possibly require. Regarding openssl, we had a problem in Ruby because of the licensing situation of Ruby (dual licensed GPLv2+ and Ruby license, linked with openssl, which might raise some eyebrows), so it was split off the main standard library package until recently (and, apparently, in the version Zed is using). For net/scp, it is not part of the standard library, and not a dependency of rubygems, so I don t see why Zed expects it to be installed. On the rest of the post: Following my last post, several people volunteered to help with Ruby on Debian (and Ubuntu). In particular, Laurent Arnoud has been doing some fantastic work fixing the pkg-ruby-extras team s RC bugs. Also, all the messages of support both in the comments of my last post were very much appreciated. But I m really wondering why the Ruby community generates so many poisonous people. All my work on Debian is done on a volunteer basis, and it s really hard to get so much shit from it.

Evgeni Golov: PokerTH in Debian and Ubuntu

If you do not play PokerTH yet, you might want give it a try :)If you already do, read on :)PokerTH 0.8PokerTH 0.8 was released a couple of days ago. The most exciting feature of this new release is the online ranking feature: you can register at poker-heroes.com and login with these credentials in PokerTH, now your games will be logged and you might reach place 1 at the ranking site.However, you won t see 0.8 if you do not have experimental (for Debian) or the pkg-games PPA (for Ubuntu) in your sources.list. As the release is only a few days old, it won t be included in Squeeze or Maverick. Sorry for that. But I plan to provide needed backports as soon they are needed (currently experimental and PPA should be sufficient, tell me if they are not).PokerTH 0.7.1As written above, 0.8 won t be shipped in Squeeze and Maverick, but 0.7.1 will be. With the release of 0.8, upstream has moved their server to 0.8. This means that Debian and Ubuntu users won t be able to play internet games on the official server (as long they did not install 0.8). I ve set up pokerth.debian.net running 0.7.1 and have just uploaded 0.7.1-2 which uses this server as default one to unstable (sync to Maverick will follow in a couple of hours). However, default means default on new installs. If you have already played PokerTH, you have a ~/.pokerth/config.xml with the upstream server in it and you have to change this if you want to play on my server. Please read /usr/share/doc/pokerth/NEWS.Debian.gz for this:
 pokerth (0.7.1-2) unstable; urgency=low
  The server at PokerTH.net now runs the 0.8 version of the software,
  which is incompatible with 0.7.x we ship in Squeeze.
  Because of that a 0.7.x server is running on pokerth.debian.net.
  On new installations this will be the default server used.
  On old ones you have to reconfigure your client yourself.
  Either set "Serverlist Address" under Settings   Internet Game to
  "pokerth.debian.net/serverlist.xml.z" or use the "Manual Server
  Configuration" using "pokerth.debian.net" as the server address.
 -- Evgeni Golov  <evgeni@debian.org> Mon, 27 Sep 2010 14:09:17 +0200
Sorry for that and enjoy nice flops and raises :)

Russell Coker: Links September 2010

Kevin Stone gave an interesting TED talk about the biological future of joint replacement [1]. Using stem cells and animal tissue which has been prepared to destroy the chemicals that trigger immune responses the tissues can regrow. Replacing joints with titanium and ceramic lets people walk again, regrowing them with Kevin s methods allows them to compete at the highest levels of sporting contests! Derek Sivers gave a brief and interesting TED talk advising people to keep their goals secret if they want to achieve them [2]. The Parrot AR.Drone is an interesting device [3], it s a four-propeller helicopter that is controlled by WiFi. Apparently there is little security (it binds to the first WiFi client it sees) which is a significant down-side. It returns a video feed to the controlling iPhone as it flys and can hover when it loses it s connection. It will be interesting to see when people write software for other devices (Android etc). Also I wonder whether there will be open source weapons kits for it. If you could have those devices use either a nerf gun or a lance to attack each other s turbines then you could have drone jousting. Don Marti had an interesting new idea for a crime game [4]. The main concept is to use the element of mistrust that is present in real criminal gangs. The new guy you invite to join a job might inform the police and you won t know for sure. Sometimes a heist will be discovered by the police through bad luck (or good police work) and you will wonder whether there was an informant. The aim is for a simple game design and with the complexity in email discussions between the players. The C64 isn t dead, it s even on the Internet [5], an original C64 is running a web site! Tan Li gave an interesting TED talk about a new headset to read brain-waves [6]. The device in question can be applied in minutes, requires no gel or abrasion of the scalp, connects to the computer wirelessly and is relatively cheap at $300US. The developer s kit (which I think includes a headset) is $500US. I wonder if the community can develop a cheaper version of this which is more open. Lisa Margonelli gave an interesting TED talk about the politics of oil [7]. One of her insightful points is that the subsidies for oil should be shifted from the oil industry to middle-class consumers. But she goes off track a bit by suggesting gradual oil tax increases until 2020, according to the best estimates of groups such as the CSIRO they won t need to have taxes to give a high oil price in 2020! She is aiming for a 20% reduction in petrol use by 2020, but I m not aware of any serious group of scientists who have evidence to suggest that the production capacity in 2020 will be close to 80% what it is now. Slate has a good article about The Innocence Project which uses DNA tests to overturn false convictions [8], it s scarey how badly the justice system works. Rachel Sussman gave an interesting talk about the World s Oldest Living Things [9], nothing less than 2000 years old is included. Nicholas Negroponte gave an interesting EG 2007 talk about the OLPC project [10]. While some of the content about OLPC production is a little dated the OLPC history is relevant and his personal opinions regarding the benefits that children receive from computers are insightful. Jayne Poynter gave an interesting TED talk about life in Biosphere 2 [11]. Her work on mini-biospheres is also interesting. Let s hope we get a permanent Biosphere running outside the Earth sometime soon. Sheryl WuDunn gave an informative TED talk titled Our Century s Greatest Injustice about the plight of women in most of the world [12]. Daniel Kahn Gillmor wrote a good article about the use of ssh-agent [13]. You really should use it to secure your ssh keys. Mark Shuttleworth has described the development process for the Ubuntu font [14]. This is a very interesting project and IMHO one of the most significant things that Ubuntu has done. Prior to this an entirely closed development process has been used for font development. Now we are getting a major new font family developed with a free and open process and with some new legal developments for a font license! One thing to note that this project appears to have involved a lot of work from professional font designers, it sounds like Canonical spent a significant amount of money on this project.

James Morrison: Weeping Tile

So I never had the chance to see Weeping Tile in Concert, but this year I have managed to see both Luther Wright in concert and Sarah Harmer. That and I found "The show 1995" channel on youtube which does have weeping tile in concert. And Uncle Remus.

Russ Allbery: Coding styles

I'm one of those people who tries to keep a very consistent coding style across all of my projects, including project documentation and build system layout, and also like reading other coding style guides to look for good ideas and clean ways of organizing packages. I first wrote a coding style guide for INN once I started working on it regularly, then moved and expanded on that guide and added Perl for my work at Stanford. Over time, I wrote a guide for C build systems and package documentation. These guides were all stranded in our old group web pages, which I'm working on retiring, and since they're my personal styles (although largely used by my group at work), it seemed to make the most sense to pull them back into my personal web pages. They're now available in a new coding style section of my technical notes. The build system document is heavily revised, since I originally wrote it before I started using Automake, and the documentation guide now has much more detailed documentation of how I lay out README files. The other documents just have minor revisions.

Runa Sandvik: Blackjack Essence: Well, I Suppose You re Taking Your First Expedition to Vegas?

Can you believe it? I still talk to people who don t know how to play blackjack. There must be something in the mechanics or tableau of blackjack that people find intimidating; for some reason, people can be a little cautious about taking the first move.
Photo courtesy of Winquerque on Net via Flickr. Clearly, there s no cause to hesitate. Players find quite quickly that it is actually not hard to figure out, and the strategies aren t even terribly complicated. For sure, if you re used to playing online slots, you are probably going to need to work a little harder to master the nuts and bolts. But it s still nothing like getting to grips with Texas Hold em from the beginning, for example!. Quite frankly, you very likely already know a fair portion of what most players have to know. I am able to give you the essentials in one simple little paragraph: If the card has aparticular number, that s the amount it will be worth. If it doesn t, it s worth 10. The only exception to this rule are Aces, which are worth either 1 or 11 (more about that later). Say hit when you have to get closer to 21, and/or stand when you don t. If you are closest to 21, you win. If you bust (get more than 21), you lose. Getting dealt blackjack (a natural 21 from the first two cards), makes you an instant winner (well, you and the dealer can also tie, or push ). Got it? OK, so it is not completely all you need to know. To begin with, most professional blackjack fans understand all too well that your goal has less to do with trying to get to 21, and just about everything to do with defeating an opponent. The dealer will not have the luxury of actually playing , precisely. Whether you re playing at a land-based casino or online (speaking of which, for additional info on USA casino players, all you have to do is click the link!), the house rules specify each individual play they can make. Mainly, she or he needs to take another card until their cards add up to the house rule limit (generally 17 and over). Of course, one of you will get an ill-fated draw and find themselves busted , but this decides a fewer number of games than you might expect. The tricky aspect of blackjack is the decision that you have to make if the cards add up somewhere around 12 and 16 (approximately, subject to other details). If you only had your own cards to consider, it would just be nothing but chance. Don t get me wrong, dumb luck has quite a lot to do with it. It is a card game, of course, and all card games are based on luck to some extent. But the serious gamer recognizes that luck is essentially a code word for statistics ; if you know what you have, and you possess a clue about the dealer s cards, you may make a knowledgeable judgment about which cards you re more inclined to end up with if you decide to hit another time. The most useful clue that you require to evaluate whether to play risky or conservative (sorry, I meant loose or tight ) is the dealer s upcard. Well, that s all for now, but for more information, you can always take a look at our friends at USA online casinos accepting Webmoney , who will get you up to speed. A bit later, we re going to get down to the serious nitty-gritty: doubling down, splitting, and much much more. Until then !

Russell Coker: Is Pre-Forking any Good?

Many Unix daemons use a technique known as pre-forking . This means that to save the amount of time taken to fork a child process they will keep a pool of processes waiting for work to come in. When a job arrives then one of the existing processes is used and the overhead of the fork() system call is saved. I decided to write a little benchmark to see how much overhead a fork() really has. I wrote the below program (which is released under the GPL 3.0 license) to test this. It gives the performance of a fork() operation followed by a waitpid() operation in fork()s per second and also the performance of running a trivial program via system which uses /bin/sh to execute the given command. On my Thinkpad T61 with a Intel(R) Core(TM)2 Duo CPU T7500 @ 2.20GHz I could get 2429.85 forks per second when running Linux 2.6.32 in 64bit mode. On a Thinkpad T20 with a 500MHz P3 CPU I could get 341.74 forks per second. In both cases is seems that the number of forks per second is significantly greater than the number of real-world requests. If each request on average took one disk seek then neither system would have the fork performance as any sort of bottleneck. Also if each request took more than a couple of milliseconds of CPU time on the T7500 or 10ms of CPU time on the 500MHz P3 then the benefits of pre-forking would be very small. Finally it s worth noting that the overhead of fork() + waitpid() in a loop will not be the same as the overhead of just fork()ing off processes and calling waitpid() when there s nothing else to do. I had a brief look at some of my servers to see how many operations they perform. One busy front-end mail server has about 3,000,000 log entries in mail.log per day, that is about 35 per second. These log entries include calling SpamAssassin and Clamav, which are fairly heavy operations. The system in question averages one Intel(R) Xeon(R) CPU L5420 @ 2.50GHz core being used 24*7, I can t do a good benchmark run on that system as it s always busy but I think it s reasonable to assume for the sake of discussion that it s about the same speed as the T7500 (it may be 5* faster, but that won t change things much). At 2429 forks per second (or 0.4ms per fork/wait) if that time is entirely reduced to zero that won t make any noticeable difference to a system that has an average operation taking 1000/35= 28ms! Now if a daemon was to use fork() + system() to launch a child process (which is a really slow way of doing it) then the T7500 gets 248.51 fork()+system() operations per second with bash and 305.63 per second with dash. The P3-500 gets 24.48 with bash and 33.06 with dash. So it seems that if every log entry on my busy mail server involved using a fork()+system() operation and it was replaced to use pre-forked daemons then it might be possible to save almost 10% of the CPU time on that system in question. Now it is theoretically possible that the setup of a daemon process can take more CPU time than fork()+system(). EG a daemon could have some really complex data structures to initialise. If the structures in question were initialised in the same way for each request then a viable design would be to have the master process initialise all the data which would then be inherited by the children. The only way I can imagine for a daemon child process to take any significant amount of time on modern hardware is for it to generate a session encryption key, and there s really nothing stopping a single master process from generating several such keys in advance and then passing them to child processes as needed. In conclusion I think that the meme about pre-forking is based on hardware that was used at a time when a 500MHz 32bit system (like my ancient Thinkpad T20) was unimaginably fast and when operating systems were less efficient than a modern Linux kernel. The only corner case might be daemons which do relatively simple CPU bound operations such as serving static files from a web server where the data all fits into the system cache, but even then I expect that the benefit is a lot smaller than most people think and the number of pre-forked processes is probably best kept very low. One final thing to note is that if you compare fork()+exec() with an operation to instruct a running daemon (via Unix domain sockets perhaps) to provide access to a new child (which may be pre-forked or may be forked on demand) then you have the potential to save a moderate amount of CPU time. The initialisation of a new process has some overhead that is greater than calling fork(), and when you fork() a new process there are usually lots of data structures which are not written after that time which means that on Linux they remain as shared memory and thus reduce the system memory use (and improve cache efficiency when they are read). #include <unistd.h>
#include <stdio.h>
#include <sys/time.h>
#include <sys/types.h>
#include <sys/wait.h>
#include <stdlib.h> #define NUM_FORKS 10000
#define NUM_SHELLS 1000 int main()

struct timeval start, end;
if(gettimeofday(&start, NULL) == -1)

fprintf(stderr, "Can't get time of day\n");
return 1;
int i = 0;
while(i < NUM_FORKS)

pid_t pid = fork();
if(pid == 0)
return 0;
if(pid > 0)

int status;
pid_t rc = waitpid(-1, &status, 0);
if(rc != pid)

fprintf(stderr, "waidpid() failed\n");
return 1;


else

fprintf(stderr, "fork() failed\n");
return 1;

i++;
if(gettimeofday(&end, NULL) == -1)

fprintf(stderr, "Can't get time of day\n");
return 1;
printf("%.2f fork()s per second\n", double(NUM_FORKS)/(double(end.tv_sec start.tv_sec) + double(end.tv_usec start.tv_usec) / 1000000.0) ); if(gettimeofday(&start, NULL) == -1)

fprintf(stderr, "Can't get time of day\n");
return 1;
i = 0;
while(i < NUM_SHELLS)

pid_t pid = fork();
if(pid == 0)

if(system("id > /dev/null") == -1)
fprintf(stderr, "system() failed\n");
return 0;

if(pid > 0)

int status;
pid_t rc = waitpid(-1, &status, 0);
if(rc != pid)

fprintf(stderr, "waidpid() failed\n");
return 1;


else

fprintf(stderr, "fork() failed\n");
return 1;

i++;
if(gettimeofday(&end, NULL) == -1)

fprintf(stderr, "Can't get time of day\n");
return 1;
printf("%.2f fork() and system() calls per second\n", double(NUM_SHELLS)/(double(end.tv_sec start.tv_sec) + double(end.tv_usec start.tv_usec) / 1000000.0) );
return 0;

28 September 2010

Lior Kaplan: LibreOffice first steps

It has been 12 hours since the LibreOffice announcement, and the projects starts to do its first steps.
  1. Neil Brown had submitted the first patch to LibreOffice, after waiting for 3 years (!) while the patch was available at the openoffice.org issues system (#80637).
  2. Michael Meeks had published Minutes of first LibreOffice technical group call . The general plan is to accept patches ( no large / risky / de-stabilising (new) feature work ) from the community and also merge the changes already done to openoffice.org (existing CWS).
  3. The public is welcome to help cleaning the existing code, Gil Forcada already started. see the EasyHacks list for the tasks to be done.
  4. LibreOffice mirrors now also contain the source code for the beta release done in the morning.
  5. Patches are welcome at libreoffice@lists.freedesktop.org or using the Bugzilla. See Get Involved Developing LibreOffice for more info.
You re welcome to join us
Filed under: LibreOffice, Openoffice.org Tagged: LibreOffice

Debian News: The FAI project gets its own domain name

For more than 11 years now, FAI (Fully Automatic Installation) lived happily at http://www.informatik.uni-koeln.de/fai. Now that it s grown up, it finally deserves its own home at http://fai-project.org. This also means less typing for all of FAI s friends.

Along with the new web home also its sister, the wiki, has moved from http://faiwiki.informatik.uni-koeln.de to http://wiki.fai-project.org

Other parts of the family, such as the mailing lists, stay at their place. If you are a friend with FAI, however, you might need to update your sources.list. If your sources.list configuration includes something like:

  deb http://www.informatik.uni-koeln.de/fai/download lenny koeln
please change it to the new URL accordingly, like:
  deb http://fai-project.org/download lenny koeln

The old URL s will still work, but we suggest to update to the new ones. If you have links on your web page to the FAI project, please update the links to the new location and also update your address book (aka bookmarks) accordingly.

FAI would like to thank its parents at the University of Cologne for hosting and continuing support. The new home is still provided by the University of Cologne.

Thomas Lange

Kartik Mistry: apt-get install moksha!

* No, we don t have moksha packaged yet. Sometime ago, Nirav forwarded me query regarding Utkarsh (my project where our goal was to provide complete Gujarati interface in OS) who got CD long time back but facing some issue. Last week, I decided to help and finish this pending task and went to place we decided. It was small laptop (ie EEE PC) for guru of group called, OM Parivar. I installed Ubuntu and customized it for Gujarati interface and required software. Second time, I went to Guruji s place for small training and I was wondering how fast man of 82 years can learn! He was very happy to see me helping and so I m converting more person to Linux. I also explained why I m using Linux and we even discussed about some Free Software philosophy. Next time: Keep Debian Installer with USB boot handy ;)

Jelmer Vernooij: Samba 4 and OpenChange daily Ubuntu packages

Daily builds As of a month ago there are Ubuntu archives with fresh packages of Samba 4 and Openchange, built on a daily basis day from the latest upstream revision. This means that it is now possible to run a version of Samba 4 that is less than 24 hours old, without having to know how to extract source code from the version control system that upstream is using, without having to know how to build and install an application from source, but perhaps most importantly: without having to go through the tedious process of manually updating the source code and rebuilding. OpenChange is tightly coupled to Samba 4, so installing a new version of OpenChange usually involves installing a new version of Samba 4 as well. To make matters more confusing, the two projects use different version control systems (Samba 4 is in Git, while OpenChange is in Subversion) and different build systems (Samba 4 uses waf, OpenChange uses autoconf and make). I have been involved in Samba 4 and OpenChange as an upstream developer and more recently also as a packager for both Debian and Ubuntu. As an upstream developer for both these projects it is important for me that users can easily run the development versions. It makes it possible for interested users to confirm the fixes for issues they have reported and to test new features. The more users run the development version, the more confident I can be as a developer that doing a release will not cause any unexpected surprises. As a packager it is useful to know when there are upstream changes that are going to break my package with the next release.

Recipes The daily builds work using so-called recipes which describe how to build a Debian source package from a set of Bazaar branches. For example, the Samba 4 recipe looks like this:
# bzr-builder format 0.2 deb-version 4.0.0~alpha14~bzr revno ~ppa revno:packaging + revno:debian 
lp:samba
merge debian lp:~samba-team/samba/unstable
merge packaging lp:~samba-team/samba/4.0-ppa-maverick
This dictates that a source package should be built by taking the upstream Samba branch and merging the Debian packaging and some recipe-specific tweaking. The last bit on the first line indicates the version string to be used when generating a changelog entry for the daily build. Every night Launchpad (through bzr-builder) merges these branches and attempts to build the resulting source package, e-mailing me in case of build problems. Generally I fix issues that come up by committing directly to upstream VCS or to the Debian packaging branch. There is no overhead in maintaining the daily build after I've set it up. For more information on creating source package recipes, see getting started.

Toolchain The entire toolchain that does the daily package builds for Ubuntu is Free Software, and I have contributed to various bits of that toolchain over the years. It's exciting to see everything come together.

Soyuz Launchpad consists of multiple pillars - one of those pillars is Soyuz, which I hack on as part of my day job at Canonical. Soyuz is responsible for the archive management and package building. Debian source packages (a combination of upstream source code and packaging metadata) get uploaded by users and then built for various architectures on our buildfarm and published to the Ubuntu archive or to users personal package archives.

Launchpad-code Another pillar of Launchpad is Launchpad-code, which is responsible for the hosting and management of version control branches. Launchpad users can either host their branches on Launchpad directly or mirror branches (either native Bazaar branches or branches in a foreign format such as Subversion, Git or Mercurial). The mirrorring of native and foreign branches happens using standard Bazaar API's. In the case of Samba and OpenChange we import the branches of the upstream projects (Samba is in Git, OpenChange is in Subversion) and the packaging for both projects is in Bazaar. Launchad-code calls out to Bazaar to do the actual mirrorring. Over the last few years I have done a lot of work to improve Bazaars support for foreign branches, in particular on supporting Subversion, Git and Mercurial. As the code mirrorring in Launchpad is one of the biggest users of bzr-svn and bzr-git it has helped find some of the more obscure bugs in those plugins over the last few years, to the point where there are only a handful of issues with Git and Subversion imports left.

bzr-git and dulwich bzr-git provides transparent access to Git repositories from within Bazaar and is built on top of Dulwich. Dulwich is a Python library that provides access to the Git file formats and protocols that is completely independent of Bazaar. James Westby originally started it and I adopted it for bzr-git and further extended it. There are now several other projects that use it as well, including hg-git, and rabbitvcs. Apart from James and me almost two dozen other people have contributed it so far.

bzr-svn and subvertpy bzr-svn provides transparant access to Subversion repositories in Bazaar. When I grew frustrated with the existing Subversion Python bindings for various reasons, I decided to create independent Python bindings for Subversion from scratch. These bindings have since been split out into a separate project - subvertpy - and other projects have since also started using them, e.g. hgsubversion and basie.

Using the daily builds To use the Samba 4 and OpenChange daily builds (Ubuntu Maverick only for now), run:
$ apt-add-repository ppa:samba-team/ppa
$ apt-add-repository ppa:openchange/daily-builds
cp: Karnivool - Themata

Guido G nther: What maps the shared objects of a security upgrade?

For a security update of a shared library to take effect processes need to be restarted in order to use the libraries from the newly installed package. The openssl and freetype updates got me thinking again if I caught all the affected services on servers and desktops/laptop systems I'm running. So I put together a small script that takes a package name and scans /proc/pid/maps for processes that map libraries from this package, it then looks for init scripts in these packages. It can also hook into apt and restart the services after the upgrade. Since the mapping to the init scripts is quiet dumb at the moment this should be used with a bit of caution though. The script whatmaps can be fetched form here. Debs are also available. Besides Debian packages it also handles RPMs and already proved useful since it pointed me to clamav being possibly affected by the recent bzip2 advisory. Flattr this

Lior Kaplan: Welcome The Document Foundation and LibreOffice

For those who haven t heard: OpenOffice.org Community announces The Document Foundation
The community of volunteers developing and promoting OpenOffice.org sets up an independent Foundation to drive the further growth of the project The Internet, September 28, 2010 The community of volunteers who develop and promote OpenOffice.org, the leading free office software, announce a major change in the project s structure. After ten years successful growth with Sun Microsystems as founding and principle sponsor, the project launches an independent foundation called The Document Foundation , to fulfil the promise of independence written in the original charter. The Foundation will be the cornerstone of a new ecosystem where individuals and organisations can contribute to and benefit from the availability of a truly free office suite. It will generate increased competition and choice for the benefit of customers and drive innovation in the office suite market. From now on, the OpenOffice.org community will be known as The Document Foundation . Oracle, who acquired OpenOffice.org assets as a result of its acquisition of Sun Microsystems, has been invited to become a member of the new Foundation, and donate the brand the community has grown during the past ten years. Pending this decision, the brand LibreOffice has been chosen for the software going forward. The Document Foundation is the result of a collective effort by leading independent members of the OpenOffice.org community, including several project leads and key members of the Community Council. It will be led initially by a Steering Committee of developers and national language projects managers. The Foundation aims to lower the barrier of adoption for both users and developers, to make LibreOffice the most accessible office suite ever. The Foundation will coordinate and oversee the development of LibreOffice, which is available in beta version at the placeholder site: http://www.libreoffice.org. Developers are invited to join the project and contribute to the code in the new friendly and open environment, to shape the future of office productivity suites alongside contributors who translate, test, document, support, and promote the software. Speaking for the group of volunteers, Sophie Gautier a veteran of the community and the former maintainer of the French speaking language project has declared: We believe that the Foundation is a key step for the evolution of the free office suite, as it liberates the development of the code and the evolution of the project from the constraints represented by the commercial interests of a single company. Free software advocates around the world have the extraordinary opportunity of joining the group of founding members today, to write a completely new chapter in the history of FLOSS . [...]
So welcome The Document Foundation and LibreOffice. I already can see how does the community benefits from this due to the merge with go-oo:
Q: What does this announcement mean to other derivatives of OpenOffice.org?
A: We want The Document Foundation to be open to code contributions from as many people as possible. We are delighted to announce that the enhancements produced by the Go-OOo team will be merged into LibreOffice, effective immediately. We hope that others will follow suit.
(from http://www.documentfoundation.org/faq/) So, will Oracle contribute the OpenOffice.org trademark to the community ? Time will tell
Filed under: LibreOffice, Openoffice.org, Proud to use free software

Next.

Previous.