Slashdot Mirror

As taken from yet another Kernel Traffic Post:

"the 2.4 kernel's scalability of the most common workloads is limited by hardware (ie. the kernel lets those workloads scale 'down to the metal'). The 2.4 kernel scales quite decently on 8 CPUs. I would be surprised if we had any serious problem at 32 or 64 CPUs. (Linux right now is architecturally limited to 32 CPUs on 32-bit systems and 64 CPUs on 64-bit systems - because we have some per-CPU data structures put into word-size bitfields.)"

There was a discussion, but I thought that it was inconclusive, in as much as there was not universal agreement upon the type of use of kernel headers that you mention.

You can see some of it at kernel traffic. They say:

"This was not the final word, and several people pointed out the while Richard's point might be valid, it still did not change the status of GPLed code. There was no real resolution though... "

Take care,

Daniel

Cool story on your link about the Radio Moscow stuff--but the FBI finding him probably wasn't as hard as it would seem:

1. The letter was probably mailed from a relatively local (30 miles) post office.
2. At the time, there probably weren't a whole heck of a lot of Teletypes within 30 miles of his town. (I don't think that characteristic would have been obfuscated by the thermal copying--in fact, there may not have been many thermal copiers, either.)
3. Simple human interviewing probably led the FBI to the "troublemaker" type.

In other words, I don't think the FBI had to analyze the paper in the envelope, track the manufacturer, find out where the envelopes were sold, etc.

(This sounds like some pranks I've thought of, though mine aren't near as clever.)

Back on topic, the lessons learned would be:

1. Don't use your home machine in any way (compiling, copying, etc.).
2. Don't use a machine anywhere "near" you (geographically or organizationally), or at your school, or employer, or somewhere easily connected to you.
3. If you use a public terminal (direct analogy to the post office here), make sure it's more than 30 miles away :>.

The conclusion was that if you really needed these kinds of tiny
latencies, then the right approach was to use a derivative kernel, but
for the rest of us, it wasn't worth the candle. So I guess hard real-time isn't in the pipeline for 2.5.

Hi!

I've been on one side of the medal (dropped college level education) for 4 years now and the other side of the medal starts to show.

More I work more of the challenge the work proves to be and more I feel the lack of formal (mostly theoretical) education shows. If I gain it in time (self study) then it's OK, if I don't the project goes down the drain faster so fast you cant even say FUBAR. Most of the stuff I learn in this way is exactly the stuff I despised 4 years ago and skipped college because of.

Theoretical knowledge helps nothing or little when confronted with work that involves "hacking" in one form or another. In these cases only experience counts and more you work more you can solve in shorter time.

Once you get past that threshold between discovering how things work to the side that demands declaring how things will work you have to be extraordinary genius (Linus comes to my mind) to survive for extended period of time without making colossal mistakes. Some will hit the barrier sooner some later.

I would personally advise everyone to read recent interview with Brian Kerninghan co-author of the C language and Kernel Traffic #85, topic no. 4.

Forget the traditional route of submitting a bug report and waiting for Linus to accept it... instead, write a quick, half-assed article for ZDnet or Cnet about the major Linux bug/vulnerability you've found, and the resulting controversy will certainly grab the developers attention. I'm sure the now-infamous Mindcraft web benchmarks had something to do with the fact that kernel 2.4 includes a fully revamped, SMP-aware TCP/IP stack.

Seriously, though, Linux does need some sort of central bug repository, and this type of thing was recently address by ESR himself in a linux kernel mailing list post. For Linux to continue as a strong player in the Server OS market, some level of professionalism and organization must be achieved...

IIRC, this is a fairly recurring topic on the linux kernel list. Do a search at any of the searchable archives and I'm sure you'll find the ongoing arguement (last time I checked).

Alternately, for a summary, check out Kernel Traffic.

Doing it completely from user space would probably add so many other variables and variances that the results would be hard to interpret,

The other way to say the same thing is
"Doing it from user space might show that it's not a performance optimization that can be noticed".

He has been an active contributor to (at least) the discussion on the linux-kernel mailing list for the last year or so. Check out his entry in the Kernel Traffic People index.

