Reviews about GNU/Linux software and hardware

Updated: 2011-12-04
Created: 2000

Linux review sites

There aren't many sites that review GNU/Linux based packages (or hardware from a Linux point of view) as it is not yet a major commercial product, but there are some from Linux magazines, among them:.

Phoronix
Phoronix does in depth review of the Linux kernel, graphics cards drivers for the Linux kernel, file systems. Sometimes their reviews are a bit naive.
Phoronix
Phoronix does in depth review of the Linux kernel, graphics cards drivers for the Linux kernel, file systems. Sometimes their reviews are a bit naive.
Linux User
Linux Format has many reviews and pointers to packages and products for GNU/Linux distributions.
Linux Format
Linux Format has many reviews and pointers to packages and products for GNU/Linux distributions.

List of Linux reviews (111204)

The reviews contained or listed in this page are usually my personal impression of the notable aspect and the overall worth of the things described rather than in depth ones.

I used to put reviews into this page, but I have changed my mind as most reviews become rather dated and fit better within my blog; I will put here brief pointers to those reviews here:

Older:

Older Linux reviews

The Xen hypervisor (050611)

Not quite a review of Xen yet, as I have not installed it, but I went to a really nice talk about it by its project leader and I have written some impressions of the talk.

The SVK source control system (050611)

Not quite a review of SVK yet, as I have not installed it, but I went to an interesting talk about it by its author and have written some impressions of the talk.

Software IP phones (060226)

I have been trying some software phones and here are my impressions.

The SIP-only Linphone 1.0.1 and KPhone 4.1.0 are both half-finished, mostly working, mostly undocumented; they are sort of useful but shoddy. Nothing unusual, unfortunately.

The IAX2 software phone KIAX 0.8.5 is also not finished, but rather more polished than the other two, with some very good ideas.

Of them I found KIAX to be by far the easiest and most reliable. Linphone can be made to work, but KPhone seems more reliable and lightweight than Linphone; some specific notes:

KIAX 0.8.5
  • KIAX is based on QT only, not on the whole KDE suite, which means that it is lightweight, but does not benefit nor requires KDE integration.
  • It only supports the OSS audio system, which is a pity but is the only softphone I have seen which permits to select distinct input, output and ringing devices. This means that for example in my two-soundcard situation (motherboard onboard sound and PCI soundcard) I can put my handsfree earphone and microphone on the first card, and speakers for playing music in the second, but also route the ringing to the speakers. This is very convenient, so I can hear ringing even when I am not at my PC with the handsfree earphone.
  • It only supports IAX2, so it does not work with SIP-only ITSPs.
    Fortunately there are many IAX2 ITSPs too, and IAX2 is a rather better protocol than SIP/RTSP.
  • It supports defining, saving and registering with multiple ITSP accounts, and switching them on the fly, with a simple drop down list.
  • Because of the design of IAX2, there is not need for the fiddly NAT dependent settings of SIP softphones.
  • Because of IAX2 there is not need to dial using SIP URIs including SIP realms. One can very well just dial typing in an unadorned telephone number.
  • Even if it is not quite finished it feels far more reliable and polished than either KPhone or Linphone. I haven't had crashes (but there is a gigantic memory leak, that makes its virtual memory allocation grow constantly), the contact list just works, the configuration is simple (largely thanks to IAX2, but the dialogs are well designed), and the sound also just works.
  • Again thanks to IAX2 it is fairly trivial to use it with a local Asterisk server to act as a local PBX.
KPhone 4.1.0
  • Being a QT application (despite the name, it is not a KDE application) it has a less whacky set of run time dependencies than a GNOME one.
  • Changing identity (that is the ITSP account details) requires restarting KPhone.
  • Only one ITSP can be configured.
  • It is possible to choose between OSS and ALSA, but not which ALSA device name is used, which can be rather annoying if one needs to select a non-default device.
  • In version 4.1.0, the latest official version released in December 2004, I could not make voice input work with ALSA; for some reason voice is captured as a buzz. Exactly the same setup works with Linphone. The current development version, 4.1.1-pre3, seems not to have this issue.
  • In some cases version 4.1.0 exhibits erratic behaviour, without crashing, especially when using ALSA. The current developement version, 4.1.1-pre3, seems rather more reliable. Neither however has a working contact list, and both occasionally refuse to connect reporting that No compatible media found.
  • It theoretically supports video calls too, handing them over to a custom version of vic.
  • The GUI based configuration is a bit awkward, but it is easy to understand and edit manually the $HOME/.qt/kphonerc configuration file.
  • It prints by default on its startup console some extensive traces of the SIP session, which can be rather useful, or useless, depending on taste.
Linphone 1.0.1
  • The GUI version is dependent on the GNOME framework. To me this is a considerable disadvantage because of all the notorious complications of GNOME.
  • Linphone crashed pretty often in my limited usage.
  • Even if Linphone has a contact list, I could not manage to put stuff in it that survives restart.
  • It supports IPv6, which could be quite useful to avoid NAT issues.
  • One can configure the IP address to use as the originating one, which can help work around some NAT cases.
  • It allows selecting OSS or ALSA devices, but the list of ALSA device names is autodiscovered, which means one cannot select a specific ALSA library device name. This can be very annoying if one wants to select a non-default device name, which can commonly be the case.
  • There is a command line version, linphonec, which is a significant advantage, but it seems to me very poorly designed (prompts end with a newline for one small detail...), and it is also crash prone.
  • The configuration can be done via the GUI, but it is stored in a file called $HOME/.gnome2/linphone which is legible but contains what look like obsolete settings and is not that comprehensible in parts.

