Kernel Traffic
Latest | Archives | People | Topics
Latest | Archives | People | Topics
Latest | Archives | People | Topics
Home | News | RSS Feeds | Mailing Lists | Authors Info | Mirrors | Stalled Traffic

SLUG Pearls #7 For 16 Jul 2000

By Jeff Waugh

Check out the Sydney Linux User Group

Table Of Contents

1. Quickies


People: Jim ClarkAndrew ShiptonConrad ParkerAngus LeesDean HamsteadAnand Kumria

2. I Like Your Old Stuff Better Than Your New Stuff

11 Jul 2000 (14 posts) Archive Link: "Wht the Old Junk in New *nix?"

People: Jeff WaughJamie HonanAngus LeesHerbert XuMatthew Dalton

Jeff Waugh asked:

Disclaimer: Please don't flame the newbie.

With recent discussions about termcaps, etc. I started thinking about the relative obscurity of all these configuration details...

Why do they still exist? How *practically* useful are they anymore?

Is it a case of backwards/cross compatibility, and that no one has the urge or flameproof suit strong enough to come up with new specifications?

Obviously, this is a question coming from someone used to "New" *nix, primarily as a desktop machine or standalone server, and the simplicity that comes from using the average distro (Slackware excluded, yes).

I'm not debating the use of plain text files for configuration, merely the gumpf that's grown over certain areas, and shows little sign of being cut back.

A couple of SLUGgers agreed, citing needless complexity and legacy issues. Matthew Dalton complained specifically about his trouble with some terminals.

Angus Lees commented that distributions should conform to a standard, and hoped that they offered soluions similar to Debian's keyboard policy. Herbert Xu posted a copy of the policy, also mentioning that Debian regards non-conformity to this as a bug.

There were many suggestions as to why the terminal configuration system was useful, including the use of ancient terminals and the 'screen' program. Finally, Jamie Honan gave an interesting rundown of the old terminal systems, and how the current systems came to be:

The thing is, there was no possible way you could encapsulate all terminal / keyboard behaviour in a table.

Here are some examples from the O'Reilly book:

kdl1 = delete line
xenl = newline glitch
ked = clear to end of screen

There are glitch parameters, support for copy, move, redo, resume, next object and select keys. Support for standout, blinking, hidden display characteristics. Any terminal manufacturer could invent any wierd feature.

I even invented one myself. I made a PC terminal emulation that would display, buffer but not transmit normal keystrokes (e.g. A-Z, 0-9) until a special keystroke was entered (e.g. RETURN, TAB or cursor key). Why? Well a server dealing with hundreds of terminals only had to respond once per field instead of each character per field.

But perhaps Jeff is right. Perhaps it's anachronistic to be carrying around a personal museum / shrine to the past glories of terminals.

Perhaps we can keep a VT100 terminfo / termcap 'fooler' for apps that need it. For those who really need to know about the Hazeltine tilde glitch (hz in terminfo and termcap), well you can roll your own.

Nah, lets keep terminfo. The past deserves respect, it contains the keys of the future. Practicality? I'd vote yes.

3. Window Managers and Core Dumps

11 Jul 2000 - 12 Jul 2000 (5 posts) Archive Link:

People: Jeff WaughAngus Lees

After solving his network card troubles, Peter Rundle asked some additional questions about how to start different window managers when starting X, and what core files were used for. Jeff Waugh answered his questions regarding window manager startup:

Are you using xdm or gdm, which make X start when you boot, or do you run startx from the command line?

In each case, you'll want to run your window manager on the last line with exec, eg.

exec lwm

If you want to run any other software on startup, put them before that line, and background them using the ampersand, &.

Whilst Angus Lees gave a quick guide to "How Cool is GDB?"

just because i think core dumps are _way_ underrated:

gdb <executable> <corefile>

at the gdb prompt, type things like "where" to find out where the program crashed.

if the executable has debugging symbols compiled in, you'll get a pretty backtrace (and be able to look at variable values, etc). if it doesn't, then you'll just get assembly and the odd cryptic linker symbol (which may still be useful).

i think its a real shame that core dumps are turned off (the size is limited to 0. see ulimit(1), limit(1) or getrlimit(2)) by default on most linux distros. core dumps are an excellent way of catching those one-in-a-million unreproducible bugs, without slowing your program down with debugging code.