It's very interesting to watch his interaction with the community, since he came in from a large software house and seem(ed, s) to not "get" the way Linux development works. Some of the discussions he's brought up really seem bizarre in the Linux world (incorporate fsck into the kernel, like w2k, or this little diatribe), but others have led to very positive developments (NTFS help, legal help, ...).

Some times this guy seems like he just doesn't get it, but then again he provides a very active *different* voice in l-k land. And the best part is that due to the nature of the project, people can basically ignore him when he rants and maybe still pick up some useful ideas along the way.

Directly related to this story, I'm not sure how much use an open NW-alike is, but hey, it's a free world.

He has been an active contributor to (at least) the discussion on the linux-kernel mailing list for the last year or so. Check out his entry in the Kernel Traffic People index.

It's very interesting to watch his interaction with the community, since he came in from a large software house and seem(ed, s) to not "get" the way Linux development works. Some of the discussions he's brought up really seem bizarre in the Linux world (incorporate fsck into the kernel, like w2k, or this little diatribe), but others have led to very positive developments (NTFS help, legal help, ...).

Some times this guy seems like he just doesn't get it, but then again he provides a very active *different* voice in l-k land. And the best part is that due to the nature of the project, people can basically ignore him when he rants and maybe still pick up some useful ideas along the way.

Directly related to this story, I'm not sure how much use an open NW-alike is, but hey, it's a free world.

He has been an active contributor to (at least) the discussion on the linux-kernel mailing list for the last year or so. Check out his entry in the Kernel Traffic People index.

It's very interesting to watch his interaction with the community, since he came in from a large software house and seem(ed, s) to not "get" the way Linux development works. Some of the discussions he's brought up really seem bizarre in the Linux world (incorporate fsck into the kernel, like w2k, or this little diatribe), but others have led to very positive developments (NTFS help, legal help, ...).

Some times this guy seems like he just doesn't get it, but then again he provides a very active *different* voice in l-k land. And the best part is that due to the nature of the project, people can basically ignore him when he rants and maybe still pick up some useful ideas along the way.

Directly related to this story, I'm not sure how much use an open NW-alike is, but hey, it's a free world.

He has been an active contributor to (at least) the discussion on the linux-kernel mailing list for the last year or so. Check out his entry in the Kernel Traffic People index.

It's very interesting to watch his interaction with the community, since he came in from a large software house and seem(ed, s) to not "get" the way Linux development works. Some of the discussions he's brought up really seem bizarre in the Linux world (incorporate fsck into the kernel, like w2k, or this little diatribe), but others have led to very positive developments (NTFS help, legal help, ...).

Some times this guy seems like he just doesn't get it, but then again he provides a very active *different* voice in l-k land. And the best part is that due to the nature of the project, people can basically ignore him when he rants and maybe still pick up some useful ideas along the way.

Directly related to this story, I'm not sure how much use an open NW-alike is, but hey, it's a free world.

There are a couple of tidbits from kernel traffic which may be helpful. One is a discussion on Joe Pranevich's DRAFT of his The Wonderful World Of Linux 2.4. The other is the DISCUSSION of the DRAFT of a PROPOSED press release which highlights the big features for when 2.4 comes out.

If you're into finding out things before they are final and are an early adopter, these may be of use to you. They are certainly not finished documents and should not be treated as such. They may contain misleading statements, misunderstandable statements, misunderstood points, mention of features that don't make it, and/or outright lies with the intention of deceit.

There are a couple of tidbits from kernel traffic which may be helpful. One is a discussion on Joe Pranevich's DRAFT of his The Wonderful World Of Linux 2.4. The other is the DISCUSSION of the DRAFT of a PROPOSED press release which highlights the big features for when 2.4 comes out.

If you're into finding out things before they are final and are an early adopter, these may be of use to you. They are certainly not finished documents and should not be treated as such. They may contain misleading statements, misunderstandable statements, misunderstood points, mention of features that don't make it, and/or outright lies with the intention of deceit.

There are a couple of tidbits from kernel traffic which may be helpful. One is a discussion on Joe Pranevich's DRAFT of his The Wonderful World Of Linux 2.4. The other is the DISCUSSION of the DRAFT of a PROPOSED press release which highlights the big features for when 2.4 comes out.

