One of the things I do not like are GUI programs behaving crappy because the programmer did not consider the complexity of the background operations and so the main GUI thread is overloaded while the UI feels jerky.

Current example is an extension for Sonata, the handy player GUI for MPD.

The result is the new multithreaded version of that patch. Now it does behave how I like it - user can type quickly, the result window is grayed out while it's searching and becomes active with results when the search is done.

Usually I don't code Python (never gelt a need to touch the code of a big application using it) but it was worth learning the basic syntax... well, it feels pretty usable after a bit relearning.

Yes Mark,

your rant expresses well what I think. And also what I have said before but apparently not many people do care. I still think that we need a strong DPL or a special delegate with powers of orphaning packages by force, since sometimes getting a new maintainer is a step ahead no matter how much experience the new maintainer needs to have. Skills can be learned. But skills in the hands of an inactive maintainer is simply dead potential. Doing something somehow is sometimes better than not doing anything.

A such hypothetical delegate would need to have the right nose to detect such cases and orphan such packages. No matter how important this package is - bugs are bugs are bugs and they need to be fixed in a timely manner, ie. without unacceptable/long delays, no matter which RL problems of the particular maintainer do hinder him/her.

Jurij, I would not get panicky just because somebody claims MD5 can be "broken" really, really, really quickly. They do not reveal many details but reading their attack scenario you can get a slight idea of what they did to "weaken" MD5.

In this case the attacker have control on both documents, the original and the forged one. I assume their method relies on getting a signature on exactly the same document that they created - without any modification and also on having a way to insert hidden, redundant data. And the signing party must be sufficiently stupid to sign things that it has no control about.

Applying this in a real-world scenario should become a bit more complicated. In most formats you can discover manipulations based on adding additional data. And in stronger watermarking technologies it would become much more complicated to add random data without violating the watermarking quality criteria (or even breaking the cover format).

All that just speculation, of course. I am looking forward to reading their paper.

Something in apt-cacher did always suck... I adopted the package short before the Sarge release and tried to make it work better. At that time the package was not in the best state, too many changes have done without big design (or any design?) in mind. I made some changes on the cache structure to make it easier maintainable, introduced a basic signaling mechanism and consistency checks, so it should not get stuck or deliver wrong data any longer.

However, there was the one big flaw, and Bug 354925 brought it to daylight. Storing all files in a flat directory was a very cheap way to merge multiple mirror contents and allow users choosing just any valid mirror. But it had also some costs: file collisions on identical names, happening more often since Ubuntu's is out there. The more I looked trough the code to find a good solution, the more I realized a need for a complete overhaul of the internal structure. For example, the simpliest change would be just putting the files into a nested directory structure. Great. But you will have duplicated files everywhere. They can still be re-unified using hardlinks, but that should be done offline since lookups with checksummng cause too much delay. And there was still the problem with persistent connections and forks, LWP does not allow connection reusing in forked clients so you get too many server connections. And the logging has been done synchronously and required flock'ing. Acceptable and not very memory-expensive but causes delays on filesystems with some load.

So, the final software architecture for apt-cacher that I came up can be described with few characteristics:

• using perl threads (separate threads for logging, connection dispatcher, connection handlers, download agents)
• not spawning too many threads, putting agent threads into a pool of available threads. That would even reuse the connection if the next apt-get client tries to access the same server
• no direct access via CGI or stdin/stdout (inetd) anymore. Instead, connection can be done via Unix Domain Sockets, so small wrappers will provide access to the daemon. That should be even more efficient.
• the problem with file duplicates will be solved with sqlite3 - apt-cacher will extract the data from Packages/Sources/Index files and track the paths/filesizes/checksums. When a client requests a file and a stored one (with the same size/basename/checksum) exits, it will be returned instead.
• the bunch of "header", "complete" and "notify" files will disappear too. They just eat space and inodes and are not needed anymore. The header files will be replaced with self-generated ones, using file data from the database. .complete and .notify existed basically for IPC and storage of origin download path and will be replaced with internal thread communication and directory path.
• integration of pdiff files - if the package index files are processesed in a background thread anyway, the more fresh pdiff files can be used to rebuild the index files in an efficient way. Trigering this rebuild action periodicaly would also allow old apt-get clients to use the benefits of the patch transport.