and if you find a stray core file, "file core" will usually be able to tell you what program produced the core dump

4. More Debian: auto-apt

12 Jul 2000 (11 posts) Archive Link: "auto-apt"

People: Fumitoshi UkaiJeff WaughAngus Lees

Angus Lees forwarded the announcement of an interesting new development in Debian's automation capabilities, auto-apt. Summarised by the maintainer, auto-apt "checks file access of programs running within auto-apt environments, and if the program try to access a file of uninstalled package, auto-apt will install the package containing the file, by using apt-get."

Whilst Nick compared auto-apt's functionality to Office 2000's "install-on-demand" feature, other SLUGgers were more devious in their attraction to the idea. Jeff Waugh wondered, "What's one command I could try to invoke that would install the *most* software in one hit? Emacs not allowed. ;)"

Trent Swift listed a few Debian packages with extensive dependencies, notable task-gnome-games, and task-japanese. Jeff Waugh responded:

so if I installed a very basic console woody, and tried running gnome-tetris, I'd end up with a fully configured desktop system? And they wonder why we LOVE Debian?!?

Angus Lees cooked up another dastardly scheme:

the cheating way would be:

lynx -source\
| gunzip | sed -n '33,$s!^\([^[:space:]]*\).*$!/\1!p' | xargs ls

otherwise.. here's a really evil way (if i understand how auto-apt works correctly):

