Suggestions for the GNOME Team //at 23:01 //by abe

Thanks to Erich Schubert’s blog posting on Planet Debian I became aware of the 2012 GNOME User Survey at Phoronix.

Like back in 2006 I still use some GNOME applications, so I do consider myself as “GNOME user” in the widest sense and hence I filled out that survey. Additionally I have to live with GNOME 3 as a system administrator of workstations, and that’s some kind of usage, too. ;-)

The last question in the survey was Do you have any comments or suggestions for the GNOME team? — Sure I have. And since I tried to give constructive feedback instead of only ranting, here’s my answer to that question as I submitted it in the survey, too, just spiced up with some hyperlinks and highlighting:

Don’t try to change the users. Give the users more possibilities to change GNOME if they don’t agree with your own preferences and decisions. (The trend to castrate the user was already starting with GNOME 2 and GNOME 3 made that worse IMHO.)

If you really think that you need less configurability because some non-power-users are confused or challenged by too many choices, then please give the other users at least the chance to enable more configuration options. A very good example in that hindsight was Kazehakase (RIP) who offered several user interfaces (novice, intermediate and power user or such). The popular text-mode web browser Lynx does the same, too, btw.

GNOME lost me mostly with the change to GNOME 2. The switch from Galeon 1.2 to 1.3/2.0 was horrible and the later switch to Epiphany made things even worse on the browser side. My short trip to GNOME as desktop environment ended with moving back to FVWM (configurable without tons of clicking, especially after moving to some other computer) and for the browser I moved on to Kazehakase back then. Nowadays I’m living very well with Awesome and Ratpoison as window managers, Conkeror as web browser (which are all very configurable) and a few selected GNOME applications like Liferea (luckily still quite configurable despite I miss Gecko’s about:config since the switch to WebKit), GUCharmap and Gnumeric.

For people switching from Windows I nowadays recommend XFCE or maybe LXDE on low-end computers. I likely would recommend GNOME 2, too, if it still would exist. With regards to MATE I’m skeptical about its persistance and future, but I’m glad it exists as it solves a lot of problems and brings in just a few new ones. Cinnamon as well as SolusOS are based on the current GNOME libraries and are very likely the more persistent projects, but also very likely have the very same multi-head issues we’re all barfing about at work with Ubuntu Precise. (Heck, am I glad that I use Awesome at work, too, and all four screens work perfectly as they did with FVWM before.)

Thanks to Dirk Deimeke for his (German written) pointer to Marcus Moeller’s interview with Ikey Doherty (in German, too) about his Debian-/GNOME-based distribution SolusOS.

deepgrep: grep nested archives with one command //at 02:00 //by abe

Several months ago, I wrote about grep everything and listed grep-like tools which can grep through compressed files or specific data formats. The blog posting sparked several magazine articles and talks by Frank Hofmann and me.

Frank recently noticed that we though missed one more or less mighty tool so far. We missed it, because it’s mostly unknown, undocumented and hidden behind a package name which doesn’t suggest a real recursive “grep everything”:

deepgrep

deepgrep is part of the Debian package strigi-utils, a package which contains utilities related to the KDE desktop search Strigi.

deepgrep especially eases the searching through tar balls, even nested ones, but can also search through zip files and OpenOffice.org/LibreOffice documents (which are actually zip files).

deepgrep seems to support at least the following archive and compression formats:

• tar
• ar, and hence deb
• rpm (but not cpio)
• gzip/gz
• bzip2/bz2
• zip, and hence jar/war and OpenOffice.org/LibreOffice documents
• MIME messages (i.e. files attached to e-mails)

A search in an archive which is deeply nested looks like this:

$ deepgrep bar foo.ar
foo.ar/foo.tar/foo.tar.gz/foo.zip/foo.tar.bz2/foo.txt.gz/foo.txt:foobar
foo.ar/foo.tar/foo.tar.gz/foo.zip/foo.tar.bz2/foo.txt.gz/foo.txt:bar

deepgrep though neither seems to support any LZMA based compression (lzma, xz, lzip, 7z), nor does it support lzop, rzip, compress (.Z suffix), cab, cpio, xar, or rar.

