X-Git-Url: http://pere.pagekite.me/gitweb/homepage.git/blobdiff_plain/97db8a6bf37fd9187881b0b6024db9c64b411231..d46b59f077fa6c9b3745fa2bb93dca66f444ef31:/blog/index.rss?ds=sidebyside diff --git a/blog/index.rss b/blog/index.rss index 7da8be61de..43e793bdf0 100644 --- a/blog/index.rss +++ b/blog/index.rss @@ -6,6 +6,61 @@ + + Debian boots quicker and quicker + Debian_boots_quicker_and_quicker.html + Debian_boots_quicker_and_quicker.html + Wed, 24 Jun 2009 21:40:00 +0200 + +<p>I spent Monday and tuesday this week in London with a lot of the +people involved in the boot system on Debian and Ubuntu, to see if we +could find more ways to speed up the boot system. This was an Ubuntu +funded +<a href="https://wiki.ubuntu.com/FoundationsTeam/BootPerformance/DebianUbuntuSprint">developer +gathering</a>. It was quite productive. We also discussed the future +of boot systems, and ways to handle the increasing number of boot +issues introduced by the Linux kernel becoming more and more +asynchronous and event base. The Ubuntu approach using udev and +upstart might be a good way forward. Time will show.</p> + +<p>Anyway, there are a few ways at the moment to speed up the boot +process in Debian. All of these should be applied to get a quick +boot:</p> + +<ul> + +<li>Use dash as /bin/sh.</li> + +<li>Disable the init.d/hwclock*.sh scripts and make sure the hardware + clock is in UTC.</li> + +<li>Install and activate the insserv package to enable + <a href="http://wiki.debian.org/LSBInitScripts/DependencyBasedBoot">dependency + based boot sequencing</a>, and enable concurrent booting.</li> + +</ul> + +These points are based on the Google summer of code work done by +<a href="http://initscripts-ng.alioth.debian.org/soc2006-bootsystem/">Carlos +Villegas</a>. + +<p>Support for makefile-style concurrency during boot was uploaded to +unstable yesterday. When we tested it, we were able to cut 6 seconds +from the boot sequence. It depend on very correct dependency +declaration in all init.d scripts, so I expect us to find edge cases +where the dependences in some scripts are slightly wrong when we start +using this.</p> + +<p>On our IRC channel for this effort, #pkg-sysvinit, a new idea was +introduced by Raphael Geissert today, one that could affect the +startup speed as well. Instead of starting some scripts concurrently +from rcS.d/ and another set of scripts from rc2.d/, it would be +possible to run a of them in the same process. A quick way to test +this would be to enable insserv and run 'mv /etc/rc2.d/S* /etc/rcS.d/; +insserv'. Will need to test if that work. :)</p> + + + Litt om valgfusk og problemet med elektronisk stemmegiving Litt_om_valgfusk_og_problemet_med_elektronisk_stemmegiving.html @@ -301,50 +356,5 @@ betydelige.</p> - - Two projects that have improved the quality of free software a lot - Two_projects_that_have_improved_the_quality_of_free_software_a_lot.html - Two_projects_that_have_improved_the_quality_of_free_software_a_lot.html - Sat, 2 May 2009 15:00:00 +0200 - -<p>There are two software projects that have had huge influence on the -quality of free software, and I wanted to mention both in case someone -do not yet know them.</p> - -<p>The first one is <a href="http://valgrind.org/">valgrind</a>, a -tool to detect and expose errors in the memory handling of programs. -It is easy to use, all one need to do is to run 'valgrind program', -and it will report any problems on stdout. It is even better if the -program include debug information. With debug information, it is able -to report the source file name and line number where the problem -occurs. It can report things like 'reading past memory block in file -X line N, the memory block was allocated in file Y, line M', and -'using uninitialised value in control logic'. This tool has made it -trivial to investigate reproducible crash bugs in programs, and have -reduced the number of this kind of bugs in free software a lot. - -<p>The second one is -<a href="http://en.wikipedia.org/wiki/Coverity">Coverity</a> which is -a source code checker. It is able to process the source of a program -and find problems in the logic without running the program. It -started out as the Stanford Checker and became well known when it was -used to find bugs in the Linux kernel. It is now a commercial tool -and the company behind it is running -<a href="http://www.scan.coverity.com/">a community service</a> for the -free software community, where a lot of free software projects get -their source checked for free. Several thousand defects have been -found and fixed so far. It can find errors like 'lock L taken in file -X line N is never released if exiting in line M', or 'the code in file -Y lines O to P can never be executed'. The projects included in the -community service project have managed to get rid of a lot of -reliability problems thanks to Coverity.</p> - -<p>I believe tools like this, that are able to automatically find -errors in the source, are vital to improve the quality of software and -make sure we can get rid of the crashing and failing software we are -surrounded by today.</p> - - -