If you're into finding out things before they are final and are an early adopter, these may be of use to you. They are certainly not finished documents and should not be treated as such. They may contain misleading statements, misunderstandable statements, misunderstood points, mention of features that don't make it, and/or outright lies with the intention of deceit.

I think that last statement is untrue. About a month ago, many of the audio engineers you spoke of released an "open letter" to the linux-kernel mailing list. They requested that the average and max latencies be reduced (for exactly the same reasons you mention). They suggested a set of patches created by Ingo Molnar, but not integrated into the main tree. This started a flame war on linux-kernel over the validity of the patches, but the views of Linus were well-stated: he believed that reducing latency was a "serious issue" and considered it very important.

As happens with many such requests/patches, the implementation details were shouted over at length, but most of the kernel hackers seemed to be in agreement that reducing latency was a big concern.

Kernel traffic (what a great resource!) has the thread here.

So what you're saying is we shouldn't upgrade because some programmers (to put it mildy) can't code their way out of a paper bag?

"Remember how much stability problems arised in windows due to the 16-bit compatibility? Ok, so it was not because of the bitness but the insecure memory model."

NT runs 16-bit code in its own separate address space. That's what should've happened in Win9x, and might have happened had MS not been helmed by marketters trying to sell the more expensive NT to businesses (who themselves bought the 9x because it was the "legacy" update to their legacy Win31 machines).

"Still, providing backwards compatibility to 32-bit software is going to happen with separate interfaces (what's the length of an 'int'?^). Have some more DLL Hell?"

It's not AMD's fault that programmers can't be bothered to use proper types and use sanity checking in their programs. AFAIK, NetBSD is the only project written with enough portability discipline to run on a 26-bit processor (one of the ARM family). Using things like "int" and assuming they are 16-bit, 32-bit, or even 64-bit is wrong. There are specific types given with every mature libc that allow you to define exactly how many bits it should be via such defined types as int8_t, int16_t, int32_t, etc.

If you look at this Kernel Traffic, you'll see what assumptions Linux makes about the various bit types.

So before you complain about migration hell, remember that you probably made the choice to run your company on a Windows powered server. If you then can't get support for it 10 years later on newer hardware because the company behind it has decided to sell other things, you have to accept that. Don't try to call foul when the hardware standards advance, but your chosen software does not.

I agree that earlier stuff should be emulated in software, rather than hardware. That's where the Crusoe has an edge -- it can, at the lowest level, emulate several processor families and allow them to communicate using the system memory. A benefit that is only gained by emulating another processor on theirs (which is what those "D00d, c0mp1l3 R4D H4t f0r 17 n471v3" kiddies fail to understand).
---

With that kind of grouping of Linux Power, there's an awful lot of Linux interest in this town - hence, a great deal of interest in running a Symposium (Thanks AH!)... if you want a symposium in your neighborhood, start one up! Can't guarantee that Alan Cox will make it (I got to sit next to him and Telsa during Miguel's keynote speech... I think I absorbed some kernel-kung-fu via osmosis)... but you never know what might come of your attempt. Maybe a few attendees will create the next great OpenSource project...

Choose Linux and you could go with a support company like us or LinuXcare. We'll take care of the whole kit and caboodle.

AIX is a good os, though I have never personally liked it. As for stability, it's pretty solid. My main complaint (among others) is that I have to add a ton of stuff to make it useful (and I'm not talking about GUI stuff) like vim, bash etc. I also very much dislike the way command history is the same for all shell windows. I guess I'm just spoiled on Linux...

Also, for web stuff, there's no getting around 100 1u Linux servers behind an f5 load balancer. Save your big iron for your database (until someone figures out how to decently cluster a database).

-Chuck

--
Quantum Linux Laboratories - Accelerating Business with Linux
* Education
* Integration
* Support

All that does is change the exploit from a stack overflow, to a slightly different kind of stack overflow. The bandaid would work at first, but after a few months, all the kiddie exploit tools would work in a new way.

Linus Torvalds (and other kernel designers) have posted exaclty how to defeat a Solar Designer patches kernel as an example. Read the kernel traffic and then realise that this sort of thing is a not a long-term success measure. The programmer must always be careful when designing a program, and no anal-retentive language or kernel-patches can protect you from bad code.
---