But first I need to get past my exams period :-( And I hope the final implementation will not become a memory monster, I didn't have the impression that Perl threads are really memory-efficient in the few first tests.

Eine Sache fehlt in den O2-Genion-Rechnungen: die Gesammtgesprächszeit. Ist ja auch kein Wunder, so könnte man durch einfache Division des Endpreises (sammt Grundgebühr und MWST) schnell auf den realen Minutenpreis kommen und dann sich etwa bei E-Plus umschauen.

Aber das lässt sich schnell ändern:

• Im Genion-Portal einloggen
• Die PDF-Datei mit Einzellverbindungsnachweis runterladen
• pdftotext 16.08.2005-*PDF

• perl -e 'for(<>) {if($go) {$go=0; $anz.=" $_";} \
  
      if(/^Dauer/) { $go=1}; } ; for(split(/\s/,$anz)) \
  
     { ($h, $m, $s) = split(/:/,$_) ; $len+=($h*60+$m+$s/60)  }; \
  
   print "$len\n" ' 16.08.2005-*.txt
  
  

So, after beeing hit by JoeyH's boot-floppies bug closing orgy and beeing bothered by all the old stuff in my BTS stuff mailbox, I wrote a simple script (derivate of grepmail) to remove all the messages related to closed bugs. Result on
http://rootfs.net/soft/bts-mbox-clean.pl.

Spitze, bravoröse Leistung vom Hermes-Versand. "Die Zustellung konnte nicht erfolgen, da der Empfänger an der angegebene Adresse nicht gefunden wurde."

Wie, bitte schön, kann man mich unter dieser Adresse nicht finden? Nur weil es ein Hochhaus war? Einfachste Logik (Stockwerk, dann Appartment-Nummer) darf man vom Fahrer ja wohl erwarten und sooo viele Knöpfe waren da ja nicht. Und wer nicht suchen will, wirft das in den GROSSEN Briefkasten für "Appartment unbekannt". Man muss nur wollen. Und ich weiss auch nicht, wann ich das letzte Mal einen Hermes-Boten hier in der Nähe gesehen habe.

Aber was will man als Kunde machen? Sich bei der Hotline beschweren? 0.60eur/min und nicht von O² aus erreichbar. Auch der Paket-Shop in der Nähe hatte keine andere Nummer. Darf man sowas Kundensupport nennen?

Eine einfache Überschlagsrechnung:
(vermeintlich gespartes Geld) - (Wahrscheinlichkeit solcher "Unzustellbarkeit")*Preis - (Hotline-Zeit)*0.60EUR/min = ...

Ich werde den Hermes-Versand jedenfalls nicht so schnell wieder in Anspruch nehmen :(

So, and now cloop-utils are available for Windows, thanks to the CygWin environment, and you can remaster Knoppix in a Win32 system or even use it as a compressing node used by a remote Linux box... get it from: rootfs.net/, the exe version has a simple installation frontend created with WinRar.

There are things that just make fun to look at. One of them is watching your custom Knoppix derivate beeing compressed with --best at almost the full speed your NIC can provide... with 5 modern RS6000 boxes attached to it ;-)

$ create_compressed_fs image2 out2 $NODELIST -a 1500 -j 5 -t 60 --best

Block size 65536, expected number of blocks: 18751

...

Input: 839188480 bytes, avg. speed: 10758826 b/s, 36s remaining

...

7zip: 18751 (1e+02%)

Hooray,

now the upstream of rxvt-unicode uses SPF with very paranoid setup, so the emails written from my university area cannot reach them, whatever I do. Now I have the choice to write a with the "funny" GMX webmail thingie, or just ignore him. All this leads to simple questions:

Does SPF solve any problems? Or does it create even more?

