Software and hardware annotations, q1 2005

deb http://archive.Ubuntu.com/ubuntu/ hoary main universe restricted multiverse
deb http://archive.Ubuntu.com/ubuntu/ warty-security main universe restricted multiverse
deb http://archive.Ubuntu.com/ubuntu/ warty-updates main universe restricted multiverse
deb http://archive.Ubuntu.com/ubuntu/ warty main universe restricted multiverse

Package: *
Pin: release o=Ubuntu
Pin-Priority: 90

• It is now possible to select the elevator on a per-block-device basis, by using /sys/block/dev/queue/scheduler.
• I figured out why I was getting much lower hdparm -t results under 2.6 than under 2.4 and the it appears that to get the same results under 2.6 I must raise the filesystem readahead set with hdparm -an to some large value like 512 blocks.
  Evidently 2.6 kernels don't automagically do as much readahead as 2.4 kernels do.
  Note that lots of readhead make streaming tests look better, but may be terrible for other uses...

• Well, some of those patches are not really relevant to the original kernel, because they are SUSE specific or not relevant to a general purpose kernel. But still, there are so many fixes.
• In order to become part of the original kernel, they have to be submitted to the original kernel maintainers. I can easily see that the majaor distributions may think it is not in their best interests to proactively contribute their collections of fixes to the original kernel.

• Almost all P2P hosts are either on a modem or an ADSL line. This means that at best the theoretical down bandwidth is half the up bandwidth, and in several cases it is one eighth, as many services offer 2mb/s accounts with a 256kb/s up limit (there are also technical reasons for inefficient line utilization).
• About half of P2P hosts seem to be behind firewalls that forbid incoming connections completely. This is less of a problem for Gnutella/OpenFT, but it is just like that with eDonkey.

• P2P actually have very hierarchical, download style usage patterns.
• There are very few seed hosts to kickstart the temporary sharing that is what actually takes place, and these seeds are on relatively slow and overloaded connections.

Change the behaviour of peers to continue sharing even after the download completes.

This is weak because peers, most of whom have consumer grade, contended modem or ADSL connections, have pitiful upload bandwidths to offer, and it is unfeasible because it just goes against the grain of user behaviour, and the more commonly ISPs charge for bandwidth, against their self interest.

Put the same repositories that currently offer their archives on FTP/HTTP/RSYNC/Torrent on P2P networks too

This can work really well and greatly improve the reliability of downloads from those sites, at the same time relieving them of a large part of the bandwidth cost, as after all while people download they also end up sharing. It is unlikely however that this will happen, as many repositories are publicly funded (e.g. hosted by universities) and P2P systems have been demonized as vehicles for dishonest and criminal behaviour. The technical problem is that P2P systems typically present a completely flat view of the namespace of available files, and most existing archives are arranged, for very good reasons, hierarchically. This can be fixed by having P2P servers flatten file paths into file names, which is not hard.

FTP or HTTP

• Download is from a single server per file, putting huge loads on server.
• No built in verification of the integrity of the transferred file.
• When an MD5 checksum file is also available, this only tells whether the download failed, not where.
• Partial downloads in practice can only be restarted from the end.
• Fortunately there are very many FTP and HTTP servers, even if they are prone to congestion, unfortunately there are few systematic catalogs of servers and indexes of their contents, with the result that the well known servers are even more prone to congestion.

RSYNC

• RSYNC downloads in chunks and verifies the integrity of each chunk, and can redownload any arbitrary chunk, so that's pretty nice.
• There is still a single download source at a time.
• There are relatively few download servers.
• There are even fewer ways to find catalogs of RSYNC servers and indexes of their contents than for FTP and HTTP.
• Existing RSYNC clients are slightly more awkward than FTP or HTTP servers, which have nice shell-style or commander-style interfaces.

BitTorrent

• BitTorrent is basically RSYNC where chunks can come from many different servers, which all register with a the original BitTorrent server, which may or may not be the one with the original content.

eDonkey

TBD

Gnutella

TBD

• Mozilla uses GTK 1, which uses the X11 native font system, and Firefox uses GTK 2, which completely ignores it in favour of that idiocy, FontconfigXft2.
• One can change the Mozilla GUI font by editing/overriding the theme description for its GTK 1 theme, that is by adding some poorly documented lines to $HOME/.gtkrc.
• In theory, and as documented, one can change the GUI font for Firefox by similarly editing/overriding the GTK 2 theme, by adding some poorly documented lines to $HOME/.gtkrc-2.0.
• The GTK 2 per-user theme file is called .gtkrc-2.0 even in the 2.2 and 2.4 releases of GTK 2.
• The font specification in the .gtkrc-2.0 file uses the setting gtk-font-name whose syntax is similar to, but incompatible with that of Fontconfig/Xft2 font names, which in turn is hardly documented, and the differences seem gratuitous. For example, in Fontconfig font names the point size is separated from the font name by a dash, but not in GTK 2 settings.
• In any case, a bright guy has made sure that several settings which are possible in .gtkrc-2.0 are actually overriden by equivalent settings in the GConf database, which apparently is only documented in an email announcing this patch to a mailing list; this requires Firefox to be dependent not just on the GTK libraries, but also on the GNOME libraries, or at last the GConf ones.
• Even after all this idiocy has been worked out, if I choose a bitmap/PCF font it is bold by default, and I haven't been able to switch that off. Why? Why? Why?

Lets face it, because of C's constraints, writing GTK code, and especially widgets, can be ridiculously slow due to all the long names and the object orientation internals that C can't hide.