I am totally with you. Few PCs have LS120 SuperDisk drives, and not many more have Zip drives. But CD ROM drives are ubiquitous. Carry a single CD with you, drop it in any PC anywhere, and bam, you're running Linux.

Here's their blurb, for those who are interested:

The Bootable Business Card is a complete miniature Linux system on a bootable CD-ROM disc in the size and shape of a business card. It is a bootable mini-CD which should work in almost any PC-compatible machine capable of booting CD-ROMs. Boot our Bootable Business Card and you have 108MB of usable software at your fingertips. It contains a full complement of recovery and rescue software. On the booted system are over 500 diagnostic programs, utilities, and networking clients.

this is pretty much zipslack but now it supports ls120 drives... Ok, if you have one it would be nice, but must people don't. What I find an even better idea is the linuxcare bootable business card. Take a look here. You just burn this iso image to a cd and you have a bootable linux that would work on a lot more machines than an ls120 or even a zip disk because its on a CD! Seeing as this is based off tomsrbt and made for business card size CD's there is plenty of room to add your own extras if you arent new to linux. I am thinking about adding soundcard support and throwing some mp3 files on it ;-)

_joshua_

There are numerous uncomplimentary posts about Gentus on kernel traffic . It seems that they've been accused of GPL violations.

Let's see: Memepool and RobotWisdom spring to mind... Also ArsTechnica, Kuro5hin and KernelTraffic (which isn't only about the kernel; the Samba summaries are also very good).

There was a huge discussion on the Linux Kernel mailing list in the last few weeks about how best to do floppy handling.

Replying to myself:

The discussion on floppy handling begins with this message by Richard Stallman in week 2 of June and continues through the next two weeks. The thread was summarized in Kernel Traffic #73.

Anomalous: inconsistent with or deviating from what is usual, normal, or expected

There was a huge discussion on the Linux Kernel mailing list in the last few weeks about how best to do floppy handling.

Replying to myself:

The discussion on floppy handling begins with this message by Richard Stallman in week 2 of June and continues through the next two weeks. The thread was summarized in Kernel Traffic #73.

Anomalous: inconsistent with or deviating from what is usual, normal, or expected

<Disclaimer>
I work for LinuxCare.
</Disclaimer>

This service is currently being offered by Linuxcare Labs. We currently offer vendor nuetral product certification designed to demonstrate compatibility with the Linux kernel and other major subsystems of a GNU/Linux operating system environment. Working in this capacity I have learned about many of the challenges that come with trying to provide independent validation of Open Source based product.

There are many challenging questions to answer when certifying Linux/Open Source based products. For example, which distribution are tested against by default? How do you treat hardware that is only partially supported, i.e. 3D video acceleration, USB, fire wire, etc. How do you make a hardware vendor understand that the certification of their products depends on external factors over which they have no control, i.e. distribution packaging practices or the ability or willingness of Free Software developers to write a driver? Do you require everything to work "out of the box" or do you allow post installation configuration steps to be taken? For example, many sound cards on the market today won't work after a default installation of most distributions, and require that you download, compile, and install the latest version of ALSA to support the card.

Answering these questions is a constant balancing act between meeting the needs of the product vendor and delivering a true benefit to the consumer. In the end, certification loses its value if strict standards are not adhered to. However, at this point in the game it is difficult to convince a vendor to even consider investing in having their products tested under Linux without making it a very attractive proposition for them. What this usually translates to is going the extra mile to "make" a product work. When Linux compatibility testing is no longer optional for computer product vendors, the burden of finding out and documenting how to support a particular product will be shifted to the product vendor.

Without much whining> that's simply not true. See this and that summary of discussions on linux-kernel.

Without much whining> that's simply not true. See this and that summary of discussions on linux-kernel.

People who follow the kernel threads summary are well aware that this topic shows up there.

For instance look here for an example of Linus apologizing for his behaviour, and then there is Donald Becker's problems. Past complaints have shown up as well.

Unfortunately I cannot right now find the post I was most interested in pointing out that the confrontational atmosphere limits participation by people from different cultures. (Specifically Japan.)

OTOH let me wrap up with my all-time favorite discussion of design philosophy, which happens to (coincidentally?) show Linus' flaming abilities...

In short I think there is an issue. Can it be fixed? Should it be fixed? I don't rightly know...

