Posted by Holger Schauer in
Linux
Wednesday, July 30. 2008
Debian just published an update to their stable distribution etch dubbed etch-and-a-half. The big news here for everyone not accustomed with Debians release cycle anyway is that it's the first time that it's not only a point release that fixes security issues but it's an update to the stable release that gasp adds support for new hardware, too. It even brings important fixes for some applications.
First of all, that's a tremendously good step in the right direction. In the past I've been bitten more than once by the long release cycle of Debian, outlasting all care taking of hardware compatibility. It's the primary reason that the only machine under my direct control running Debian is my rusty private workstation at the moment, all other machines needed newer drivers and hence are installed with Ubuntu. So, if Debian finally realizes that it has to change something to support newer hardware that's more than welcome.
However, it's not really etch-and-a-half. It's not much more than a new kernel which I would compile regularly from kernel.org myself anyway. Admittedly, there are also two new xservers (for nv and intel), but that's still not very helpful for people with newer ati hardware, for instance. But I'm a developer and much more than any hardware hassle I'm much more bitten by really outdated development tools. I've written only one blog entry about the issue, but it's a topic that most developers could write books about -- or maybe not, most of them probably just compile newer versions as needed and are done with the issue. This looks like the easy way out but it doesn't really solve the issue: if you've got to deploy your software you'll need to ensure that what you need is there. But using newer versions of base libraries forces you to deploy them yourself, which also means that you got a problem whenever a security issue will be found in those libraries. On the contrary, with system libraries you don't need any manual deployment of libraries you're only using and you can hope to participate of all system updates. So, in my eyes that's clearly a big advantage for using system libraries. But with Debian (and etch-and-a-half doesn't change this) you're stuck with older libraries which a) might lack long wanted functionality and b) are incompatible with versions from other vendors, which is a pain if you need to deploy on different platforms. Now, granted that the latter problem is not only tied to the age of libraries, but it would be a lot smaller if Debians general release cycle wouldn't be that long. I know of software vendors who have thus decided to develop for Ubuntu but not for Debian, in order to minimize portability issues due to library/functionality mismatches between platforms. To me, that looks like quite high a price to pay.
Posted by Holger Schauer in
Linux
Friday, May 30. 2008
I've tried Compiz with Metacity again and switch it off after a day -- again. I'm not willing to do without working software suspend just for some graphical whizz. I've been using Metacity for, I think nearly two years now, on my work computers and have somehow accomodated to it's various glitches (for instance the unusable keyboard settings). On my trusty home workstation, however, I've stuck with WindowMaker, which I think I've been using roughly since 1997 (I can't remember the version number, but it was fairly low). Unfortunately, development seems to have stopped -- since quite some time there is no sign of activity on the webpage and the mailing list archive is dead.
Yesterday, out of a current frustration about Metacity, I installed a naked current version of WindowMaker on one of my machines, under Ubuntu 8.04 (don't try to make WindowMaker work under Gnome: While WindowMaker does "work" under Gnome, it is really crippled. For instance, the keyboard setting know nothing about WindowMaker but still override your keyboard settings via, say, WPrefs.). Nearly everything worked as expected, but there were two glitches: the menu didn't reflect the installed software. Having customized the thing under my Debian system, I knew that this was supposed to work with the update-menu script, but that was missing. Some web-searching revealed that for some reason or other Ubuntu no longer installs the menu(-xdg) package. The other glitch was a very old complaint: That WindowMaker doesn't ship with a virtual desktop switcher or pager. You don't need to tell me about the different philosophy of WindowMaker, I know all about it. However, I've been using Fvwm and OpenLook (OLVWM) too long.
I could use gnome-panel (which I've done before in the past), but of course that brings me those two panels that make sense for Metacity and besides it also means that I would still depend on gnome. I've did quite a bit of looking around to find out what all the cool Fluxbox, Openbox etc. users are using and finally found fbpanel (the trick was to search for "taskbar" instead of "pager"). So, finally thanks to netwm support (which I think is in WindowMaker since 0.90), the one missing bit from WindowMaker is finally there without Gnome. Oh my, I'm finding this out really late.
Posted by Holger Schauer in
Linux
Monday, April 21. 2008
Dell is selling Ubuntu equipped systems since about a year now and seems to be quite happy with it. Whatever that effectively means, at least I can tell that I'm quite happy with Linux on Dell systems, too.
Through the last five years, I've been using Linux on a number of Dell systems. Under my personal control there have been three laptops (Dell C610, D610 and a Latitude 640) and a desktop (Optiplex 755), on which I have been running Debian Sarge, Ubuntu Dapper, Feisty and now Hardy. We also had several Dell servers at work running more or less smoothly with Debian (sarge, etch). Using Linux wasn't always without problems: I had trouble with built-in modems, PCMCIA ISDN cards and acpi/hibernation. For example, on my private Latitude 640, I have trouble suspending at all, because of the ipw3945 driver for the wlan. But the important thing to note is that basically all problems were really small and never of a size requiring me to use some other OS in the first place.
The only real issue is not with Dell per se, but more with my favourite OS, Debian: over the years, and especially with the ever-lasting sarge release, getting Debian to run on a recent system got more and more difficult. That's the main reason why I've been using Ubuntu on all recent hardware I had contact with: it's more or less (more so than less) a Debian system but does run on modern hardware. Main issues here were graphics adapters, sata/scsi hostadapters and network/wifi cards, or to put it otherwise: too old kernels, too old X.org. Both problem sources can simply be solved by using a recent version of Ubuntu. Sorry, Debian, but your release cycle is just too long to be acceptable. Granted, all these problems are mostly an issue when installing a new system, but it's not always possible to plug in some old disc with a working version of Linux.
Posted by Holger Schauer in
Programming
Wednesday, October 17. 2007
Like I mentioned in a previous post ( here), I hadn't looked closer at those modern distributed revision control systems like Git, Darcs or Mercurial. This was mainly due to two facts: As I'm currently neither involved in any major open source project which uses these systems nor in a project at work which requires the facilities offered by such systems, and as there was no easy access for them in XEmacs, the more traditional systems like Subversion, CVS and RCS are fine for me. However, there was this nag that I might miss something and as revision systems always have been somewhat of a pet peeve of mine, I eventually spend some time reading up more on them. I've read quite a lot of discussions on the web, and gathered that mercurial might be worth a closer look, as it claims to be quite easy to handle, comparably well documented and quite fast. And then finally I've read on xemacs-beta that the new vc package (in Pre-Release) would support mercurial as well.
Well, that's where I am now: I have several pieces of code lying around which I sometimes develop on my main machine and sometimes on my laptop when moving around. This is the scenario where a server-based approach to revision control is not what you want: you won't be able to access your server while you're on the road and hence you can't commit. Now, with RCS that's not a problem, as there is no server involved. But of course, since RCS is a file-system local revision system, syncing is a major problem and you have to go to great pains to ensure you don't overwrite changes you made locally in between syncs. I hope that a distributed version control system like mercurial will solve the problem, as I no longer have to decide which version is the current head version, instead cherry-picking change sets at will.
But of course, for this to happen, I have to convert my RCS repositories to Mercurial. This doesn't seem to be a common problem: there are a lot of tools for conversion from CVS or Subversion (see Mercurial Wiki, e.g. Tailor for instance), but not from RCS. I ended up following the instructions given in the TWiki Mercurial Contribution page. I have some minor corrections, though, so here we go:
-1. (Step 6 in TWiki docs) Ensure all your files are checked in RCS. I won't copy the advice from the TWiki page here, because I believe in meaningful commit messages and would urge you to do a manual check.
0. You'll need cvs20hg and rcsparse which you will find here. You'll need to have Python development libraries installed, i.e. Python.h. For Debian systems, this is in package python-dev. Installation is as simple as two "./setup install" as root which will install the relevant libraries and Python scripts.
1. Create a new directory for your new mercurial repository (named REPO-HG, replace that name):
mkdir REPO-HG
2. Initialize the repository:
hg init REPO-HG
3. (Step 4 in the TWiki document) Create a new copy of your old RCS repository (named REPO here, replace that with the name containing your old RCS files), add a CVSROOT and a config file (mistake one in the TWiki docs: As with all CVS data, the "config" file needs to go to CVSROOT, not to CVSROOT/..). Of course, if you're no longer interested in your old data, you may omit the initial copy.
mkdir tmp
cp -ar REPO tmp/REPO-old
mkdir tmp/CVSROOT
touch tmp/CVSROOT/config
4. Inside your directory with the old RCS data, move everything out of the RCS subdirectories
(mistake two in the TWiki docs: the double-quotes need to go before the asterix):
find tmp/REPO-old -type d -name RCS -prune | while read r; do mv -i "$r"/* "$r/.."; rmdir "$r"; done
5. Run cvs20hg to copy your old repository to mercurial. If you don't follow the directory scheme shown below, you'll end up with your new mercurial repository missing the initial letter of the name of all top-level files and directories.
cvs20hg tmp/REPO-old `basename tmp/REPO-old` REPO-HG
6. Check that everything looks like you would expect:
cd REPO-HG
hg log
7. If you had files in your old directory not under version control that you'll like to keep, copy them over. This might be a good time to think about whether they are worth having them under revision control. Afterwards throw away any old directory you no longer need (i.e., your original REPO, tmp/*).
Posted by Holger Schauer in
Programming
Monday, August 13. 2007
Joey seems to have inspired a "list of programming languages you know"-contest over on planet.debian.org, so this is mine:
- Basic (forgotten)
I've started using Basic on the Commodore C64 and have used it considerably, apart from the intrinsics of peek and poke, which some would claim was what Basic on the C64 was all about. I also used Basic on the Apple II at school, but was spared any further need to use Basic.
- Cobol (forgotten)
I remember my old computer science teacher bringing white and green prints on endless paper and teaching us the joys of Cobol. Having used Basic before, it looked somewhat suspicious but not too alien. Fortunately, we only had to solve some simple problems on paper, as the Apple II only had .... DBase II, I think.
- Pascal (forgotten)
(Turbo) Pascal was the language of choice in the first semester at the University of Koblenz at the start of the nineties. I've did what I had to do in it, but never really liked it. From the occasional look I throw in Wirth's algorithms book I know I can still read it, but the language looks just as baroque as the copy of the book I have.
- Prolog (forgetting)
I've really done a lot in Prolog, being first exposed in the second semester to it. I remember to marvel at some guys who grokked the language at first usage in the initial course -- to me, having used only imperative languages up to then, it was a mistery. I still think Richard A.O'Keefe's book "The Craft of Prolog" is among the best CS books.
- C/C++ (forgetting)
About 1992, I somehow got interested in object-oriented programming. Free software was still unknown to me, so I bought a student edition of Turbo C++ and some Addison-Wesley book and of I went inventing another wheel. At the time, I also had to do some C hacking for some course at the university, involving MS Windows programming. I've used C over time in several smaller projects, but would never call myself a C hacker.
- Assembler (forgotten)
My first exposure to Assembler was with some book for the C64. I was very interested but understood next to nothing. I should program some I/O chip directly instead of just using "load $,8,1"? WTF? Next look was in University, of course. I still know enough bits to be able to grok more or less the output of (disassemble 'foo) of some (tiny) foo-function in CL on an i386-style machine, but that's about it.
- Mercury (had interest in)
Mercury seemed like a nice successor to Prolog, adding several features of functional languages. I read several manuals, had several installations and never used it for anything.
- Life (had interest in)
Another possible successor to Prolog, which I've learned about at a summer school for language, logics and information. That's about all I remember.
- XLisp (forgotten)
My first exposure to Lisp in the context of a course for computational linguistics. The only thing worse than the editor used in the system was the tutor giving the course. A horror of parenthesis is about the only thing I remember.
- Shell scripting (daily usage)
I think since 1992 or 93 I've been using Unix systems and shell scripts. I no longer can remember whether our Suns dumped you into csh or sh or whatever, but since I've been using Linux systems (since 94), I've been using bash and written bourne shell scripts. Of course, I've also written the occasional csh script abdomination, but "Csh programming considered harmful" was an early lecture.
- Emacs Lisp (forgetting)
I remember seeing one of my instructors doing nearly miracles with XEmacs and wondering how his fingers could be that flexible -- I know that now.  I've written several small utilities in Elisp and keep using it occasionally.
- Common Lisp (improving)
When I started a student job in 1995, I also started using Common Lisp, using Steele's CLtL2. Having used Elisp before, I no longer was worried about parenthesis. I still keep finding areas I didn't know or used before. And it's a language large enough that keeps you re-learning tricks you thought you knew. Which didn't stop me from giving a course on CL, which in hindsight didn't have the right focus: instead of showing that CL is just as capable of doing whatever you expect, it's also capable of doing you won't expect.
- Smalltalk (interested)
At the computational linguistics lab in Freiburg, the parser system was implemented in Smalltalk, so when I started there I took a small course in Smalltalk. As I worked more on the knowledge representation side of the system, I only rarely used it, though, so rare indeed, that I never got to do anything serious with the language. I still can read Smalltalk despite it's somewhat unusal syntax and have to do that even sometime.
- Tcl (forgotten)
We wanted to extend a linguistic annotation written in Tcl, so I bought a book and started digging through the code. Soon enough a student took over the job (and did it rather well), so I started the tiny bits I've learned quite soon. I remember finding the concept that every thing is a string to be rather messy and still see it as a lame excuse for dynamic/weak typing.
- Perl (static)
For nearly ten years, I had been using shell and/or Emacs to solve any data mangling tasks when I finally gave in and had a closer look at Perl. I still find it amazing how quick and dirty it's possible to solve problems in Perl, but on the other hand I've given up Perl for more complex tasks that require some thought and design, since Perl's syntax and language idiosyncrasies keep leading me to programs I don't even like myself.
- XSLT (improving)
At about the same time I started using Perl, I also needed to transform a set of XML documents and XSLT was all over the media, so I had a closer look. I dislike the noisy syntax of XSLT and particular the intermix with output elements and it's fever for being a "clean" functional language. But the concept of XPath and the idea of traversing a document via axis I find very compelling.
- make (static)
For a long time the power of make didn't occur to me. A colleague of mine, however, used it to implement a nifty workflow for document processing, of which I learned a lot of tricks when I needed to mimic it for a different task.
- Ruby (improving)
When I finally was fed up with Perl, I looked around to find Ruby as a nice halfway compromise between Common Lisp and Perl. It's still fancy and geeky and with Ruby on Rails has a lot of buisness ballyhoo around it, so I hope it will see more use in my current surrounding.
- Java (not interested)
Like everybody else, I couldn't avoid looking at Java. It seems to be the Cobol of today and as such is the job guarantee today. But Java looks so boring, I can hardly stand it. And this with regard to both the language and the results produced with it. Sigh But still, it's likely that someday I'll going to buy another book (that would be my third Java book, the first being O'Reilly's Java in a nutshell for Java 1.1 in maybe 1997 or so?), since just like Cobol at it's time, avoiding Java is hard ...
- Python (not interested)
When Python 1.4 hit the scene, there was quite some bubble around it. It burst quickly and as my latest review of the language reveiled last year, it still doesn't seem interesting.
Missing in this list is stuff like Scheme, Dylan, Oz, Oberon, Eiffel, Haskell and probably some other "tiny" languages which I looked at at some point in time and really didn't ever took a second look. Of those, I may take another look at Haskell in the future, but currently I have no concrete plans in doing so.
Posted by Holger Schauer in
Linux
Tuesday, May 22. 2007
Etch ships with drivers for the Ralink RT2570 wifi/wlan chipset in the package rt2570-source. However, for whatever reason, if I try to use that package (i.e. compile it the usual Debian way via make-kpkg modules-image and install the resulting deb), modprobe rt2570, I only see that the usb subsystem sees the adapter but I get no interface (rausb0). I then just recompiled my local CVS copy from last summer, modprobe/insmod it and everything is fine. Huh?
Update: I updated to 2.6.21.1 today, using a fresh vanilla kernel. Still Debians module compiles flawlessly, can be installed and the module installed, but no working interface shows up. Manual compiling/installing the old CVS version (probably by a month younger) works out of the box.
Posted by Holger Schauer in
Linux
Saturday, May 12. 2007
In my workstation I still operate a Matrox G400 back from 1999. It was a state of the art graphics card for its time, and especially well supported under Linux/XFree86. Well, time went on and now everybody's using X.org. Since two days ago, my workstation joined the club, finally having been updated to etch. And then I find a discussion in the Usenet group de.comp.os.unix.linux.hardware with somebody complaining about a freezing system with X.org/mga when switching to the framebuffer console. And of course, I can easily reproduce it: Switching back to X immediately hang the system. Suspend to disk hangs up the system, too. Great.
A little bit of searching quickly revealed this horrible list of bugs for xserver-xorg-video-mga in Debian, from which one bug in particular links to this upstream bug entry. See the date of the last change to this bug? It's almost three years old! I am now trying with "UseFBDev" set to "false" and at least I could switch three times back and forth, but we will see.
Posted by Holger Schauer in
Linux
Friday, May 11. 2007
Since over a month, I have a Debian Etch DVD lying around. Last night, I finally finished backing up any valuable data and started the upgrade, closely following the careful upgrade instructions given in the release notes. This worked quite well, some minor glitches have happened, though. For instance, wmsensors and wmwifi were removed, although at last wmsensors is included in etch; I haven't checked wmwifi yet. Then my mouse stopped working. Turned out, I never updated gpm.conf from my old serial mouseman configuration to the newer usb mouse I have since quite some time. This was easy to fix, though. Finally, the installation of iceweasel aka Firefox 2.0 resulted in the loss of two of my favourite extensions: SurfKeys, which for instance allows to move between tabs with "o" and "u" and Reveal, which shows mini views of the contents of other tabs. I can live without Reveal but I'm going to look for a replacement for SurfKeys (yes, I use hit-a-hint and keyconfig, but I don't know how I can configure moving between tabs). There is probably more that needs fixing, but nothing spectacular so far.
Update: The surfkeys problem can be solved (see this discussion).
Posted by Holger Schauer in
Linux
Tuesday, April 17. 2007
Today, I've been bitten by this bug in apt-get -- running apt-get update/upgrade or any other application depending on apt, like, e.g. aptitude or apt-cache would simply segfault. This is the first time in roughly ten years use of Debian that I encountered a bug in one of the major administrative tools. I'm not sure I should be happy that it took so long or unhappy because it happened today. Anyway, the bug report (actually, I think there are probably two bugs lurking, the segfault I encountered is the same as the second backtrace) contained the required information to work around it: (re)move /var/cache/apt/*.bin and everything worked again. Strange.
Posted by Holger Schauer in
Linux
Monday, April 9. 2007
Back from the usual familiy visit for Easter, I discovered that the rabbit had a very special egg for the open source community: Etch(aka Debian 4.0) has been released. So, while I wanted to do some running in the afternoon, my server is going to do something for his fitness ...
Posted by Holger Schauer in
Lisp
Wednesday, April 4. 2007
Reading Bill Clementson's blog pointed me to Edi Weitz new STARTER-PACK Lisp package, which tries to overcome one of Common Lisp perceived entry level problems for newcomers, when compared to e.g. Python. Python is known to come with "batteries included" which actually means that you'll have lots of libraries for everyday problems installed out of the box. For Common Lisp, not much has been accomplished in this area, as most people still seem to be debating on comp.lang.lisp about standarization. Edi's starter pack instead does the right thing: It provides a simple selection of common packages, some of which could be called to have achieved de-facto standard level (e.g. his own CL-PPCRE package). Unfortunately, it's for Windows and Lispworks only, which Bill ported to Mac/LW.
Being a Debian user since many years (should be roughly ten years now), I think that it would be fairly simple to achieve something similar (but not at all comparable) to STARTER-PACK. There are already a lot of Common Lisp packages in Debian, what's missing, however, is a CL-TASK package. Such a package could do what all other task-* packages do in Debian: Have dependencies on the most common packages. This would provide at least a starting point for the newbies with CL in Debian. I think, I'm going to discuss this with Peter van Eynde via mail and also on cll.
Posted by Holger Schauer in
Linux
Monday, April 2. 2007
Dear Lazyweb: Are there any good tutorials on turning a running native Windows installation into a Xen instance (i.e. without a fresh installation)? Preferably on an Ubuntu (edgy) host? Alternatively, Debian etch would also be an option, though I don't believe the OS of the host system matters much. Yes, I know, I need paravirtualization for that, but apart from that I know next to nothing about Xen, so all up-to-date tutorials on Xen are welcome, too.
Posted by Holger Schauer in
Linux
Wednesday, March 14. 2007
The other issue is that I never got hibernation working on the server and I fixed that today, too. I use a vanilla kernel.org self-compiled kernel on the box, so I could have gone for Suspend2, but as I have sysfs_power_state working on my Ubuntu laptop without much hassle, I wondered what was the problem on the server. As it turned out, suspend to ram (mem) doesn't seem to work and as that always had failed, I think I never really tried suspend to disk. Additionally, I hadn't added a resume line to my grub configuration, so it wouldn't have worked anyway. After a freeze in NetworkStop on my first try with suspend to disk, I added the rt2570 module to the list of blacklisted modules and now suspend to disk (and resume, of course) works. Yay! I'll be able to continue my hacking on UCW without having to boot it all the time, for instance. Here is what is actually doing the work from the config file:
[root@bauhaus->root]grep -v '#' /etc/hibernate/hibernate.conf | sed '/^$/d'
UseSysfsPowerState disk
PowerdownMethod shutdown
Verbosity 1
LogFile /var/log/hibernate.log
LogVerbosity 1
Distribution debian
SaveClock restore-only
UnmountFSTypes smbfs nfs
UnloadBlacklistedModules yes
LoadModules auto
DownInterfaces rausb0 eth0
UpInterfaces auto
XStatus x
XSuspendText Preparing to suspend...
XResumeText Resuming from suspend...
Posted by Holger Schauer in
Linux
Wednesday, March 14. 2007
I finally fixed a very annoying bug in the network setup. Bauhaus is connected via an USB wlan stick by Conceptronic, which has a Ralink chipset (rt2570). I made that thing work quite some time ago, although the (legacy) module from
rt2x00.serialmonkey.com required a small patch at the time.
What I couldn't fix though was a very annoying behaviour of the driver: It wouldn't connect on the first try. Only if I re-started /etc/init.d/network, the server would connect to my AP. I had figured out that the driver required the interface to be upped before you would be able to set ESSID etc., but I couldn't get it to work with Debians ifupdown scheme. Some days ago, somebody in de.comp.os.unix.linux.misc posted his configuration and he had a pre-up ifconfig rausb0 two times, so that makes three times the interface gets upped. This actually did the trick. I now have the following in my /etc/network/interfaces:
# The wlan interface
auto rausb0
iface rausb0 inet dhcp
pre-up ifconfig rausb0 up
pre-up iwconfig rausb0 essid XXXXX
pre-up iwconfig rausb0 channel 10
pre-up sleep 3
pre-up ifconfig rausb0 up
pre-up iwpriv rausb0 enc 3
pre-up iwpriv rausb0 auth 3
pre-up iwpriv rausb0 wpapsk XXXXX
pre-up sleep 3
post-up /etc/network/if-post-up.d/bauhaus.fw
And this finally allows to connect the damned thing at boot time, which is nice for two reasons: It speeds up my boot process (before dhclient would fail after an awful lot of time) and my clock will be much more precise. Now the next thing would be to try the new implementation of the driver, aka rt2x00, and go for WPA2 (which the current legacy driver is not capable of). I'll leave that for another day, though.
Posted by Holger Schauer in
German
Monday, February 12. 2007
In BaWü gibt es seit einiger Zeit die glorreiche Idee, dass die Schüler, die im sog. Rheingraben in der Nähe (30km) zu Frankreich wohnen, ab dem nächstem Schuljahr an den Gymnasien in den fünften Klassen mit Französisch statt mit Englisch beginnen. Während die Idee auf den ersten Blick ja ganz vernünftig klingt (es ist durchaus hilfreich, wenn man die Sprache seines Nachbarn versteht), bringt sie auf den zweiten Blick eine Menge Probleme. Eine Webseite der Jungen Union (!) www.region-fuer-englisch.de listet einige davon auf (Danke, Kris). Am heftigsten sind m.E. nach folgende zwei Punkte: 1) Der Wechsel von Realschule auf das Gymnasium wird damit fast unmöglich gemacht. 2) Bei einem Umzug aus dem Rheingraben in eine andere Region hat man augenblicklich eine miese Note in Englisch. Und das, obwohl gleichzeitig überall mehr Durchlässigkeit zwischen den Schulsystemen und auch Flexibilität bzgl. der eigenen Lebenssituation gefordert wird. Liebe Politiker, wenn ihr schon das Verständnis zwischen den Ländern fördern wollt, solltet Ihr dafür nicht das Verständnis zwischen den Schülern im eigenen Land vergessen.
|
