Dear Lazyweb, in late 2001, I bought a shiny new computer to replace my VHS VCR and to finally help me in getting my last 200 hours worth of music form analog audio tapes into the digital domain. I have to admit that I have failed to do this.
While the TV ambitions were originally spoiled with the rotten Windows TV software that came with the Hauppauge PVR PCI card, audio with windows used to work rather decently. Until I decided to ditch Windows and to use Linux. Which looks like a mistake. Not even the audio stuff works any more.
I have bought a new TV card and a new sound card, but all I currently get (with the old sound card, btw) are audio recordings that sound way too fast.
I recently had an issue where a remote host would frequently run out of memory after a number of processes had been invoked from remote. I looked in the wrong direction first, but finally found out that each process invocation leaves two sshd processes hanging around, which are eventually exhausting the memory on the box.
Next step was finding out what happened for the sshd processes not to properly terminate. Eventually, I remembered that the incoming ssh connections were not invoked directly, but via a third host with "proxycommand ssh other-host socket %h %p". Looking on other-host quickly showed a number of socket processes being around, and killing them made the sshds on the low-memory host vanish as well.
Short-term remedy was therefore to set ClientAliveInterval in the low-memory host's sshd configuration.
I then searched for reasons why ClientAliveInterval is not set by default at least in Debian's sshd configuration. I didn't find a reason and proceeded to file a wishlist bug request againnst openesh-server for this option to be set by default.
Before filing this bug, I routinely visited the BTS, just to find out that the bug was already filed. By me. One year and 285 days ago. And that the openssh maintainer(s) didn't even bother to reply to it yet.
Guys, _this_ is a textbook example how to discourage people from filing Bugs against your packages. Please, give them at least the appreciation of a short ACK if you don't get around to fixing the bugs in reasonably short time. Having a bug rot away uncommented and unfixed in the BTS for two years is simpy not acceptable. Yes, that goes even for a wishlist bug.
One thing I wish for exim is a patch for Exim Bugzilla Issue #66, which will incidentally fix Debian Bug #244724, which has become a recurring issue in various complex ISP configuration schemes.
A patch solving this would add an option to an SMTP transport which allows the transport to set the authentication credentials instead of the authenticator. The transport still knows the host name given to it and can look up the right authentication credentials, while the authenticator only knows the IP address that we are connected to and thus needs to rely on reverse DNS information to look up the credentials. Which leads to numerous kinds of confusion regarding CNAMEs and broken reverse DNS on the ISP side.
So, please dear Santa, give me a patch for that. It shouldn't be too hard to do.
Yesterday, Philip Hazel released exim 4.64. I have just uploaded the packages to Debian experimental. If you want to try the lastest and finest exim, please check out the packages.
Unfortunately, the release is too late for etch. Debian etch will release with exim 4.63. I mean, unless the release team decides to bend their rules very badly, which I really do not assume.
Andreas, I am not a nice guy. I am only lazy. If the change to exim4 (it now displays a debconf note to everybody who tries do dpkg-reconfigure exim4, -base or a daemon package telling them to dpkg-reconfigure exim4-config) saves #debian from answering the question "how do I reconfigure exim4, dpkg-reconfigure exim4 does nothing!" twice a day, it is a good change.
I basically agree with you that people who not read the minimum basics of documentation are a nuisance, but they're unfortunately real. You need to hurl the docs into their faces. And even then they're going to ignore them and google for answers instead. And on google, they're going to find wrong or outdated docs.
If you are putting an URL containing brackets in the section title of an .ini-like formatted file, you'd better use percent notation for the brackets in the URL.
Sorry for yesterday's Planet flood. I hope it will be less painful this time.
To keep non-Debian-related articles from showing up on Planet Debian, my blog used to have a Debian-English category which was subscribed to Planet Debian. This also meant that only English-Language, and Debian-related articles showed up there which made my kind of an irregular contributor. I'm going to change this.
Recent Serendipity have the possibility to free-tag articles and generate RSS-Feeds for these tags. After using tags for a few weeks, I am now reasonably comfortable to put them to real use. A new tag planet-debian will be generated and subscribed to Planet Debian. And then I'm going to tag articles that I decide to put up to Planet Debian with this tag.
To avoid old articles from showing up again, I'll refrain from tagging them planet-debian.
This also means that the "Debian-English" category is going to disappear and to be replaced by "Debian" (or even other categories). An additional tag "english" is going to appear on english language articles. So you can now choose whether you want to read only my english articles.
btw, what's the stance of Planet Debian about non-Debian articles and/or native language (in my case: German) on the Planet?
The host hosting blog.zugschlus.de, ivanova.notwork.de, was down due to a network failure in the hoster's network for a few minutes today around 2 pm CEST.
After returning, I found a lot of my syndicated articles anew on Planet Debian, known as the "flood" phenomenon. Is it possible that the Planet software does react in a non-graceful way when an RSS feed cannot be pulled?
Aside from the abysmally slow performance, the dependency on out-of-tree, non-free modules has been cause of grief since it has almost constantly forced me to keep an outdated kernel version around just in case that I would need the modem.
Fortunately, _this_ is over now since more recent kernel versions (I suspect somewhere in the 2.6.16 era) support my winmodem natively without out-of-tree modules. All I need to get only on a POTS line is sl-modem-daemon, which is reasonably painless.
Letztes Wochenende war ich auf dem d.t.r.-Treffen in Röhrenspring im schönen Sauerland. Abgesehen davon, dass an dieser Location kein Mobilfunknetz verfügbar war, empfand ich das lange Wochenende als wunderschön.
Traditionell wird auf dtr-Parties ein Partylog geschrieben. Was ursprünglich ein Notebook mit offenem Editor war, ist inzwischen eine von Stefan geschriebene kleine PHP-Anwendung, die den Inhalt einer TEXTAREA direkt in ein Textfile schreibt - was einmal geschrieben ist, kann nicht mehr geändert werden.
Da Stefan diesmal erst später dazustößt, habe ich mir ein paar Gedanken gemacht und ein Notebook vorbereitet, das als Partylog dienen soll. Dabei hatte ich die Idee, aus dem Partylog ein Partyblog zu machen, und habe s9y eingesetzt.
Die Idee finde ich immer noch klasse, aber sie wurde nicht akzeptiert.
My notebook is an hp compaq nc8000 running Debian unstable, and I'd like to know whether it is "already" possible to use software suspend (hibernation). To my knowledge, there is a lot of different ways to do suspension, all of them differently broken and/or incompatible.
I't like to run with an unpatched vanilla kernel, use suspend-to-ram and suspend-to-disk according to my choice at suspend time, and have the notebook wake up with the X session unhampered and the important hardware (sound, synaptics) still useable. Additional bonus points if wireless and/or wired network remains useable and USB/PCMCIA devices don't need an unplug/plug cycle.
Which solutions should I investigate, which web pages should I read?
The last days, Debian suffered a bug in the reportbug package which made it fail in postinst. This bug was promptly fixed, but reported like THIRTEEN times as a bug in the BTS. If I were reportbug maintainer, I'd have gone ballistic at this ignorance of bug reporters.
Guys, all of you who have reported this bug are running Debian unstable, an unreleased development version of your distribution. Is it asking too much to follow basic etiquette to look in the BTS whether a fatal bug might already been reported? I mean, THIRTEEN nearly identical reports?
I am wondering whether it is currently possible to run a personal laptop with Debian unstable and some init scheme that allows parallel startup of the services. Naturally, it would be very good to start the X server early to be able to log in faster.
Is this concept ready for testing and use? Which packages should I investigate? Any URLs that might be enlightning?
The new wpa_supplicant packages have removed the /etc/wpa_supplicant.conf file. Wireless LAN is now configured via special commands from /etc/network/interfaces, which looks like an elegant Debian way to do things.
While setting this up, I have learned the following:
an ESSID starting with "+" is not accepted
You don't enter the passphrase verbatim into /e/n/i, you use wpa_passphrase to hash it
wpa_supplicant debugs surprisingly well
Well done, maintainers! Thanks!
Next time I'll figure out how to configure wpa_supplicant to automatically associate to the correct wireless LAN regardless of location