Further current drawbacks of deepgrep:

• Nearly no commandline options, especially none of the common grep options
• No man-page or other documentation
• Exit code not related to search results, you have to check the output to see if something has been found

deepfind

If you just need the file names of the files in nested archives, the package also contains the tool deepfind which does nothing else than to list all files and directories in a given set of archives or directories:

$ deepfind foo.ar
foo.ar
foo.ar/foo.tar
foo.ar/foo.tar/foo.tar.gz
foo.ar/foo.tar/foo.tar.gz/foo.zip
foo.ar/foo.tar/foo.tar.gz/foo.zip/foo.tar.bz2
foo.ar/foo.tar/foo.tar.gz/foo.zip/foo.tar.bz2/foo.txt.gz
foo.ar/foo.tar/foo.tar.gz/foo.zip/foo.tar.bz2/foo.txt.gz/foo.txt

As with deepgrep, deepfind does not implement any common options of it’s normal sister tool find.

[The following part has been added on 17-Nov-2012]

As with deepgrep, it also doesn’t seem to support any of the more modern or more exotic compression formats, i.e. it fails on modern debian binary packages which use xz compression on the data part:

deepfind xulrunner-18.0_18.0\~a2+20121109042012-1_amd64.deb
xulrunner-18.0_18.0~a2+20121109042012-1_amd64.deb
xulrunner-18.0_18.0~a2+20121109042012-1_amd64.deb/debian-binary
xulrunner-18.0_18.0~a2+20121109042012-1_amd64.deb/control.tar.gz
xulrunner-18.0_18.0~a2+20121109042012-1_amd64.deb/control.tar.gz/triggers
xulrunner-18.0_18.0~a2+20121109042012-1_amd64.deb/control.tar.gz/preinst
xulrunner-18.0_18.0~a2+20121109042012-1_amd64.deb/control.tar.gz/md5sums
xulrunner-18.0_18.0~a2+20121109042012-1_amd64.deb/control.tar.gz/postinst
xulrunner-18.0_18.0~a2+20121109042012-1_amd64.deb/control.tar.gz/control
xulrunner-18.0_18.0~a2+20121109042012-1_amd64.deb/data.tar.xz

[End of part added at 17-Nov-2012]

Dependencies

The package strigi-utils doesn’t pull in the complete Strigi framework (i.e. no daemon), just a few libraries (libstreams, libstreamanalyzer, and libclucene). On Wheezy it also pulls in some audio/video decoding libraries which may make some server administrators less happy.

Conclusion

Both tools are quite limited to some basic use cases, but can be worth a fortune if you have to work with nested archives. Nevertheless the claim in the Debian package description of strigi-utils that they’re “enhanced” versions of their well known counterparts is IMHO disproportionate.

Most of the missing features and documentation can be explained by the primary purpose of these tools: Being backend for desktop searches. I guess, there wasn’t much need for proper commandline usage yet. Until now. ;-)

42.zip

And yes, I was curious enough to let deepfind have a look at 42.zip (the one from SecurityFocus, unzip seems not able to unpack 42.zip from unforgettable.dk due a missing version compatibility) and since it just traverses the archive sequentially, it has no problem with that, needing just about 5 MB of RAM and a lot of time:

[…]
42.zip/lib f.zip/book f.zip/chapter f.zip/doc f.zip/page e.zip
42.zip/lib f.zip/book f.zip/chapter f.zip/doc f.zip/page e.zip/0.dll
42.zip/lib f.zip/book f.zip/chapter f.zip/doc f.zip/page f.zip
42.zip/lib f.zip/book f.zip/chapter f.zip/doc f.zip/page f.zip/0.dll
deepfind 42.zip  11644.12s user 303.89s system 97% cpu 3:24:02.46 total

I though won’t try deepgrep on 42.zip. ;-)

Conkeror usable on Ubuntu again despite XULRunner removal //at 00:08 //by abe

