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

Debian Traffic #16 For 29 Dec 2000

Editor: Zack Brown

By Prashanth Mundkur  and  Zack Brown

Debian Home Page | Weekly News | Social Contract | Constitution | Policy Manual | Developer's Reference | Documentation Project | debian-devel Archives

Table Of Contents


Want to help write KC Debian? See the KC Authorship page the KC Debian homepage, and the Thread Summary FAQ. Send any questions to the KCDevel mailing list.

Mailing List Stats For This Week

We looked at 621 posts in 2200K.

There were 210 different contributors. 113 posted more than once. 0 posted last week too.

The top posters of the week were:

1. Some Discussion Of Debian Package Namespace Conflict

12 Dec 2000 - 20 Dec 2000 (20 posts) Archive Link: "ITP: water -- A graphical water effect demo."

Summary By Zack Brown

People: Josh HuberMiles BaderHamish Moffatt

Uwe Hermann announced his intention to package 'water', a graphical water effects demo. There were no serious objections, but Josh Huber suggested, "perhaps you should change the name? water seems very generic..." Miles Bader disagreed, and said 'water' seemed like a great name. He added, "It seems very unlikely that there will be other packages competing for the name, and if someday there are, well, they can easily choose others. In cases like this, I think the rule should be `first-come-first-serve.'" This made sense to Josh, but Hamish Moffatt replied to Miles, "I disagree. The policy is to avoid namespace polution, which means that package names should be as specific as possible. Imagine if the first 26 packages were named a through z, just because they could be and they were first come first served?" Miles returned, "there has to be *some* point at which you stop trying to be more specific in a package name, and when a name is unlikely to cause conflict in the future, the maintainer has more freedom in choosing that point. If the program is called `water' then it's perfectly fine to call the package `water'." Hamish was not convinced, and suggested calling the package 'water-demo' or 'waterdemo' or something like that. He checked the output of 'dpkg -l' and saw very few packages with plain english names. Miles saw no significance in that argument, and Hamish explained, "it demonstrates that most people thing plain English names are too generic and therefore not suitable for package names." Miles replied, "it simply illustrates that no one has chosen a `plain English name' for a package."

There was no resolution during the thread.

2. Debian usability vs Mandrake

15 Dec 2000 - 21 Dec 2000 (50 posts) Archive Link: "Latest Mandrake"

Summary By Prashanth Mundkur

People: Eray OzkuralToni MuellerRandolph Chung

Eray Ozkural provided a glowing report on the latest Mandrake beta's usability, gnome/kde configuration and internationalization, and complained about usability features in Debian. He later added that applications like Xemacs had better looking defaults, the draktools on Mandrake made it possible to easily provide dhcp to windows machines without editing any config files and that "I didn't read _any_ documentation to do it."

This sparked discussion that diverged along various avenues. According to Toni Mueller:

I think end-user usability is better in many other Linux distributions. I do, however, value Debian for having a very good package management, a better "standard-conformity" w/o that tendency to really lock people in, and a sense of honestness and quality in general.

On automatic hardware detection and ease of installation, Randolph Chung pointed out:

We have a lot of plans to make the installation system more smooth and better suited for automated installs, etc. But as long as people are just complaining and not actually helping, it's just not going to happen. Debian is a volunteer effort, things don't happen unless someone volunteers to help.

The new installation project is being developed on the debian-boot list, the latest progress report is here, and the announcement of the latest demo system is here.

3. 'testing' distribution available

17 Dec 2000 - 21 Dec 2000 (42 posts) Archive Link: "testing to be implemented on ftp-master"

Summary By Prashanth Mundkur

People: Anthony TownsJosip Rodin

Anthony Towns announced the availability of the testing distribution:

And, days later, we're ready to roll out "testing" too.

For those who haven't been following closely, "testing" is an automated way of keeping a suite (potato, woody, etc) in an essentially releasable state: packages are installable, don't have release critical bugs, and are consistent across all the architectures we're planning on releasing.