I really have doubts that it filters that much spam. Clever spammers will find ways to cloack the mail source. OTOH SPF hits a lot of valid messages, simply because the sender is not able (or allowed or willing) to use _exactly_ the same server for outgoing SMTP as for his mailbox hosting.

I consider closing some bug reports on my packages simply because the sender is not reachable any more. Using SPF is a clear demonstration of unwillingness to communicate and degrades the quality of communication within the Debian BTS to the Bugzilla level, and even worse.

I thought that my scsi-idle package is dead because the kernel patch is not applicable to kernel 2.6 (or, reportedly, can be ported but does not work well).

Fortunately, it was brought to my attention that recent kernel 2.6 versions support manually triggered spinning down of scsi devices, and a compatible utility called scsi-spin has been around for a while now.

All that allows me to implement a simple tool as replacement for the scsi-idle daemon. The current version is a small perl script that polls /proc/diskstats every 10min and suspend SCSI disks (and Firewire!) without activity. The next version that will go into the package will be coded in C to have smaller memory footprint, and have a more flexible configuration scheme with different times for different devices.

#!/usr/bin/perl

	
$statfile="/proc/diskstats";

$interval=600;

$prefix="sd";
	
die "Could not read $statfile\n" if ! -r $statfile;

do {

   open(st, $statfile);

   while() {

      if(  ($disk, $data) = (/^\s+\d+\s+\d+\s+(${prefix}[a-z]+)\s(.*)/)  ) {

         $newdata{$disk}=$data;

         if($seen{$disk} eq $data && $halted{$disk} ne $data) {

            syswrite(STDOUT, "Spinning down: $1\n");

            system "scsi-spin -f -d /dev/$1";

            $halted{$disk}=$data;

         }

      }

   }

   close(st);

   %seen=%newdata;

}

while(sleep $interval);

 apt-cacher (0.9.1) unstable; urgency=medium

...

   * added precache-by-Priority feature to apt-precache.pl

Ha, I could not resist the challenge when looking at how hackers in Guetersloh try to add features to a caching system that it has not been designed for and here it only needed few lines of code...

Just set up my first WPA enabled network, and it is the usual story - there is some trap and nobody cares enough to make user know what. wpa_supplicant cannot load michael cipher but

a) you need to run it by hand in debug mode to learn that (not displayed in syslog, haha)

and

b) it is unknown where to get it (I hade an idea where I need to look in the kernel setup, but a n00b would be simply lost).

I think, what Debian needs most is not another hacker but more people that understand the issues of newbies, that walk trough the whole process or look at newbies trying to actually use the software.

So,