Because of the very annoying new Mozilla release politics (which look like a pissing contest with the similar annoying Google Chrome/Chromium release schedule), Ubuntu kicked out Mozilla XULRunner with its recent release of 11.10 Oneiric. And with XULRunner, Ubuntu also kicked out Conkeror and all other XULRunner reverse dependencies, too. Meh.

Sparked by this thread on the Conkeror mailing list, I extended the Debian package’s /usr/bin/conkeror wrapper script so that it looks for firefox in the search path, too, if no xulrunner* is found, and added an alternative dependency on firefox versions greater or equal to 3.5, too.

From now on, if the wrapper script finds no xulrunner but firefox in the search path, it calls firefox -app instead of xulrunner-$VERSION to start Conkeror.

With the expection of the about:-page showing the orange-blue Firefox logo and claiming that this is “Firefox $CONKEROR_VERSION”, it works as expected on my Toshiba AC100 netbook running the armel port of Ubuntu 11.10.

From version 1.0~~pre+git1110272207-~nightly1 on, the Conkeror Nightly Built Debian Packages will be installable on Ubuntu 11.10 Oneiric again without the need to install or keep XULRunner version from Ubuntu 11.04 Natty.

For those who don’t want to use the nightly builds, I created a (currently still empty) specific PPA for Conkeror where I’ll probably upload all the conkeror packages I upload to Debian Unstable.

Offener Brief an die SBB: Tarifregelung Faltvelos //at 21:38 //by abe

Auf Anregung von @RailService ein offener Brief an die SBB zum Thema Velotransport als Handgepäck (abgesendet via SBB Kontaktformular):

Für normale, zerlegte Velos kann ich ja verstehen, dass eine Verpackung erwünscht ist, da es sich dann ja um Einzelteile (meist zwei Räder und der Rest) handelt.

Dass aber Faltvelos nur dann kostenlos sind, wenn sie verpackt sind, ist eine Zumutung, da sie dann meistens noch grösser, unhandlicher und – aufgrunddessen, dass die meisten Verpackungen inklusive der SBB TranZBag schwarz sind – auch noch leichter zu übersehen sind. Und auch ansonsten macht es weder für das SBB-Personal noch Reisende einen Unterschied, ob das Faltvelo verpackt ist oder nicht. Es ist ein Gepäckstück wie jedes andere, sowohl in der Grösse als auch im Gewicht.

Die SBB (und der ZVV am besten gleich auch noch) möge sich ein Vorbild an den Verkehrsunternehmen nehmen, die für Faltvelos eine nachvollziehbare, eindeutige, und wesentlich sinnvollere Tarifregelung haben, nämlich anhand der Reifengrösse: Faltvelos (gefaltet, aber ohne unsinnigen Verpackungszwang) bis 20” Reifengrösse werden als Handgepäck betrachtet, darüber hinaus als Velo.

Der ZVV hat momentan sogar noch wesentlich ungenauere Formulierungen in ihren Beförderungsbedingungen für Velos (Hervorhebung durch mich):

Kleinkindervelos und Kindertrottinetts werden gratis befördert. Übrige leicht tragbare Fahrgeräte, auch demontierte und verpackte Fahrräder, werden gratis befördert, wenn sie über oder unter dem Sitz der Benützerin oder des Benützers untergebracht werden können.

Früher waren – wenn ich mich recht entsinne – in dem hervorhobenen Teil Faltvelos sogar noch explizit erwähnt. Jetzt ist es Auslegungssache, was ein “leicht tragbares Fahrgerät” ist. Ich finde jedenfalls, das Brompton ist sehr leicht tragbar, ein Fahrgerät ist es allemal. Ein ZVV-Kontrolleur wollte das neulich jedoch nicht wissen (hat sich aber auch nicht auf eine Diskussion eingelassen und ist ausgestiegen).

The mouseless side of X //at 00:48 //by abe

Although I like the idea of a tiling and completely keyboard focused window manager, I never fell in love with Ion because the default keybindings weren’t really intuïtive (to me). A few months ago I noticed, that ratpoison is also a tiling and completely keyboard focused window manager, only with much more intuitive usage: If you know screen and it’s keybindings, you also know ratpoison and it’s keybindings: Just exchange Ctrl-A with Ctrl-T. This sounds perfect for usage on my low performance laptops, where I have small screens and usually also no virtual desktops in use.