Cheers,
Ben

People who follow the kernel threads summary are well aware that this topic shows up there.

For instance look here for an example of Linus apologizing for his behaviour, and then there is Donald Becker's problems. Past complaints have shown up as well.

Unfortunately I cannot right now find the post I was most interested in pointing out that the confrontational atmosphere limits participation by people from different cultures. (Specifically Japan.)

OTOH let me wrap up with my all-time favorite discussion of design philosophy, which happens to (coincidentally?) show Linus' flaming abilities...

In short I think there is an issue. Can it be fixed? Should it be fixed? I don't rightly know...

Cheers,
Ben

People who follow the kernel threads summary are well aware that this topic shows up there.

For instance look here for an example of Linus apologizing for his behaviour, and then there is Donald Becker's problems. Past complaints have shown up as well.

Unfortunately I cannot right now find the post I was most interested in pointing out that the confrontational atmosphere limits participation by people from different cultures. (Specifically Japan.)

OTOH let me wrap up with my all-time favorite discussion of design philosophy, which happens to (coincidentally?) show Linus' flaming abilities...

In short I think there is an issue. Can it be fixed? Should it be fixed? I don't rightly know...

Cheers,
Ben

People who follow the kernel threads summary are well aware that this topic shows up there.

For instance look here for an example of Linus apologizing for his behaviour, and then there is Donald Becker's problems. Past complaints have shown up as well.

Unfortunately I cannot right now find the post I was most interested in pointing out that the confrontational atmosphere limits participation by people from different cultures. (Specifically Japan.)

OTOH let me wrap up with my all-time favorite discussion of design philosophy, which happens to (coincidentally?) show Linus' flaming abilities...

In short I think there is an issue. Can it be fixed? Should it be fixed? I don't rightly know...

Cheers,
Ben

One of the things that I've seen being discussed in the Kernel development threads is adding metadata support to Linux.

The nicest idea I've seen is Application Logical Bundles of Data (ALBODs), which look like a tarball if you open(), stat(), etc. them, and look like a directory if you opendir(), readdir(), etc with them. Check out Treating Multiple Files as One for Kernel Traffic's summary of the linux-kernel discussion last year on this topic.

This would allow applications to do the kind of substorage that they need to efficiently; a word processor document may have jpegs, spreadsheet tables, etc. embedded into it; things that can be more efficiently stored and manipulated as a directory full of files than as a single file. However, people don't want to manage a directory for each document, they want to manage a file. So, only new applications (or wily users; imagine being able to copy the images out of a document with "cp my.doc/*.jpg ~") that know to expect an albod actually try treating it as a directory; old tools that try to treat it as a file just get a file, so "cp my.doc my2.doc" still works without changing cp.

Unfortunately, this wouldn't let you add forks to normal files, and in fact adding forks to normal files seems impossible without breaking POSIX semantics and rewriting a bunch of old programs. You got it exactly right: "cp", "tar", "ftp", "apache", and a billion other programs act on files by simply doing an open() and read or mmap on the file. If we provide metadata at the end of that reading, then it gets copied correctly, but the program actually using the file probably breaks. If we don't provide metadata that way, then applications work unchanged, but we need to change all the applications that copy files around. And either way, what happens when you use FTP, scp, HTTP, etc to transfer your file around? Do you send the other end a tarball and leave it to the resource fork aware receiver to handle it ok? It'd be a mess.