mv /usr/doc /usr/doc.bak
while ls /usr/doc; do
   mv /usr/doc/* /usr/doc.bak
mv /usr/doc.bak /usr/doc

5. SLUGgers Still Capable of Political Debate

12 Jul 2000 - 13 Jul 2000 (24 posts) Archive Link: "name server weirdness"

People: Russell DaviesDanny YeeHerbert XuAngus Lees

Danny Yee asked a quick BIND question, and the list was soon embroiled in arguments about Free Software. Hard to believe? Russell Davies commented that if Danny was using BIND for a caching nameserver, he might want to try dnscache. Danny, who is well-known amongst SLUGgers as a strong proponent of Free Software replied that dnscache wasn't Free. Russell disagreed, "it certainly is free software. I suggest you review your facts." Danny replied:

The are conditions on binary distributions

My understanding (assuming this si the same deal as qmail, etc.) is that these don't cover just anything calling itself djbdns, but anything derived from the same code base.

Russell did not believe this to be the case:

Your understanding is in serious question.


``Free software'' refers to the users' freedom to run, copy, distribute, study, change andimprove the software. More precisely, it refers to four kinds of freedom, for the users of the software:

Dan's software satisfies all these criteria.

If you are complaining that you can't hack this software and release it _under the same name_, then you better remove all that GNU software you have as well.

Herbert Xu - one of SLUG's resident Debian developers - took exception to this point, commenting that Debian would still be using it otherwise.

Crap. If all we had to do was to change the name, then qmail would've been part of Debian ages ago and we wouldn't have spent the huge amount of effort to convert our main server away from qmail. Read this from

If you want to distribute modified versions of qmail (including ports, no matter how minor the changes are) you'll have to get my approval. This does not mean approval of your distribution method, your intentions, your e-mail address, your haircut, or any other irrelevant information. It means a detailed review of the exact package that you want to distribute.

I don't see anything about allowing the distribution of a modified qmail under a different name.

And if you still think this is OK, well just ask yourself what a distributor can do when the next security hole comes along and Dan is not in a position of releasing a patch (on a safari trip, perhaps?).


_next time_ ? There has never been a security hole in any of Dan's software to the best of my knowledge and he regularly offers cash rewards at their release for any found. However, for the sake of argument, let's assume a security hole is found.

In that event, simple -- I'd probably hit where there is a wealth of knoweldge, users and patches. Note in particular 'User-Contributed Software for Qmail'. There is nothing stopping somebody writing a patch that others can obtain and apply to the official source distribution -- a simple patch; make and make install would probably solve the problem. When Dan returns from his hypothetical safari, he would probably decide whether or not to include it in the next release (which are very few and far between I might add).

Your scenario isn't really a big deal.

Herbert commented that, "It's not a problem for an individual with the skills. But for a distribution this is not good enough."

Angues Lees asked, "so does that mean that when a distro (for example: debian) decides they want to patch the source to change a default path, or something - they can't distribute the resultant binaries? (without renaming it to "dnscache-debian" or some other shenanigans)" . To this, Danny Yee commented on further problems with the licensing:

My concern is that it's not even clear that they would be allowed to do the latter - ie, change the binaries *and* the name.

I understand that DJB is a genius and no one should ever want to modify his code or change the way he does things, but I feel that people should do the right thing because they choose to, not because they are compelled to.

And what happens if Bernstein is run over by a bus tomorrow? In the absence of any formal licence covering his code, who knows what the executors of his estate could do.

The debate was continued off-list.

6. Prioritising Network Traffic with 2.2

13 Jul 2000 - 14 Jul 2000 (18 posts) Archive Link: "Priority of network traffic"

People: Joshua MarshallHerbert XuAngus LeesJill RowlingJames Morris

Joshua Marshall asked whether it was possible, "using IPChains or other means, to prioritise network traffic over a link?"

The link is 33k and is easily flooded by people accessing files etc across this link.

I would like to put something on there so that the telnet sessions are given the highest priority, and everything else only allowed to transmit once the telnet packets have been sent out. We can control both ends of the link so priority on transmit at each end would do the trick (I don't think you can put priority on receive, you just get it as it comes - am I correct?)

Any info would be appreciated, we're using kernel 2.2.16

Jill Rowling hoped that by giving the telnet daemon a higher priority than normal, the sessions would be better off. DaZZa pointed out that 'nicing' them would only prioritise the process, not the link.

Herbert Xu offered a number of tips, summarised here:

It should be done automatically with the TOS bit. Though you might have to adjust the txqueuelen paramter of your PPP interface. Of course this is assuming the routers on both ends of your link are Linux or at least prioritise according to the TOS bit.

...if your application does not set the TOS bit correctly, you need to either fix it or use ipchains to rewrite the TOS bit.

If you're using Linux, and haven't enables QoS, then this is the default. The code is in net/sched/sch_generic.c.

[The list of TOS flags can be set are from] /usr/include/linux/ip.h:

#define IPTOS_LOWDELAY 0x10
#define IPTOS_MINCOST 0x02

James Morris suggested the 'Manipulating the Type of Service' section in the IP Chains HOWTO as a good guide to this feature.

Angus Lees strongly recommended that Joshua check out iproute2:

it does all this and is in the 2.2 kernels (you just need the two user-space tools) (apt-get install iproute)

basically, iproute2 (the command is just "ip") does away with ifconfig, route, interface aliases and tunnelling, and is *much* more flexible. addresses are separated from devices, devices from routes, etc. and each can have a list, not just one. tc is the traffic shaping stuff, and you can choose just about any criteria to match traffic, and then about 10 different algorithms for what to do with it.

In addition to the documentation provided with the tools, Angus offered as a good reference.

7. Thank a Hacker

14 Jul 2000 (5 posts) Archive Link: "Add some karma, send a ThankYou"

People: Jamie HonanHoward LoundesKen Yap

Jamie Honan posted a nice Friday morning warm fuzzy for us all:

Thought for the day:

Why not send a thank you email to someone who has written some free software you use and like.

Something simple like: "I use XYZ a lot, just thought you'd like to know".

Or: "I couldn't get by without PQR. Thank You".

You feel good, they feel good, and so on ....

Doesn't take a lot of effort. Do it now.

Howard Loundes joked that yes, it must be Friday, "but in the spirit of Jamie's suggestion, Thanks to Sluggers for answering questions."


Ken Yap agreed, and mentioned that, "Developers would often like to know if you are using their software in some unusual situation. It may even give them ideas for future directions."







Sharon And Joy

Kernel Traffic is grateful to be developed on a computer donated by Professor Greg Benson and Professor Allan Cruse in the Department of Computer Science at the University of San Francisco. This is the same department that invented FlashMob Computing. Kernel Traffic is hosted by the generous folks at All pages on this site are copyright their original authors, and distributed under the terms of the GNU General Public License version 2.0.