There’s only one thing which annoys me in ratpoison: If I use a mostly mouse driven application like e.g. a webbrowser with ratpoison, I have no problems to click on links, even if the webbrowser is not in the so called “current frame”. But if e.g. click into an input field, I usually notice much too late that while the mouse works fine in the browser, keyboard focus is still in some other window. Currently they all use flwm, the Fast and Lite Window Manager.

So what I would need is a tiling and keyboard focused window manager but with “focus follows mouse” politics. And since the laptops on which I intend to use such a window manager, all have a touchpad or thumbstick, the mouse there counts as keyboard focused, too somehow, doesn’t it? :-) I wonder, if an ion3 could be configured to use the same keybindings as ratpoison. That would probably fulfil this desire.

On the other hand, there are browsers which are fine without mouse. lynx or links2 for example, so the focus problem I have with ratpoison wouldn’t occur. But what if I need or want a keyboard driven and full blown webbrowser? Ok, Firefox as well as Opera are not that bad in keyboard only use, but they still are focused on the mouse using user.

But Gecko wouldn’t be Gecko, if there wasn’t some Gecko based browser with this features: On the ratpoison website I found a link to a very interesting Firefox plugin which makes Firefox a complete new browser, a keyboard driven webbrowser named Conkeror. It has no toolbars at all, no (visible) tabs, no menus, no nothing — it shows only the website in fullscreen, a status line and a multipurpose command line — exactly like the mini-buffer of GNU Emacs.

But not only the layout, even the keybindings are very emacsish: C-x C-f opens an URL in a new buffer -eh- tab, C-x 5 C-f opens an URL in a new frame (window), C-x C-v opens a new URL in the current tab (buffer) with the current URL as editable default value, C-x b switches to another tab, C-x k kills -eh- closes a tab, C-x C-b lists all open tabs, l goes back (remember the Emacs info reader, eh?), C-g quits accidently requested dialogs or stops loading a web page, Ctrl-s and Ctrl-r give you forward and backward i-search, C-n, C-p, C-f and C-b scroll, etc. Even M-x works, e.g. will M-x revert-buffer reload the web page. (Unfortunately Esc-x doesn’t work. Yet.) And for vi freaks, there is even M-x use-vi-keys. There’s even one lynxish keybinding: \ lets you view the source.

And although it’s one of the strangest webbrowsers I saw yet, I somehow like it and also would like to see it in Debian as package, since it is the perfect companion for ion or ratpoison. Looking through apt’s package cache as well as the wnpp bugs, I haven’t found any hint on somebody already packaging it, so I’ll have a look on it and on how to to package a Firefox extension for Debian.

BTW: While looking through the wnpp bugs, I found bug #335459, which is the ITP flock, an also Gecko based browser with a lot of cool features for blogger who like social network tools.

Another nice thing I found today in Debian was the xfonts-artwiz package whose small fonts are very suitable for small resolution screens, especially if a tiling window manager is used with a e.g. 800×600 resolution. Unfortunately they aren’t available in a charset with German umlauts.

Apropos tiling window managers: Anyone tried pconsole with an automatically tiling and resizing window manager? I wonder if it’s usable. At least on MacOS X with its cascading window positioning algorithm, pconsole is a pain. — But even without cascading windows, MacOS X is a pain for keyboard users. Just think of its default behaviour when using the tab key inside a form mask: It will skip all buttons, all checkboxes, all radio buttons and all select boxes. Argh!

Fedora Legacy useless? //at 15:16 //by abe

For a (much too long) time, we ran our three AMD 64 bit virus scanners and spam filter boxes with Fedora Core 4. Since the the official support ended a few months ago when Fedora Core 6 Test 2 came out, so we decided to switch them over to support through the Fedora Legacy Project.

