I keep wondering why people keep writing HUB, WEB and SPAM, where the correct technical terms are Hub, Web and Spam. Neither of the three expressions is an acronym.
Well, SPAM is, but Spiced Pork and Ham is a Trademark of Hormel Industries, and they ask people not to use their trademark to talk about Unsolicited Commercial/Bulk E-Mail on the Internet. They do, however, allow the expression Spam to be used for UCE/UBE.
Any idea why people keep treating Hub and Web as an acronym? It disturbes my reading tremendously.
For nearly two years, I have been pondering about a good and failure-resilient DNS setup to implement for my own domains. In the last days, I have set the first prototype into use.
No, I haven't dared to touch zugschlus.de, my most important domain, yet. This is planned for the weekend. So, if you experience difficulties in accessing any of my Internet services, please inform me and allow me to fix the issue.
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.
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.
Given a simple, switched LAN with Debian Linux (sid, iputils-ping) and Microsoft Windows XP (Service Pack 2, with the Windows Firewall disabled). A user complains about the network being slow (meaning his Windows notebook). I quickly find out that I can ping the box from my Linux notebook if my -s parameter is < 1393 or > 1472. If it's between 1393 and 1472, no replies are received.
I spend the next hour with debugging this not so interesting phenomenon.
While evaluating Gallery, I noticed that my test web server generates wrong links inside the web application. After getting some help on the Gallery Forum, I was told that this was because my setup was miscreating REQUEST_URI to contain the entire URI, consisting of scheme, host name and path, while Gallery expects that variable to be only the path portion of the URI.
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?
wtf? 10.101.2.1 is my default gateway (running a recent Linux 2.6 kernel), so it is ok to answer ARP requests. 10.202.202.254 is bound on the same box, but on a different interface, so I don't think it is ok to answer ARP requests for that IP address on "my" interface, as it confuses some "what network segment am I on today" mechanisms.
Is there some /proc setting where I can disable this rather generous ARP behavior?