your link is broken :(, but i'll try to find it later.

anyway after reading kernel traffic for more than 3-4 months now i have hard time believing that linus will include reiserFS into 2.4 :( (quote from latest kerneltraffic "There is no need to delay reiserfs integration into 2.4 to accomplish a journaling API in 2.5." - Hans Reiser)
it seems to me that lots of kernel developers have some kind of animosity towards reiserFS

you might want to check this article from latest kerneltraffic its about standardizing journalling filesystem.

your link is broken :(, but i'll try to find it later.

anyway after reading kernel traffic for more than 3-4 months now i have hard time believing that linus will include reiserFS into 2.4 :( (quote from latest kerneltraffic "There is no need to delay reiserfs integration into 2.4 to accomplish a journaling API in 2.5." - Hans Reiser)
it seems to me that lots of kernel developers have some kind of animosity towards reiserFS

you might want to check this article from latest kerneltraffic its about standardizing journalling filesystem.

I've bought both from them, but I haven't burned any yet. One of these days I'll have to download the LinuxCare nootable business card iso image and burn it to a business card!

Also, some things put off for 2.6 will help tremendously:

• fully multithreaded TCP/IP stack
• SCSI layer rewrite
• hopefully, a standard journaling filesystem (prolly will be EXT3, but you never know...)

What I would like to see from the BSD community:

• More willingness to cooperate with Linux developers. Cross-licensed drivers like AIC7xxx is just a start.
• A revived awareness that Redhat != Linux (you have NO idea how many "*BSD is better than Linux" articles focus only on Redhat.

I'm sure I've missed lots of things... corrections are obviously welcome.

-l

• Microsoft.com. Search for exact phrase "SAMBA." (include the period)
• Web Workshop - CIFS Products and Vendors
• Samba
• At the bottom of the page select Linuxcare
• then click the Linuxcare logo to go to the US site for Linuxcare
• Under Linux Links select News/Press
• then, finally, Slashdot!

• Microsoft.com. Search for exact phrase "SAMBA." (include the period)
• Web Workshop - CIFS Products and Vendors
• Samba
• At the bottom of the page select Linuxcare
• then click the Linuxcare logo to go to the US site for Linuxcare
• Under Linux Links select News/Press
• then, finally, Slashdot!

• Microsoft.com. Search for exact phrase "SAMBA." (include the period)
• Web Workshop - CIFS Products and Vendors
• Samba
• At the bottom of the page select Linuxcare
• then click the Linuxcare logo to go to the US site for Linuxcare
• Under Linux Links select News/Press
• then, finally, Slashdot!

Err, isn't this the other way around? Since unix clients don't require the extended info, they can authenticate against an nt server just fine, but not the other way around (because they _do_ need the extra info).

You're right, there's a blurb about it here

Very unfair. The term "lie" indicates that I was deliberately misinforming people. That is certainly not true. I was using the term that the people I've seen talk about this Linux feature use. I will admit I have not spent the time to really understand "capabilities" or "privileges".

You are welcome to cite references to your distinction between "privileges" and "capabilities".

A few links:

Pavel's capabilities page

Linux Weekly News listing of Linux capabilities as of 2.2.13.

Secure-programs-how to contains a lot of security related information, including references to the POSIX standards. The POSIX information looks a little dated though.

This link from kernel-traffic indicates that there are several different concepts of what "capabilites" are, and gives some details about what each style consists of.

Let me be clear, I don't know much about capabilities, but I know that they are talked a LOT about on lkml. Simply calling me a liar and saying that it's "privileges" not "caps" doesn't really help educate anyone.

"I'm against using text files because textfiles can be fucked up with typos and duplicate data. A good db like system protects you from making those errors. Using XML would be an improvement over the current situation but also a big misstake in my eyes since XML is just as unsuitable for permanent storage of data as a normal text file."

In that case, are you considering a binary file, or some kind of registry system? If so, check out the rant Linus went into over proc & devfs issues;

"Guys, remember what made UNIX successful, and Plan-9 seductive? The "everything is a file" notion is a powerful notion, and should NOT be dismissed because of some petty issues with people being too lazy to parse a full name.

On a serious note, just because Linus said it doesn't make it universially correct...though he does have a point.

I remember working on an old DOS program where line endings and file endings caused us all sorts of headaches in ASCII files. Till we handled them consistantly, we often ended up with odd problems parsing text configuration files. Once that was done, the headaches went away -- not the creation of some obscure binary file format only our program could touch.

Interbase is an ex-proprietry database solution which is (we hope) becoming open source. It runs under Linux, and Win32. In a recent Linux Care poll it came top of the list of databases for most, if not all areas. It already has a solid userbase including NASA, Boeing, and is even used in the M-1 Abrams Tank.

Granted, the source has not seen the light of day, but 'should' be on its way soon.

Interbase provides a very firm stand point launch the open source development. There is an open source documentation project underway Links :
Interbase Homepage
Developer Initiative site

Incidentally, the portion of the Kernel Traffic discussion where Linus discusses devfs , mentioning thus:

I want the numberic crap to GO AWAY. It's stupid, it's unmaintainable, and I do _not_ want to have the same old "device number" problems in new guises.

A hierarchical name-space with true names is the obviously correct way to name kernel parameters. And doing that any other way than exporting it as a filesystem is stupid and wrong.

Guys, remember what made UNIX successful, and Plan-9 seductive? The "everything is a file" notion is a powerful notion, and should NOT be dismissed because of some petty issues with people being too lazy to parse a full name.

The same is true of ASCII contents. Binary files for configuration data are BAD. This is true for kernel interfaces the same way it is true of interfaces outside the kernel.

I tell you, you don't want the mess of having things like the Windows registry - we want to have dot-files that are ASCII, and readable with a regular editor, that you can do grep's on, and that can be manipulated easily with perl.

This is one of those things that shows that Linus most definitely does have a clue. Further devfs changes will likely have an impact on VFS code, and thus be "injurious" to Alexander Viro. And it looks like there may be some side-effects whereby /proc gets nearly "reimplemented." And I can see the glimmerings of the VFS changes providing the kernel support needed to make managing ACLs and kernel capabilities a whole lot better.

It may take some time, and may not be complete until 2.5, but there is definitely some ongoing Good Stuff getting implemented in the Linux kernel.

Yes, this is a classic "Me too!" comment. Kernel Traffic is wonderful, a godsend to someone like myself who really is interested in what's going on in kernel-land, but can't possibly read 100 messages a day (or whatever) on the mailing list. Anyone else in the same boat (and I'm sure heaps of Slashdotters are) would be mad not to check it out every week.

And, if you're not aware, Kernel Cousins is a collection of "cousins" to Kernel Traffic, for other mailing lists. Currently the Gimp, Wine, Samba and Debian HURD mailing lists are summarised weekly or thereabouts. So if you're interested in the bleeding edge of any of those projects, there's something for you too.

Massive kudos to Zack Brown and the other traffickers for these summaries!!

On Digital UNIX I believe it's possible to make the stack non-executable when a process is running as root. Can this be done in Linux?

No, and this is the topic of seemingly continual discussion on the kernel development list. See http://kt.linuxcare.com/ kernel-traffic/kt20000117_51.epl#1.

Those for a non-executable stack argue it is one more level of protection on the system. Those against it argue the protection is illusionary (it just changes the form the attack takes) so all a non-executable stack adds is kernel bloat. I won't go further into either side here. Please see the aforementioned link for more detail.

All software should be open under a GPL or simpler license.

For the student, geeks and computer sciences that have to actucally work with the source code/software it is 100 times easier if the code is freely (as in speech) avaiable.

For the commerical blood suckers they should fight and make money on terms of good software/support and not on marketing and a huge amount of lawyers.

I am sorry, but I don't see ANY reason that software should be closed. What vaule does closed software have? less than nothing

Just because closed software has the ability to make immoral and unethical money though slezzy business practices, doesn't mean it is right. Business can make money though open source software and services, but the companies will have to work 100 times as hard, and compete based on product/service rather than lawyers/marketing.

Ohh you can see the rant building up in his eyes, lets get out of here, it is about to go off

I'm no kernel hacker, but I guess this has a chance of a snowball in hell to get adapted by the kernel folks.
First, the idea seems old, look at the UDI project.
Looks even cleaner IMO.
And now watch the opinion of several high grade kernel hackers about it.
Two citations:
Dave Miller: "No thanks, IMHO OS neutral driver interfaces are a nice idea but they can only lead to mediocrity. (Yes I have read and understand how your stuff works, the problem will still be there)."
Alan Cox "Not sure why anyone thinks this is Linux relevant 8) - other than it will help to make our drivers even faster than the competition if they adopt it. Have a read, but keep a bucket handy". And after smashing the idea of OS independant drivers a bit more, he really gets funny: "So what are you going to do with it. Joysticks?"

On a quick glance, this thing has even more facts going against it's usage:
The worst:
-It seems to demand applications (not only drivers) to link special headers in order to use their infrastructure.
- It's name (WinDriver)
- This sentence on their webpage:
"Use the powerful graphical Wizard (available in Windows only), to create your driver source code. The Wizard will automatically generate make files for both Linux and Windows."