For testing purposes we first switched over one of the three boxes. But the test failed: Although the changes (as documented on the Fedora Legacy home page) seemed to work fine, not a single update came until the end of last week, even though there were partially remotely exploitable security issues in OpenSSL, OpenSSH, gzip, etc. during that time. There were also no announcements on the list since FC4 switched over to the Fedora Legacy Project, not for FC4 nor for any other distribution maintained by the Fedora Legacy Project.

So what the heck does the Fedora Legacy Project if not security updates?

I would be very happy if I could switch over those boxes to Debian or even Ubuntu, but there’s no BiArch support (running 32 bit applications on 64 bit operating systems transparently) in Debian (and therefore neither in Ubuntu) yet without a lot of manual fiddling and chroots, so we can’t run our 32 bit virus scanners on those 64 bit boxes with a debianesk operating system yet.

Today we’ve upgraded the last of those three boxes to Fedora Core 5.

Mailing lists made my day //at 13:58 //by abe

Today actually two mailing lists made my day:

First Theo de Raadt’s mail to the FreeBSD security mailing list:

Date:       Mon, 02 Oct 2006 14:00:11 -0600
From:       Theo de Raadt <deraadt@cvs.openbsd.org>
To:         freebsd-security@freebsd.org
Subject:    Re: FreeBSD Security Advisory FreeBSD-SA-06:22.openssh 
Message-ID: <200610022000.k92K0B5P009759@cvs.openbsd.org>

> The OpenSSH project believe that the race condition can lead to a Denial
> of Service or potentially remote code execution
                ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Bullshit.  Where did anyone say this?

Why don't you put people in charge who can READ CODE, and SEE THAT
THIS IS ABSOLUTE BULLSHIT.

and Colin Percival’s dry reply pointing out who made the “ABSOLUTE BULLSHIT”:

Date:       Mon, 02 Oct 2006 14:25:05 -0700
From:       Colin Percival <cperciva@freebsd.org>
To:         Theo de Raadt <deraadt@cvs.openbsd.org>
Cc:         freebsd-security@freebsd.org
Subject:    Re: FreeBSD Security Advisory FreeBSD-SA-06:22.openssh
Message-ID: <452183B1.7000306@freebsd.org>

Theo de Raadt wrote:
>> The OpenSSH project believe that the race condition can lead to a Denial
>> of Service or potentially remote code execution
>                ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> Bullshit.  Where did anyone say this?

The OpenSSH 4.4 release announcement says that, actually:

 * Fix an unsafe signal hander reported by Mark Dowd. The signal
   handler was vulnerable to a race condition that could be exploited
   to perform a pre-authentication denial of service. On portable
   OpenSSH, this vulnerability could theoretically lead to
            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   pre-authentication remote code execution if GSSAPI authentication
   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   is enabled, but the likelihood of successful exploitation appears
   remote.

Colin Percival

Well, looks like an exquisite own goal. (Found by Squeeeez.)

Then, _rene_ cited a mail from the current Debian Project Leader Anthony Towns on debian-devel in #debian.de, who thought that »Switzerland was some foreign word meaning “snowy place”«:

Date:       Tue, 3 Oct 2006 15:52:38 +1000
Subject:    Re: Bits from the DPL: Looking forward
From:	    Anthony Towns <aj@azure.humbug.org.au>
Message-ID: <20061003055238.GA4841@azure.humbug.org.au>

On Tue, Oct 03, 2006 at 03:39:20PM +1000, Anthony Towns wrote:
> BSPs in Vienna (Switzerland) [3], 

I was assuming, of course, that "Switzerland" was some foreign word
meaning "snowy place", but apparently it's actually a country all of
its own, entirely separate to Austria...

On Tue, Oct 03, 2006 at 03:43:52PM +1000, Anthony Towns wrote:
> (b) Firmware vote
> proposal, as amended by Manon Srivastava (Message-id:

And while _Manon des sources_ might've been a neat French film, I don't
think it's actually got all that much to do with Manoj...

Cheers,
aj

And contrary to the usual biases, this geographic unawareness comes from Australia (which is unequal to Austria ;-) and not from the US. :-)

Guys, you all made my day. Kind regards from a currently not so snowy snowy place. :-)