gerade wird mein erstes PowerPC-System unter Linux eingerichtet. Nein, kein Mac, sondern eine alte RS6000-Workstation, 43P-140. Alles wäre so einfach gewesen, wären da nicht ein Paar Stolpersteine. Und die debian-installer-Doku war wohl hauptsächlich für Macs geschrieben :( :

• zunächst gab es herauszufinden, wie das Biest überhaupt zu booten ist. Irgendwann mal findet man raus, dass F1, 1, 0, 5, F5, 8 und F8 die eigentlich wichtigen Tasten sind.
• zum Glück fand ich das rplu-Howto für Debian Woody
• Leider ist die Default-Einstellung der Boot-Parameter falsch für Prep, die CD kann nicht einständig booten.
• leider musste die GraKa raus, weil sie nicht ordentlich von Linux unterstützt wird. Nach einigen glücklosen Versuchen, eine vernünftige serielle Console zu organisieren (alte AIX-Terminals taugen nicht viel, der Telnet-Wrapper der Igel-Terminals noch weniger), habe ich einen Null-Modem-Kabel und USB/serial-Adapter ausgeliehen und damit klappte es plötzlich wunderbar (mit urxvt und screen als Terminal-Programm), nur Strings mit Umlauten waren abgehackt (also englische Locale genommen)
• zum Glück gab es da das Video der Installation, das mir gezeigt hat, wo genau nun wie editiert werden muss. WTF ist es so schwierig, solche "offensichtlichen" Sachen zu dokumentieren. Typisch, "das weiss man doch" (ausser als n00b, dann guckst du dumm aus der Wäsche). Natürlich musste ich den zweiten console-Parameter entfernen, sonst hat die serielle Console nichts angezeigt. Das ist ja soooo offensichtlich :(
• Nächster Fehler: prep-Partition erstellen, aber nicht mounten, auch nicht als /boot. Eigentlich offensichtlich, aber von der i386-Welt ist man was anderes gewohnt.
• Der bootloader-Installer ist natürlich auch nur für Macs gebaut. Man sollte dem o.g. Video folgen (ggf. den Flash-Player auf Pause stellen) und so nachmachen.

Der Tag der offenen Tür an der FH Zweibrücken gab uns heute den Anlass, Ellen zu besuchen (ehemalige Mitstudentin, die dort wieder angefangen hat). Sie hat sich dort wohl ganz eingelebt und lieferte uns eine professionelle Führung durch die FH. Ingesammt muss ich jetzt sagen: Hut ab! Die FH wird dem Klischee Dorf-Uni (bzw. Dorf-FH) nicht gerecht, ganz im Gegenteil: sie machen viele coole Sachen!

Auch der anschliessende Spaziergang durch die Stadt war ganz nett, für ihre Grösse und Umgebung ist sie durchaus beeindruckend. Natürlich konnten wir nicht auf einen Besuch des Rosengartens nicht verzichten.

Die direkte Nähe der Studentenwohnheime zur FH fand ich ebenfalls sehr praktisch *g*, nur die weite Strecke zur Stadtmitte (steil bergauf/bergab) macht das Leben schwer.

Die ländliche Umgebung der Stadt erinnerte mich bei der Reise stark an Bayern (Münchens Vororte), viele grüne Wiesen, viele Hügel, ideal für Fahrrad-Fahrten (und Motorrad natürlich auch). Vielleicht sollten wir da wirklich mal eine kleine Radtour unternehmen...

AUTSCH. Grade beim Vorbeilaufen in der Küche merkte ich, dass mein Wasserkocher nur noch ein Paar cm vom Toaster entfernt steht und erinnerte mich gleich an das Bild vom Toaster meiner Eltern (abgebrannt, im wahrsten Sinne des Wortes, nach einem kleinen Wasserspritzer, der letztendlich auf der Steuerung-Plattine gelandet ist).

Independently from Progeny's Componentized Linux I made some similar thoughts about how we should split Debian into release modules, allowing each part to be released independently. It should happen within two dimensions, one based on subsets of the Archive so large blocks like GNOME related packages can be splitted out, and the other based on package popularity (which would be a much better thing than the Vancouver proposal).

A prototype tool I wrote demonstrates the possible cuts (based on breadth-first search with node/edge weights).

Continueing to recycle my old inka.de pages, now integrated VLFS.

So, having upgraded a system with many k users on my university from Woody+Backports to Ubuntu Hoary, I noticed a thing I have seen before: GNOME SUCKS. The gnome-session kept crashing while starting up... Jeez, what is so hard with making stable software and test the upgrade path? Even after removing the .gnome* dirs, it still kept crashing. The anoyning part was: you can press on ignore or report or whatever I did, it was always the same... stupid crash loop. (OTOH KDE survived the upgrade from some 3.x just fine, the only thing I had to change in the config were the font sizes).

I scaned my memory and could not remember any system where Gnome has been runnin on an upgrades system. IMHO there are only two kinds of systems in the GNOME world: the ones that are freshly installed (and most likely reinstalled periodicaly) and those that do not run GNOME suite as regular desktop.

I decided to move to the second part and drop gnome-session (though it is Ubuntu's primary desktop).

Wow, my surprise of the day:

m-a list | grep -- -- | wc -l

72

$ apt-cache rdepends module-assistant |wc -l

45

So it looks like the majority of Debian's module source packages is using m-a's includes now. I discovered that fact while thinking about a hack workaround for reliable tracking of version information to implement smart build-when-and-only-when-needed function for #303636. IMO there are only few popular packages among the "others" like nvidia* and alsa*.