What this means is:

  1. if you want to stay on the bleeding edge, point apt at unstable, rather than woody, and you'll stay there.
  2. if you're using an unreleased architecture (hurd-i386, hppa, etc) point apt at unstable (*not* woody), at least until it's ready to be released.
  3. if you want a taste of what the next release will be like, without the risk, you will be able to point apt at testing, or woody. [0]
  4. if you stay pointing at woody, many of the packages you've got installed will remain newer than those that'll be available, until various problems in the packages themselves get worked out

[0] This can only be a taste, though, since atm glibc 2.2 isn't suitable for release yet (since it doesn't build on m68k and arm), which has a flow through effect to most of the last couple of month's package, most notably X 4.

On discovering that the testing distribution would be code-named "sarge" after the release of woody, Josip Rodin contributed these technical details:

characters not used from Toy Story (yet):

  1. The Green Plastic Army Men
  2. Andy (the kid)
  3. Draw (the blackboard), or was it Esck?
  4. Snake
  5. Robot
  6. Scud (Sid's dog)

and additional characters from Toy Story 2, also not yet used:

  1. Jessie (the Yodelling Cowgirl)
  2. Zurg (the Emperor)
  3. Wheezy (the penguin)
  4. Hannah (owner of Jessie)
  5. Stinky Pete the Prospector (the old fat guy)
  6. Mrs. Davis (Andy's Mom)
  7. Sarge
  8. Barbie

4. session managers and window managers

19 Dec 2000 - 22 Dec 2000 (22 posts) Archive Link: "x-session-manager alternative"

Summary By Prashanth Mundkur

People: Joey HessIvan E. Moore IIEric Gillespie, Jr.Branden Robinson

Eric Gillespie, Jr. noted that Branden Robinson will now have /etc/X11/Xsession to try to exec x-session-manager before x-window-manager, thus enforcing the recognition that session-managers and window-managers are two different beasts. However, the user can override these default selections through the use of a custom ~/.xsession script.

Later in the discussion, Joey Hess commented:

I still worry about this x-session-manager thing. It almost feels like we are agreeging with the BS spread by KDE and Gnome about "desktop environments" and all that, instead of good old-fashioned X servers, session managers, window managers, and X clients. Of course, I know we're really not -- Branden is just recognizing that a session manager != a window manager, and is providing infrastructure to reflect that. Then kde/gnome's "desktop environment" perversion is tainting that. But the end result is that debian is going to contine to promote the impression that "desktop environments" are real entities if we do this. <sigh>

This issue wasn't addressed satisfactorily in later discussion.

Elsewhere, while explaining that installing Konqueror does require one to install the KDE session manager, Ivan E. Moore II clarified the dependency structure of the KDE packages:

First off, konqueror only depends on that which it needs to function... it does not depend on kdm or kdebase (which contains the session manager)

It DOES *suggest* kdebase however. It does in fact NOT depend on the KDE session manager. Neither does konsole or any other KDE app that doesn't need it...

Let me also point out there is a big difference between kdebase and kdebase-libs [which is where all the modules live for things like ssl support, and all the nifty things that makes konqueror work] ...most apps do depend on kdebase-libs...but kdebase-libs does not contain any session only contains common libraries and code. This is where all the modules are for things like ssl supprt...kdebase is where the wm and sm is...kdebase is where kicker and kdesktop are...

Stuff in kdebase-libs really (IMO) should be a part of kdelibs...but aren't.

5. Shared Filesystems

19 Dec 2000 - 20 Dec 2000 (10 posts) Archive Link: "/usr/etc"

Summary By Zack Brown

People: Yedidya Bar-davidWichert AkkermanChristopher F. MillerJacob KuntzBernhard R. Link

Yedidya Bar-david asked:

About a year ago, there was a discussion about /usr/etc. It seems (to me, at least) that it stopped without final decisions for or against. Since I am interested in this subject (for practical purpuses - I manage a few 10's of Linux workstations which I intend to convert to debian with a shared /usr), I would like to know whether a decision was made (which I was unable to find in the archive), and if not, why was the discussion stopped (perhaps because the interested participants found other solutions to /usr sharing).

Just my 2 cents - nothing new, others have said this: I think most of the configuration files in a typical workstations site (and I specifically say workstations - things are different with simple XTerminals or with compute clusters) can be shared. I also think it could be nice if the sharing or unsharing of a particular file could be decided by the administrator (at install time of a package, or even as a system policy?). Other solutions have arrived, such as cluster-nfs (look at cluster-nfs at sourceforge - basically it's an NFS server that lets some (few?) files to be different for different client machines/users). Still, I think one of the oldest ideas on which the whole Un*x filesystem hierarchy is based is that of sharing /usr, and it's a waste that this can't practically be done, with any of the Linux distributions I know.

I looked at some of debian's mailing-lists archives, including policy, and found nothing, except the above- mentioned discussion. BTW, I couldn't find archives for the FHS mailing list (to which I am not subscribed (yet?)).

I would like to hear what people think, and whether there is a chance to reintroduce /usr/etc to debian (and fhs).

Wichert Akkerman replied shortly, "Decision is simple: /usr/etc will not happen. Feel free to discuss this on the FHS list which is a more approriate forum for this discussion."

Christopher F. Miller also replied to Yedidya, saying:

Maybe it's just my inability, but I find sharing even /usr/share is a PITA. We do that because we want the docs and man pages everywhere to be the same even though, for example, we don't want a full tex installation on every machine. Booting without /usr/share mounted means bad time: (/etc/localtime) cron and syslog fail. Nor will mysql even start. There was a time when lprng would not start either. The worst part though, is that upgrading just a dozen machines must be done in a certain sequence; we find it best to do the server last. Upgrading more than one machine at a time creates race conditions in /usr/share and lots of small files work the NFS hard. Maybe we are too ambitious: /usr/share/man and /usr/share/doc might do the trick for us.

Jacob Kuntz replied, "that's why the FHS allows for a read-only /usr. i haven't tried running a debian system in that situation, but i'm curious to see how the package tools deal with it. i believe someone posted here about mouning /usr read-only on a server to save fsck time (ie, only his live data areas would need to be checked). one could just mount -o remount,rw /usr before running apt. nfs is a whole 'nother issue, since you can have a situation where /etc/xyzzy.conf is in a different format than /usr/sbin/xyzzy expects. if anyone has a good solution to that problem, i'd love to hear it." And Bernhard R. Link explained, from his own experience, "I have an old slink-box at home with /usr readonly. dpkg just relizes, that it can not write and install nothing, but there was no damage, when I forgot to remount it before installing."

6. NSA's Secure Linux Distribution

22 Dec 2000 - 23 Dec 2000 (9 posts) Archive Link: "NSA's Secure Linux Distribution"

Summary By Zack Brown

People: Brent FulghamMiquel van SmoorenburgJacob KuntzBritton Kerin

Brent Fulgham said:

No doubt most of you have seen the NSA's secure linux posting on Slashdot this morning.

Looking at:

there appears to be several utilities that have been updated to provide enhanced security.

Should we be merging these patches into Debian, assuming they appear to be compatible with our policy, etc.?

Miquel van Smoorenburg replied:

Ofcourse it's not just the utilities - they rely on the special NSA Linux kernel.

Packaging the NSA versions of the utilities is only useful if Debian was also using the NSA Linux kernel.

The NSA Linux kernel is based on 2.2 (while 2.4 is due out soon), it deviates from the standard kernel in a big way, and it is higly experimental.

The kernel people are going to look at the NSA kernel, and might merge the security features in 2.6 or 3.0, then again they might not merge them at all.

So I guess it's not an issue. Unless you want to start a seperate destribution, based on Debian: Debian/GNU/NSA Linux

Elsewhere, Britton Kerin was skeptical about merging the NSA's code without lots of testing. Jacob Kuntz replied, "would the nsa really plop a backdoor in an opensource project, hoping it missed and accepted with the rest of the code? i doubt it. their whole (advertised) motive was to protect against the possibility of Trusted (AIX|Solaris|PalmOS|whatever closed os) going belly up." But he added, "of course i plan on running this monster on a throwaway machine before i make form any real opinions." Britton replied, "things like the weird unexplained DES s-boxes show that NSA is at least not afraid of doing things that are blatantly suspicious. And a lot of insiders there have the attitude that no one outside a project ever really looks closely enough at things to detect problems unless something is noticably broken. With Linux and open source that assumption is probably more wrong than ever before, but still with a grain of truth in it."







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.