Overall, in particular because of its higher reliability, KIAX is the clear winner, followed by KPhone 4.1.1-pre3.

aptitude (040709)

It is so much better than other ways of dealing with APT based dependencies. Only Synaptic is comparable, and it has a GUI, and is less finely tunable to do things manually.

Things that suck:

Debian distribution (040807)

My overall opinion is that it is tolerably good technically, even if with some important problems listed later. The best thing is that is “politically correct”.

RedHat, SUSE or Mandrake (and even Slackware) could go the way of SCO; a change of ownership or management or business plan might make them switch to offering a proprietary distribution containing mostly free software, like other companies do. This cannot imaginably happen with Debian.

Debian seems very much targeted at hard core UNIX people with access to lots of bandwidth, running either bleeding edge desktops for themselves or very stable services on old servers.

There are some distributions derived from Debian, like Knoppix, Libranet, Mepis, User Linux, Progeny, Munjoy, Bonzai, or even Linspire or Xandros, that are much better suited for non-advanced desktop users.

The Debian project does many things, but the main activity seems to be maintaining a vast collection of packages. It used to be that it was about releasing a distribution, but for the past few years this has not happened very much.

Another social aspect of the Debian project is that it seems that many of its members are somewhat obsessive and that perhaps as a result of this the release of an official distribution has been made conditional upon a large number of obsessively defined conditions, like being completely available on a large number of platforms and a long period of QA.

Since each of the strictures taken by itself is a good idea, and has enough vocal defenders, in practice none of them can be dropped, but their overall effect is near paralysis as far as official releases are concerned.

Other social strictures (more than structures) of Debian are fairly interesting too. Debian is a cathedral style project in which the following rules apply:

Also, I think that as most Debian developers already have Debian installed and are online via high speed lines, most are just happy to contribute to and keep updating via the package collection, and the bother of actually releasing a distribution does not excite them much.

Other projects are releasing distributions based on the Debian package collection, and their are more focused on releasing distributions more frequently and targeted to a greater range of potential uses.

Probably in effect if not in theory the Debian project will become like the Mozilla project, whose purpose is to develop a code base, and release test snapshosts of that code base, not to release a finished application.

Things that suck:

3ware simulates a SCSI disk subsystem

SCSI drives and host adapters usually support mailboxing with tagged queueing, and these give a very large performance advantage when several programs read a disk concurrently.

Unfortunately SCSI disk drives tend to cost several times more than ATA disk drives os equivalent capacity and otherwise similar performance.

3ware and other companies have spotted this as an opportunity and have designed host adapters that allow ATA drives to be used for RAIDs.

3ware in particular have one of these ATA RAID host adapters that simulates a SCSI host adapter. The important feature is that it has an onboard processor that handles queues of requests and the Linux driver supports that. In other words it does mailboxing with tagged queueing with ATA drives.

I have tried a 3ware 7410 model with two IBM 120GB drives; the drives were arranged as a RAID 0 (striped) volume, under Linux kernel 2.4.18. Each disk is capable of a sequential transfer rate of about 40MB/s with a single process reading from it, which falls to 8MB/s and lower when multiple processes read from it concurrently using a standard ATA host adapter.

When reading with a single process using the 3ware 7410 the aggregate transfer rate was about 80MB/s (because of striping across the two disks).

When reading with multiple process using the 3ware 7410, the aggregate transfer rate was near to 40MB/s, but it stayed near to 40MBs even if 10 or 20 processes were reading concurrently. This indicates that the 3ware does perform mailboxing with tagged queueing.

This is the same performance that is obtained by using a SCSI host adapter. But while the 3ware 7410 and an equivalent SCSI host adapter cost much the same (around $230), the ATA disk costs less than one third ($190) of a similar (smaller but faster) SCSI disk (about $680). In particular, the price of the 3ware card is half the difference in price between the ATA and SCSI disk drive.

The only downside to the 3ware cards is that they really require a PCI64 slot, even if they are comaptible with PCI32 ones, because of the very high transfer rates they support. Unfortunately PCI64 slots are present almost only on fairly expensive SMP server class motherboards. But then striped RAIDs can easily exceed the bandwidth of the PCI32 bus.

Conexant USB drivers

I have had the misfortune of buying a Zoom 5510A USB ADSL modem, and to make it work under Linux.

I have felt unfortunate because this has meant that I have had to have a look at the sources for the Linux drivers for this chipset, and to me they range from revolting to the merely appalling.

It is hard to convey just how outraged I am that what seems to me rubbish like the cxacru sources exist and infest my system. I have with considerable effort forced myself to look at them in detail, and even started rewriting them.

Among the numerous aspects that I think are ignorant or silly (from the makefile to the scripts, from the sources of the user space utility to the layout, and so on), one seems to stand out: the nontrivial API between the driver and its controlling utility is defined twice, with different symbols, in the driver and in its controlling utility, and the two ways just happen to be equivalent.

The saddest aspect of this all seems to me that the authors of the sources probably are individuals with lots of potential to be good programmers, because after all the drivers mostly work.

I think that writing something fairly complex well requires skills, writing something fairly complex really badly and still make it work requires extraordinary capabilities.

Finally the speedtch project has created a completely new (and much better written) cxacru driver which is from version 2.6.13 a standard part of the mainline kernel.