2012-12-05 More than two months without an entry -- no, I'm not dead ... yet. Just, I haven't had much time for computer work lately. And if I did work on the machine, I haven't written that down, until today. Therefore, this is a look back onto the last two months. Francois asked me for permission to translate my essay ``Why the Unix Philosophy still matters'' [0] in French. Of course, I hap- pily agreed. The result is online. [1] That's great! Thanks a lot. He wants to interview me as well. I'm curious for that. The recordings of my ``mmh'' talk at GPN12 were nearly lost. Be- cause the settings of the recording system were wrong, the record was unusable. Luckily, Boris Kraut had dumped the live stream (which went through a different system). I've cut the recording and put it online. [2] [3] To cut it, I used avidemux. For recoding, I've tried with men- coder and ffmpeg. My shell history tells me that I've used these commands: mencoder -oac copy -ovc copy -ss 1:04:15 -endpos 1:58:25 -o out.avi in.dump ffmpeg -vcodec copy -acodec copy -ss 1:04:15 -t 0:54:10 -i in.dump out.ogv ffmpeg -vn -acodec copy -ss 1:04:15 -t 0:54:10 -i in.dump file.ogg ffmpeg -i file.ogg file.mp3 I think ffmpeg was more successful than mencoder, but I'm not sure. Now some curiosity, which took me an hour to understand. If you redirect the output of some command line, you do it this way: foo -a > x Almost always, I omit the space after the angle bracket: foo -a >x Sometimes, I also omit the space before the angle bracket: foo -a>x This is possible because the shell recognizes the angle bracket as special symbol, thus not needing the spaces to tokenize the command line correctly. Let's take a real world example: ... | head -5 >a Omitting unnecessary spaces: ...|head -5>a Everything goes well. But not of you use the newer `-n' option: ...|head -n 5>a I just stumbled over that and couldn't figure out at once, why that happened. With a bit of distance, the reason becomes. Figure it out yourself! Last weekend, I've had a look at my father's system. It's a Debi- an stable with fluxbox and only a small set of programs. I solved some issues that were introduced during upgrades (for in- stance that fbsetbg couldn't find a wallpaper). To his relief, I switched the systeme (for hist account) to German. Yet missing is the transfer of the system partition to the other, newer hard disk. Throughout the last weeks, I came back to the topic of a sane file system layout and the question which kind of Unix to use. More and more I am dissatisfied with the FHS, obviously concen- trating on /usr and sbin. Experimental approaches exist already, but I wonder if it would be possible to change the FS hierarchy independently of the distribution/derivative. Currently, this question focuses on Crux Linux. Would I be able to only modify the ports and then gradually convert the whole system, with the result of an installation medium for the converted system? The point is, on the one hand I am dissatisfied with the current FS hierarchy and want to change it, but on the other hand I don't have much development power and don't want to break compatibility without success. Changing the FS hierarchy requires building your own package system (which mostly defines an distribution). Sure- ly, I've enough other stuff to do. Yet, this brings me to the question of which version of Unix to use. Although I like Crux, I feel that I like to remove the Linux, the kernel, and most GNU parts. Obviously, BSD comes in mind. But BSD has some dark corners as well (binary passwd and legacy encodings, just to name two). Of the BSDs, OpenBSD appears to match my view on software style best. MirOS BSD, an OpenBSD fork, looks most attraktive to me. But none of the options convinces me truly. Nonetheless, currently I feel I should give MirOS BSD a try. (But on which system? I don't want to drop Crux already again.) One more addition to the sane vs. compatible discussion: I'm much annoyed of the double-spacing of fmt(1). I want to get rid of it ... everywhere. Patching the local fmt(1) is a first step, which I want to take. A satisfying global solution is not in sight. Finally, yesterday evening, I did a little bit of C programming after many weeks without. Dennis Herrmann (dhn) pointed me to a problem with attachments in mmh. In the end, it was a problem of the version of file(1) he uses, but the error message was misleading. I ensured a better error message. It wasn't much cod- ing, but hey, it was wonderful! I also fixed the documentation. There is no ``GNU file(1)''. The (almost) one and only implementation of file(1) is Ian Darwin's. [4] Good to know. At the end, some websites I found interesting within the last weeks: [5] [6] And some threads in debianforum.de (in German), which were worthwhile: [7] [8] [9] [0] http://marmaro.de/docs/studium/unix-phil/ [1] http://www.f.0x2501.org/b/008/ [2] http://marmaro.de/docs/gpn/mmh/ [3] https://entropia.de/GPN12:meillo%27s_mail_handler [4] http://www.darwinsys.com/file/ [5] http://www.chiark.greenend.org.uk/~sgtatham/aliases.html [6] http://tos-dr.info/ [7] http://debianforum.de/forum/viewtopic.php?f=29&t=139213 [8] http://debianforum.de/forum/viewtopic.php?f=34&t=139280 [9] http://debianforum.de/forum/viewtopic.php?f=27&t=139444 http://marmaro.de/lue/ markus schnalke