Slashdot Mirror

You probably already know about it, but there is a very fine digest of the Linux kernel mailing list called Kernel Traffic available at kt.linuxcare.com. Since most documentation tend to fall behind the actual developpement, it might be a good idea to read a few past issue to get you going. I am not a kernel hacker personnally (don't know C), but I still find KT really informative. A really good read.

It's a controversy because there are people on kernel-dev who feel both ways. There are people who believe that we need a journaling fs now, and believe (despite the code inaccuracies) that ReiserFS should go in with an "experimental" tag as a result. If no one on kernel-dev had expressed that, and everyone had agreed wholeheartedly with Linus, /then/ there would be no controversy. But there was, at least some, and has been more in the past. Get over the anti-/. stuff already.
~luge(relevant KT threads are here)

I don't think you can go wrong with ORA's Running Linux, 3rd ed". It covers everything at a intro level. There are also a _ton_ of non book docs on the net. eg: Take a look at Linux Care. Good luck on the class - sounds cool.

Their mailing list is regularly snapshotted. This one is # 17.

Cheers,
Ben

That wouldn't have been a problem if that power didn't come at a huge cost in usability. Unfortunately it dose and vi is simply the hardest thing to use in your typical Linux distribution. Configuring IP forwarding and firewalls is simple. VPN is trivial. Hell even slapping together a lab full of diskless workstations and an SMP server to drive them was all in a nights work.

VI however is hard. In fact I contend that it is the hardest part of any Unix or Linux system. Not just because the keystrokes mean nothing outside of VI but also because it's difficulty is unreasonable considering the simple task it must perform.

As for Mr. Joy I would NEVER contend that he is not an extremely brilliant person and programer. VI is a crappily designed product in my opinion but to the mind of it's creator it was elegant. However the design considerations pale in the face of execution. VI is rock solid, fast and reliable. Simply put every version of VI I have ever seen seems to be well written. Even Vigor works the way it was intended all the time.

I guess the only good thing about VI is that it's being so dammed hard helps to artificially limit the number of Unix admins available at any one time. This increases the earning power of those ( like me ) who have actually taken the time to learn it. Unfortunately NT Netware are more popular than any single version of Unix in large part because MCSEs are a dime a dozen and CNEs are not so hard to find.

You can have their Debian based mini-distro soon, I've found the information on LinuxCare's site, here. At the moment, it doesn't say very much, but it does mention that more information will be provided soon, as well as ISO images, and source code!

They also have a mailing list setup for discussion of the business card. You can subscribe by sending an e-mail to the list request address, with the word 'subscribe' in the body.

This is one cool thing, and I've gotta give props to LinuxCare for this. ;-)

You can have their Debian based mini-distro soon, I've found the information on LinuxCare's site, here. At the moment, it doesn't say very much, but it does mention that more information will be provided soon, as well as ISO images, and source code!

They also have a mailing list setup for discussion of the business card. You can subscribe by sending an e-mail to the list request address, with the word 'subscribe' in the body.

This is one cool thing, and I've gotta give props to LinuxCare for this. ;-)

One problem I had with the CD is that its size and shape makes it prone to "falling through the drive tray" when I use it in one of my SCSI CD-ROM drives. It's just small enough to slide through the slot in the back of the tray if the CD stops spinning at just the right position.

I've been carrying the CD around in my bookbag and using it on campus lab machines. When I need to ssh somewhere, I reboot the machine with the LinuxCare CD in it, run dhcpcd, run the ssh installation script (which pulls a .deb of ssh from a foreign server and installs it on the ramdrive), and ssh as usual.

As for availability, I doubt you'll find these things outside of computer shows. (Why not start a project to create a similar recovery CD?) As for its shape, look at www.shapecd.com for all the weird shapes you can have CDs cut. As for size, it's only slightly taller than a business card but not as wide.

And her e</a>...

Google Bug Hunt
1999/11/17 - 30 (10 posts): Frequent oops in shrink_mmap

David desJardins of Google reported a problem on their cluster. He said:

"Google runs on a cluster of 2000+ Linux/Intel machines. We have a problem on several of those machines, a symptom of which is kernel oops messages in try_to_free_buffers, called from shrink_mmap. (The machines which have these kernel oops messages tend to have poor performance in general, even at times when the oops aren't being generated.)

We are currently running 2.2.7 on these machines, but I see from searching linux-kernel traffic that the problem of kernel oops in shrink_mmap is a long-standing one which has been reported in many different kernel versions, up to at least 2.2.12, and has also been reported in Linux/Alpha. I've looked at all of the past archives, and I didn't see any definitive response to these problems.

The problem is probably related to heavy disk use and/or heavy network traffic and/or heavy parallel processing with threads. These are the circumstances under which we tend to see the problem, and also are circumstances that I see correlated with past reports of this problem.

I have 56 of these oops messages from 10 different machines, all at exactly the same location. I've attached a sample at the end of this note. Most of them look very similar (to each other, and to other oops messages previously posted to this list). But I would be happy to forward all of them to anyone who can use them. I could collect even more if that would be helpful.

It's possible that the problem is associated with or caused by a hardware problem. Out of thousands of machines, we could easily have 10 with some specific problem. But I don't really know what kind of a problem, or why it would manifest itself only in this particular way. Also, the fact that the same problem occurs in Linux/Alpha makes me suspect some sort of software flaw."

Rik van Riel started thinking about where the bug was most likely to be, but Stephen C. Tweedie pointed out that if the oopsing machines also had poor performance in general as David had said, the problem could very well be in the hardware. Analyzing David's code dump, he added, "the immediate problem is that there is a page in the page map which has a page_map->buffers pointer of 0x40000000. That's one bit away from a legal value of zero. That sort of single-bit error is usually a sign of hardware trouble. It's not guaranteed, but that's the best diagnosis just from looking at one dump." He added, "And yes, depending on your usage patterns it is *entirely* plausible for random one-bit memory corruptions to show up in the same place on a number of different machines, if that happens to be where we stress the kernel most. I've seen similar random memory problems on a different machine which repeatably oopsed somewhere else in the buffer cache, but it was definitely a memory fault and only the load pattern caused it to repeat in the same part of the code."

David replied, "I looked at 56 of these oops messages in try_to_free_buffers, from 10 machines. 50 messages (4 machines) have %eax=80000000, and 6 messages (6 machines) have %eax=40000000. Is this consistent with the single-bit memory error, or not?" Andrea Arcangeli and Stephen replied that it was, and Stephen added:

"If there is a design flaw on your motherboards, for example, such that the timing of the outside signals on the bus is borderline, then this is exactly what you would see. In cases like these it is always hard to determine absolutely for sure whether it is hardware or software, but the fact that you see this on only a fixed subset of otherwise identical machines argues strongly for hardware.

There is also the fact that the corruptions are coming from a statically allocated area of memory which is simply never, ever used for kmalloc allocations, and the vast, vast, vast majority of software-triggered memory corruptions are due to accesses to memory which has been allocated dynamically and then freed early. That just doesn't fit the pattern (and I can see no way a corruption to the buffer ring links in a normal buffer head could get propagated back to the static page array without triggering an oops elsewhere).

My bet would still be on hardware."

The thread ended there.

&sign($AC[0]);

An example of a linux bug, her e</a>...

Strace Hole
1999/12/25 - 1999/12/31 (10 posts): strace can lie
Pavel Machek reported:

When you see snippet from strace, that says:

open("/etc/passwd", O_RDONLY) = 3
Do you trust it? You should not. Malicious program could open _any_ file on filesystem with this syscall.

He posted some code to do just that:

void
main(void)
{

char *c = 0x94000000;
open( "/tmp/delme", O_RDWR );
mmap( c, 4096, PROT_READ | PROT_WRITE, MAP_FIXED | MAP_SHARED, 3, 0);
*c = 0;
if (fork()) {

while(1) {

strcpy( c, "/public" );
strcpy( c, "/secret" );

}

} else

while (1)

open( c, 0 );

}
He added:

Depending on races, /public or /secret is printed with strace. This can be reproduced even on UP and easiest way to do so is to make /public file readable, and then look if you get

[pid 224] open("/public", O_RDONLY) = 718
[pid 224] open("/secret", O_RDONLY) = 719
[pid 224] open("/public", O_RDONLY) = 720
snippet like this. It is impossible for kernel to open non-existent file; that means that strace printed something that did not actually happen.

Any ideas how to get rid of this problem? It is nasty. It is very nasty and makes strace unusable for anything security-sensitive.

Mike Coleman replied, "Yes, this is a problem if you're trying to be secure. Anything that allows memory contents to change while a process is stopped is trouble." He suggested some possible solutions, but added, "One subtle problem with eliminating the problem race is that it potentially provides a method for the program to discover that it is being traced ("No races? I must be being traced."). Ideally there would be no way for the program to tell."

&sign($AC[0]);

1. Firstly, it wasn't an "extra $100."

   Dell was likely paying MSFT substantially less than $100 in return for buying a whole pile of copies of Win9x. Likely something more like $50. Or perhaps even less than that for Huge Quantity Discounts as well as Exclusively Installing Win9x So As To Block Out Alternatives.

2. Secondly, some of the amount that more likely resembles $50 is likely going to LinuxCare.

   I'd say the more the merrier.

3. As for the "3 months of tech support," I suggest that you take a look at Red Hat Linux Versions.

   The only thing you get support on is installation support.

   If you bought a system where Linux was preinstalled, then you don't need installation support.

Read the latest edition of Kernel Traffic, there's discussion of the weaknesses of the Linux /proc filesystem. For those of you who don't know, Kernel Traffic is a weekly summary of discussion on the Linux kernel developlement mailing list, and can be accessed at http://kt.linuxcare.com.

See this kernelnotes article as no. It is even possible neither is going to be in at first but it is looking slightly better for ext3.

XFree, being an implementation of an X server, has pretty much nothing to do with OpenGL. There are two limited ways they deal with each other:

• They both draw stuff to the framebuffer, and...
• GL can cooperate with an X server by using the GLX extension to X. GLX basically moderates contention for the graphics hardware between X and GL.

Mesa is an implementation of the OpenGL API. So is SGI's OpenGL® Sample Implementation. In fact, the reason SGI first started calling it "Open" (instead of simply "GL" for "Graphics Library") was because they cleaned up and published the API, then gave people permission to implement it.

As has been posted elsewhere on this thread, SGI is making vague noises about OpenGL and Mesa merging. This would be a wonderful example of how open source licenses actively discourage forking (as discussed in the context of the GPL in Linuxcare back in November).

If you want to know more about the hoary guts of OpenGL, and not just the API, I'd suggest looking up some of Akeley's articles on the hardware from prior SIGGRAPH proceedings.

Both Inventor and Performer are toolkits developed by SGI to run on top of OpenGL and simplify application development. Inventor is targeted more at interactive applications, like modelers (I wrote one in Inventor before it was released in less than five days, having never seen the library before - see Paul Strauss's and Rikk Carey's SIGGRAPH paper). Performer is targeted more at walkthroughs, flight simulators, and the like.

There is no, I repeat no stackguarding technique to completely prevent buffer overflows. Take a look at last week's Kernel Traffic for a summary of a good discussion about this.

Automated library-level checking, whether using a stackguarded compiler or weird stack hacks in the OS is no way to make an app buffer-overflow secure. The only way to do it is continuous human code auditing (and careful initial coding practices), à la OpenBSD. OpenBSD is tight, carefully audited, and in fact provides surprisingly little as far as applications. The size of a typical Linux install is a huge enemy of auditing -- there's just too much stuff to go through. You can however build quite a secure system (assuming you don't have any untrusted local users) simply by strictly limiting which services your machine offers to the outside.

The Internet Worm won't happen again in the UNIX world -- we learned our lesson at the time about poorly written programs and known problems. M$, typically, still hasn't figured this one out. The only reason UNIX users won't be vulnerable to Word Macro-type viruses is that no UNIX user would use such a pathitically stupid application -- and a UNIX user would know better than to execute a random chunk of code he found lying around.

Of course the user can still screw himself if he's dumb, but that's not fundamentally against the UNIX mentality -- 'rm -Rf *' has always been there waiting for you.

...

Actually, a real problem is the fact that most users go looking all over the internet for RPMs of their latest gotta-have applications, without checking the origins. Downloading RPMs from random webpages and installing them as root could be a very bad idea.

Interestingly enough, a heated thread on a related topic cropped up in the kernel-dev mailing list the other week. Check out Kernel Traffic for the details, but basically it had to do with some SGI engineers who wanted to make a change in a threading mechanism to facilitate 3D graphics performance on Linux. Linus explained that he felt their method was, basically, an unmaintainable, inelegant hack that has crept its way into Irix for marketing purposes but will never be in the Linux kernel.

The relevant thing in relation to the IBM article is Linus' discussion of the philosophy of fork() and how strongly committed he is to this model. He's stated quite often, in fact, that this thread scheduling mechanism (which schedules threads as separate processes) is a very intentional part of the kernel design.

Personally, I think this opinion will pretty much have to change over time when people are able to demonstrate very elegant patches for the many-to-many threading model discussed in the IBM article. In fact, if I remember correctly, this is the sort of threading model that TowerJ uses in their native Java compilation system to achieve such great scalability on Linux. You can find plenty of examples of in-process scheduling code if you're interested in checking it out: GNU portable threads is the first one that comes to mind, but almost every Java implementation offers this model as an option (green threads). The method IBM is talking about combines this inter-process tactic with the current, intra-process scheduler.

It just makes sense that if you have 10,000 processes in a queue and you have to recompute goodness for each every time you enter the schedule, this will be a less scalable approach than if you'd created 100 processes with 100 threads each, so that thread_goodness only needs to be computed when that particular process is entered. Think about the management of a large corporation: does the top management allocate resources, set timetables, and otherwise schedule every single employee? No, they schedule a number of departments and projects, then the next level of managers schedules each of the employees within those.

So far, I think this has been much less of an issue not just because Linux hasn't been focused on the enterprise space (where scalability to tens of thousands of threads is crucial), but more because the key server-side applications in Linux (Apache, etc), have been multi-process rather than multithreaded. Now, with the increase in multithreaded apps from Java (say what you will about the language, it makes threading MUCH easier than C) and, for example, the new Apache process models, we'll start to see serious real-world performance benefits for those OSes that have the best thread scalability. Linus, being the bright guy he is, will surely pick up on this make whatever changes are necessary. At least, that's the way I see it working out. --JRZ

"Basically, the gist of his argument is that microkernels aren't any better than monolithic kernels, simply because any tricks you can pull to optimize a microkernel can be applied towards optimizing a monolithic kernel. Microkernels aren't necessarily any more portable than a well-designed monolithic one, and they don't necessarily guarantee better performance. Further, they have some overhead that monolithic kernels can avoid."

He's right. Splitting up a perfectly working kernel in a myriad of tiny things that run in seperate address spaces buys you flexibility, not performance. Microkernels depend quite heavily on message passing via memory regions and other IPC methods. The problem is that (on the x86 PC at least) there is a heavy overhead to the memory reads. In the days when the CPU core can only access its L2 cache on every other, or every third, CPU instruction (K7), it doesn't make sense to play tricks with the MMU and address space. It's great for embeded systems where modularity is important, and memory latencies are not an issue, but a properly designed/architectured monolithic kernel works better on x86 machines.

If you read this Kernel Traffic piece, you'll see that (suprise, suprise!) the DinX framebuffer does not work as well as X's classic system because of the x86 memory bottleneck.

(I quote from the piece)"Just to clarify, performance is currently horrible on PC hardware because we read (memmove) from the framebuffer a lot when dragging windows around. And it seems PC hardware does this really slowly. "
This is because a read requires the data to filter through the main memory bus (100Mhz or 66Mhz), to the L2 cache (same as memory bus on Socket 7, a bit faster for PII/Celeron/K7), and then to the CPU and its L1 cache. So the message reading overhead exists, and is getting exponentially worse as the CPU/L2 Cache/Memory latencies add up. Writes are "fire and forget," and so do not suffer as much because of the latencies.


"I'm sure all of that is well and good, but the fact that the BeOS kernel exists, is a microkernel, and has a performance on par or better than (depending on the situation) the Linux kernel tends to, in my mind, dispute Torvalds' views that microkernels are basically intellectual playthings not worthy of implementation."

Now, if you'd read Linux-Kernel (digest or otherwise) or Kernel Traffic, you'd know that Linus has rejected a patch that removes a lot of the Linux Kernel latency because he says Linux is not competing with the BeOS. This patch does exist, and in this Kernel Traffic piece, we see how it removes the latency you complain about, without recoding the Linux kernel as a microkernel. QED: this proves your assertation based on architecture is flawed and false.

If you think the Linux Kernel's design is so horrible, anyway, you should go work on the GNU/Hurd. It needs more development/developers.

Cogito ergo cogito sum :-)
---

"Basically, the gist of his argument is that microkernels aren't any better than monolithic kernels, simply because any tricks you can pull to optimize a microkernel can be applied towards optimizing a monolithic kernel. Microkernels aren't necessarily any more portable than a well-designed monolithic one, and they don't necessarily guarantee better performance. Further, they have some overhead that monolithic kernels can avoid."

He's right. Splitting up a perfectly working kernel in a myriad of tiny things that run in seperate address spaces buys you flexibility, not performance. Microkernels depend quite heavily on message passing via memory regions and other IPC methods. The problem is that (on the x86 PC at least) there is a heavy overhead to the memory reads. In the days when the CPU core can only access its L2 cache on every other, or every third, CPU instruction (K7), it doesn't make sense to play tricks with the MMU and address space. It's great for embeded systems where modularity is important, and memory latencies are not an issue, but a properly designed/architectured monolithic kernel works better on x86 machines.

If you read this Kernel Traffic piece, you'll see that (suprise, suprise!) the DinX framebuffer does not work as well as X's classic system because of the x86 memory bottleneck.

(I quote from the piece)"Just to clarify, performance is currently horrible on PC hardware because we read (memmove) from the framebuffer a lot when dragging windows around. And it seems PC hardware does this really slowly. "
This is because a read requires the data to filter through the main memory bus (100Mhz or 66Mhz), to the L2 cache (same as memory bus on Socket 7, a bit faster for PII/Celeron/K7), and then to the CPU and its L1 cache. So the message reading overhead exists, and is getting exponentially worse as the CPU/L2 Cache/Memory latencies add up. Writes are "fire and forget," and so do not suffer as much because of the latencies.


"I'm sure all of that is well and good, but the fact that the BeOS kernel exists, is a microkernel, and has a performance on par or better than (depending on the situation) the Linux kernel tends to, in my mind, dispute Torvalds' views that microkernels are basically intellectual playthings not worthy of implementation."

Now, if you'd read Linux-Kernel (digest or otherwise) or Kernel Traffic, you'd know that Linus has rejected a patch that removes a lot of the Linux Kernel latency because he says Linux is not competing with the BeOS. This patch does exist, and in this Kernel Traffic piece, we see how it removes the latency you complain about, without recoding the Linux kernel as a microkernel. QED: this proves your assertation based on architecture is flawed and false.

If you think the Linux Kernel's design is so horrible, anyway, you should go work on the GNU/Hurd. It needs more development/developers.

Cogito ergo cogito sum :-)
---

I am sure there is a lot to learn from those old systems.
(Why some of the VMS guys inflicted Windows NT on us is a different thing :)

That we seem to have lost some features as well and did not progress only, shines through in the hacks and rants of great hackers like Richard Stallmann and Jamie Zawinski. Take this quote

Back before the current dark ages began, I hacked on Lisp Machines. (..)
Have you ever wondered why we're stuck with crap like Unix and MS-DOS? Read Richard Gabriel's Worse is Better paper for a great explanation of why mediocrity has better survival characteristics than perfection

from Jamie's page and this quote from Richard

Yes, with string-based interpreters you can represent programs as strings, and you can interpret them as strings, but you can't parse their syntax very easily as strings. In LISP, programs are represented as data in a way that expresses their structure, and allows you to easily do things to the programs that are based on understanding them.

from a recent RMS interview. Both refer to the LISP machines of MIT, which seem to have operated on a higher level program representation than mere strings.

I interpret these rants that todays machines are stronger but dumber in a sense as well.

Question is if one could combine the strengths of both worlds. The higher level representation found in LISP machines and the performance of our present C compiled systems.

Like I tried to explain above, my feeling is that this could be achieved by shifting the primary representation to something closer to the intermediate structures that arise during compilation. It would have indeed similarities to a configuration management system. Adding a line to a text source would, after check-in, result in an immediate update of an persistent parse tree of the program database core.

OpenVMS compilers and the linker can be invoked to operate on CMS objects without having to pre-fetch anything first.

Do you have any reference where I can read more about CMS? (I would be happy also to have some nice review on the strengths of the LISP machines)

If we were to implement something like this for ourselves I'd say the first thing to do is to find a lightweight, fast and efficient implementation of an object repository. Does anyone know of such?

Sounds to me like what OODBs are promising. The one I had to try so far (POET 3 under Win32 and Solaris) was horrible. No idea how they perform today, as they seem to be two major revisions farther.

I also wish there had been more push for make Linux x86 a better database server platform. Limitations that get in the way are:

• 15 partition limit should be raised to a 31 partition limit
• Support in the offical kernel for accessing raw partitions such as rawfs or char partition devices
• Support in the offical x86 kernel for file over 2 gigs

Another item is the ability to have multiple default routes and routing to the default route based on source ip address. Multi-homing on multiple Internet feeds just isn't any fun when all your outbound traffic goes through the same pipe regardless of where the request comes from.

Anyways, I look forward to the 2.5 developments. The 2.3 kernel series has been fun. :)

It seems a shame that none of the journaling filesystems that are in the works are going to be ready in time for 2.4 (i.e. ext3, ReiserFS, or XFS) (unless I lost one of them somewhere in the alphabet soup)

There was some talk of these on Kernel Traffic, but apparently to no avail.

This is still one area that NT kinda shows linux up. (though there are plenty of bones to pick with NTFS, don't get me wrong) Not only that, but it's a neat, useful idea that adds much and takes nothing away. (I'm sure you'll be able to use ext2 'till the earth falls into the sun.)

The policy (as far as Linus is concerned) is that the P3 serial number will always automatically be disabled at boot, and that will not change. The reason (paraphrasing) is so vendors won't start using the serial number if it's never available.

You can read up on all of this on the Kernel Traffic web page.

A possible down side to binary video drivers is more closed source stuff. This could be good in that it gives vendors a way to have their kit supported in a way that they are more comfotable with (and therefore quicker development) but it might not help everyone else.

Kernel traffic / the linux kernel mailing list makes some intresting points about binary drivers.

From my point of view, binary == good as we get drivers quicker but if the driver as a anoying flaw there is very little that can be done about it (with out reinventing the wheel).

Yes, apparently Linux doesn't like variable speed CPUs. See here for more info. Apparently, it's a pretty serious problem.
--

They've been hyping this for a long time. Wasn't it supposed to slow the processor when the system was running low on power? There've been laptops that do this for quite a while now. In fact, there was a discussion on the kernel mailing list about it a while back. Here's a link to the discussion. Personally, I don't see it being that big of a deal. My take on it is that it's just an excuse to charge more for portable processors again now that they've been forced to lower prices by competition by AMD.

You'll want to read the recent Kernel Traffic. The first piece is all about closed binaries on Linux, and why they'll likely not happen any time soon in a big way.

It boils down to source code and maintenance. Once the company gives out specs that let people write source code, or otherwise release source code for the device, people can go ahead and use those devices. Companies seem afraid of giving out source code. I don't know why, becuase (at least with the Linux community) the community will support/maintain the code, fix bugs, and otherwise make it work well. If the company keeps their source closed, they have to take all the responsibility and work of making the code useful onto their shoulders. Simple psuedo code & specs for devices would allow a renaissance of proper hardware support for the BSDs, Linux, Hurd, and BeOS, among others. True, BeOS is a more closed source OS, but it could also benefit from LGPL drivers :-)

As for BSD, etc. Drivers in source form can be taken from Linux and put in the BSD kernels, as the LGPL licence is friendly about being linked with BSD licenced bits and bobs, IIRC.
---

I was pretty impressed when I saw it...

http://www.linuxcare.com/support/

See this URL : [ http://kt.linuxcare.com/kt19991220_47. html#1 ]for one such example..

Oh, you mean the discussion that includes

Erich Boleyn, an Architect in an IA32 development group at Intel, also replied to Linus, pointing out a possible misconception in his proposed exploit...

...

There was a long clarification discussion, resulting in a complete turnaround by Linus

i.e., that Linux later accepted the change:

"Everybody has convinced me that yes, the Intel ordering rules _are_ strong enough that all of this really is legal, and that's what I wanted.

...

Thanks, guys, we'll be that much faster due to this.."

As for "others can be found elsewhere", please give references - perhaps they're also not bad implementations.

Linuxcare Gurus who's who

Include Tridgell, Paul Mackerras(Linux on PPC), Paul Russell(ipchains), the excellent group of people at Prosa, and more on their way!

Also, according to this, google uses linux, and on many machines too :).

I'm sorry but I must disagree with you here.

Ok. You have a program, one situation is under GPL and the other one is under BSD. Lets say the owner now stops maintaining it. Under the BSD, someone else can take over. And lets say that this code is used by many and you are dependant on it. Now a company takes this code and starts maintaining it under a proprietary license. You use them because they may provide the best support. Then that company falls under and no longer can support you. Or they just don't think there's enough profit in maintaining it any longer, or they come out with a version that nolonger supports you. Now you are stuck with no one supporting this tool.

Lets look at this under GPL. It must remain open. Say that same company takes it over, but sells the support for that tool. Lets say that company makes many enhancements. All these enhancements must remain under GPL. This company now no longer supports it, it is easy to get someone else to support it, because it IS under GPL and anyone has access to the source.

BSD can promot forking more than GPL because you can license it under a proprietary license. Although the original code is still free, which is a good thing. I don't think we would have had the forks of the Unix if the original Unix code was under GPL.

A good article on this was posted on slashdot last month that points to the explaination of GPL and forking.

Like I said before, BSD is great when you take someone else's code. GPL is great when you make your own.

Steven Rostedt

I'm sorry but I must disagree with you here.

Ok. You have a program, one situation is under GPL and the other one is under BSD. Lets say the owner now stops maintaining it. Under the BSD, someone else can take over. And lets say that this code is used by many and you are dependant on it. Now a company takes this code and starts maintaining it under a proprietary license. You use them because they may provide the best support. Then that company falls under and no longer can support you. Or they just don't think there's enough profit in maintaining it any longer, or they come out with a version that nolonger supports you. Now you are stuck with no one supporting this tool.

Lets look at this under GPL. It must remain open. Say that same company takes it over, but sells the support for that tool. Lets say that company makes many enhancements. All these enhancements must remain under GPL. This company now no longer supports it, it is easy to get someone else to support it, because it IS under GPL and anyone has access to the source.

BSD can promot forking more than GPL because you can license it under a proprietary license. Although the original code is still free, which is a good thing. I don't think we would have had the forks of the Unix if the original Unix code was under GPL.

A good article on this was posted on slashdot last month that points to the explaination of GPL and forking.

Like I said before, BSD is great when you take someone else's code. GPL is great when you make your own.

Steven Rostedt

It's my understanding that while the Hurd is aiming for Posix compatibility, and going to use glibc as the standard library, they're going to be much more modular and abstracted (read: cool but possibly slow) under the hood.

The neatest things I've heard of:

The whole system is basically cooperating servers running atop the GNU Mach microkernel:

the idea that every user can build up his own system on top. So, if you want to operate, start compatible servers. It's after all your decision, much like it is your personal decision if you use one desktop system (like Gnome) or Xlib, Athena etc programs together. Latter don't interoperate well (drag n drop etc). As they run in user space, you can tweak the system to your liking, even as a user.

But there are still some servers that are the base of the Hurd system. Those are the auth, proc, init and password server at least. You don't need to register your process with the proc server (and it won't show up in the output of "ps" if you don't do so), but that the only thing that will give you access to the features of the proc server. Same with auth. If you don use auth, your tasks will have little to none privilegdes.

Better yet, filesystem support comes from servers, which I believe means that users can have files or filesystems (limited to user permissions) that live off their own servers. Every mounted filesystem is just another new filesystem server added to the pool. No need to make smbmount suid root or put every smb share with the user option into fstab, for instance; any user process would be able to mount arbitrary smb shares in their own directories and make them viewable without being able to circument security. Cooler yet, in theory you could make .signature be randomly generated by a program without using ugly named pipe hacks, you could "cd file.tar.gz" without ugly virtual filesystem libraries, you could implement albods more easily... I can't imagine all the possibilities, but it's fun to try.

Superficially you'd think there's an element of jealousy there because Stallman almost wrote an OS then someone else got most of the limelight by writing the kernel... but that just doesn't feel like the case.

There's appropriate mailing lists you can hunt down for deep info, but you can follow the Cliff's Notes of the Debian Hurd work at the debian-hurd Kernel Cousin page.

It's my understanding that while the Hurd is aiming for Posix compatibility, and going to use glibc as the standard library, they're going to be much more modular and abstracted (read: cool but possibly slow) under the hood.

The neatest things I've heard of:

The whole system is basically cooperating servers running atop the GNU Mach microkernel:

the idea that every user can build up his own system on top. So, if you want to operate, start compatible servers. It's after all your decision, much like it is your personal decision if you use one desktop system (like Gnome) or Xlib, Athena etc programs together. Latter don't interoperate well (drag n drop etc). As they run in user space, you can tweak the system to your liking, even as a user.

But there are still some servers that are the base of the Hurd system. Those are the auth, proc, init and password server at least. You don't need to register your process with the proc server (and it won't show up in the output of "ps" if you don't do so), but that the only thing that will give you access to the features of the proc server. Same with auth. If you don use auth, your tasks will have little to none privilegdes.

Better yet, filesystem support comes from servers, which I believe means that users can have files or filesystems (limited to user permissions) that live off their own servers. Every mounted filesystem is just another new filesystem server added to the pool. No need to make smbmount suid root or put every smb share with the user option into fstab, for instance; any user process would be able to mount arbitrary smb shares in their own directories and make them viewable without being able to circument security. Cooler yet, in theory you could make .signature be randomly generated by a program without using ugly named pipe hacks, you could "cd file.tar.gz" without ugly virtual filesystem libraries, you could implement albods more easily... I can't imagine all the possibilities, but it's fun to try.

Superficially you'd think there's an element of jealousy there because Stallman almost wrote an OS then someone else got most of the limelight by writing the kernel... but that just doesn't feel like the case.

There's appropriate mailing lists you can hunt down for deep info, but you can follow the Cliff's Notes of the Debian Hurd work at the debian-hurd Kernel Cousin page.

But as I said, the item seemed to indicated very little about what AT would be doing beyond working for Linuxcare remotely and playing with a frisbee when he wasn't (there was substantial footage of him chucking the said frisbee - this does not show up on the transcript.)

There are a lot of very stupid dependencies on undocumented "features" in Star Office. If they worked on getting rid of those they would do wonders to improve their stability and portability...

Regards,
Ben

if this article doesn't tell you otherwise, you are 100% unreasonable

Is there a worthwhile feature that anyone has developed, debugged, and perfected that the Linux guys have said no to?

• Support for ANSI C, and thereby the ability to compile the kernel using EGCS?

  We still have the situation that GCC v2.95 Or Higher Still Out Of Favor For 2.2.3pre11

  (That has changed recently, but Linus was refusing "EGCS compatibility" patches for rather a while there...)

• Removal of arguably-obscene language took a long time to be accepted...
• ACL's haven't yet seen implementation (although nobody has seriously tried)
• devfs has been tracking Linux kernels for quite some time, but has never been included.

  Recently discussed.

  This debate first came up in Issue #25, Article 2. This time it started innocently enough with a discussion of USB device number allocation. Pavel Machek pointed out that USB was finally starting to get useful, which meant it was time to allocate /dev entries for various USB devices. He allocated 32 entries for 16 devices, and Steffen Grunewald asked about other USB devices like monitors, speakers, etc.; and Dan Hollis replied, "The desperate need for devfs becomes all more clear." At this point there was no turning back. The debate raged for about a week and a half, generating over 600 posts. Linus, although back from vacation, posted nothing in any of the related threads; while Alan addressed his posts strictly to peripheral, technical details.

Is there a worthwhile feature that anyone has developed, debugged, and perfected that the Linux guys have said no to?

• Support for ANSI C, and thereby the ability to compile the kernel using EGCS?

  We still have the situation that GCC v2.95 Or Higher Still Out Of Favor For 2.2.3pre11

  (That has changed recently, but Linus was refusing "EGCS compatibility" patches for rather a while there...)

• Removal of arguably-obscene language took a long time to be accepted...
• ACL's haven't yet seen implementation (although nobody has seriously tried)
• devfs has been tracking Linux kernels for quite some time, but has never been included.

  Recently discussed.

  This debate first came up in Issue #25, Article 2. This time it started innocently enough with a discussion of USB device number allocation. Pavel Machek pointed out that USB was finally starting to get useful, which meant it was time to allocate /dev entries for various USB devices. He allocated 32 entries for 16 devices, and Steffen Grunewald asked about other USB devices like monitors, speakers, etc.; and Dan Hollis replied, "The desperate need for devfs becomes all more clear." At this point there was no turning back. The debate raged for about a week and a half, generating over 600 posts. Linus, although back from vacation, posted nothing in any of the related threads; while Alan addressed his posts strictly to peripheral, technical details.

Is there a worthwhile feature that anyone has developed, debugged, and perfected that the Linux guys have said no to?

• Support for ANSI C, and thereby the ability to compile the kernel using EGCS?

  We still have the situation that GCC v2.95 Or Higher Still Out Of Favor For 2.2.3pre11

  (That has changed recently, but Linus was refusing "EGCS compatibility" patches for rather a while there...)

• Removal of arguably-obscene language took a long time to be accepted...
• ACL's haven't yet seen implementation (although nobody has seriously tried)
• devfs has been tracking Linux kernels for quite some time, but has never been included.

  Recently discussed.

  This debate first came up in Issue #25, Article 2. This time it started innocently enough with a discussion of USB device number allocation. Pavel Machek pointed out that USB was finally starting to get useful, which meant it was time to allocate /dev entries for various USB devices. He allocated 32 entries for 16 devices, and Steffen Grunewald asked about other USB devices like monitors, speakers, etc.; and Dan Hollis replied, "The desperate need for devfs becomes all more clear." At this point there was no turning back. The debate raged for about a week and a half, generating over 600 posts. Linus, although back from vacation, posted nothing in any of the related threads; while Alan addressed his posts strictly to peripheral, technical details.

Is there a worthwhile feature that anyone has developed, debugged, and perfected that the Linux guys have said no to?

• Support for ANSI C, and thereby the ability to compile the kernel using EGCS?

  We still have the situation that GCC v2.95 Or Higher Still Out Of Favor For 2.2.3pre11

  (That has changed recently, but Linus was refusing "EGCS compatibility" patches for rather a while there...)

• Removal of arguably-obscene language took a long time to be accepted...
• ACL's haven't yet seen implementation (although nobody has seriously tried)
• devfs has been tracking Linux kernels for quite some time, but has never been included.

  Recently discussed.

  This debate first came up in Issue #25, Article 2. This time it started innocently enough with a discussion of USB device number allocation. Pavel Machek pointed out that USB was finally starting to get useful, which meant it was time to allocate /dev entries for various USB devices. He allocated 32 entries for 16 devices, and Steffen Grunewald asked about other USB devices like monitors, speakers, etc.; and Dan Hollis replied, "The desperate need for devfs becomes all more clear." At this point there was no turning back. The debate raged for about a week and a half, generating over 600 posts. Linus, although back from vacation, posted nothing in any of the related threads; while Alan addressed his posts strictly to peripheral, technical details.

Is there a worthwhile feature that anyone has developed, debugged, and perfected that the Linux guys have said no to?

• Support for ANSI C, and thereby the ability to compile the kernel using EGCS?

  We still have the situation that GCC v2.95 Or Higher Still Out Of Favor For 2.2.3pre11

  (That has changed recently, but Linus was refusing "EGCS compatibility" patches for rather a while there...)

• Removal of arguably-obscene language took a long time to be accepted...
• ACL's haven't yet seen implementation (although nobody has seriously tried)
• devfs has been tracking Linux kernels for quite some time, but has never been included.

  Recently discussed.

  This debate first came up in Issue #25, Article 2. This time it started innocently enough with a discussion of USB device number allocation. Pavel Machek pointed out that USB was finally starting to get useful, which meant it was time to allocate /dev entries for various USB devices. He allocated 32 entries for 16 devices, and Steffen Grunewald asked about other USB devices like monitors, speakers, etc.; and Dan Hollis replied, "The desperate need for devfs becomes all more clear." At this point there was no turning back. The debate raged for about a week and a half, generating over 600 posts. Linus, although back from vacation, posted nothing in any of the related threads; while Alan addressed his posts strictly to peripheral, technical details.

IF any one wants to see another dumb patent case and a patent examiner's view of this check out the latest Kernel Traffic

RMS had no problems with this business model, . . .

Actually, I hear that he's not thrilled with it. Indeed, one of the biggest problems that I can see is that there is very little incentive for people to improve the existing GPL version of Ghostscript when they know that Aladdin has (a) already improved Ghostscript in the current commercial version, and (b) will be releasing their changes 'soon' (after one year). This interview with Ghostscript's author Peter Deutsch sheds more light on the situation, including Stallman's thoughts.

One result is that the GPL community is almost guaranteed to always be one year behind the latest in Ghostscript technology, unless someone gets up enough nerve to fork Ghostscript development and try to get ahead of Aladdin.

With Ghostscript the GPL was not restrictive enough. Proprietary software would simply call the gs executable in a separate process.

Part of the problem here is that the Aladdin folks try to license their code to printer manufacturers, etc. The printer folks aren't too keen on having to ship Ghostscript on demand to anyone who buys a printer. Also, if the printer folks make any platform specific changes (which undoubtedly they will, such as specific driver technology for running the print engine), they'd have to distribute those changes, and most aren't willing to do so.

Also, more importantly, Peter Deutsch doesn't seem too keen on having people ship Postscript-enabled printers by using his work for free (as in gratis).

The upshot: Aladdin offers their latest and greatest Ghostscript with a commercial license.

With ReiserFS, I'm sure a similar but not identical set of considerations exist. People building embedded or mission critical systems on an otherwise proprietary base might license ReiserFS for their application without introducing any questions as to the effects of GPL. At the same time, a GPL version is available for everyone.

The difference here is a bit subtle but important. Namesys appears to be releasing the latest and greatest ReiserFS under GPL, rather than imposing an artificial delay. (Whether or not this changes in the future is unclear, but for now it is an important distinction.) In this case, the commercial license seems to be a means for companies to buy an "unencumbered" version of ReiserFS for their own purposes. (By "unencumbered", I mean free of the implications of GPL.) I see this potentially as a way to keep both camps happy. Maybe. (Except, of course, RMS.)

This is a good thing, but it is part of a more general problem.

And that problem is that we accept tools for Linux development that are distinctly sub par. There is a lot that could, and should, be done.

I would say more, but I cannot possibly say it better than this rant does.

Cheers,
Ben

PS The Microsoft program works right and has a bad interface, the Linux program has a nice interface but sucks! Whodathunkit? (Read the link.)

This is still a very Good Thing(tm), though, since it takes more dominoes to fall to keep a domino effect going.
---
"'Is not a quine' is not a quine" is a quine.

They can start with my favorite kernel site, Kernel traffic. If you want to have a reasonable sense of what is going on with the kernel but don't want to follow the mailing list - then visit this site every week.

By and large the sorts of services that people need are already available. They should recognize that, list a few, and then move on.

I would say that some advice on kernel programming would be good. Sprinkle said advice with links to a few of Torvalds' rants on sending patches. :-)

Cheers,
Ben

See Kernel Traffic #36 for a start; a bit later in the thread referenced there Alan Cox said that he'll be looking to solve the problems with more recent version of GCC in 2.2.14 or 2.2.15, for now he advises compiling production kernels with GCC 2.7.2.3.

Of course, RH6 has already switched to later versions, and doesn't include or make available GCC 2.7 anymore. I haven't yet done it but it seems to me that it shouldn't be too hard to install an older version just for kernels. That step prolly won't be needed for all that long, anyway. Anybody with experiance want to post some tips on the process?

As I understand it the main trouble with newer GCC versions is that certain parts of the kernel rely on bugs or at least strangeness in the older versions. My current system is a well patched 2.2.9 compiled with egcs 2.91 and I haven't seen any problems, but for my important servers I don't want the possibility of random lockups if I can avoid it.

THE GOOD

• LinuxCare's little bootable Linux recovery CD kicks ass. No bigger than a business card, it fits in the 3" diameter groove in CD-ROM/DVD-ROM drive trays and has the potential to save your butt when lilo eats itself. They also had some Linux stickers that now adorn the case of my 386... (Yes, it runs Linux.)
• IBM had a presence. Although certainly not the largest or flashiest booth in the show, Quake 3 on a rather large plasma display attracted lots of attention. Dual PII-400 Intellistation + Voodoo 3 3000 + large plasma display. Mmmmmm. Thanks to the guys there for letting me get some game time on that mammoth thang...
• O'Reilly also had a presence, and their trade show pricing kicks much booty. Picked up a few books for 20% off list and got a shirt to boot...
• Mad props to VA Linux Systems for not only having a cool booth and giving away lots of stuff but for supplying the machines used for public Internet access. Their Debian boxed set is pretty cool and sports Learning Debian GNU/Linux from O'Reilly. (Yes, I was one of the people who stood around in line for ten or fifteen minutes to win this...)
• Thanks to the Sun and Rave Systems folks for all the free stuff. Learn to play Quake 2 without cheating before next year's show... :-) (Now where's my complimentary Sparc 5?)

THE BAD

• None of the shirts I got fit. None. Zero. Zip. Zilch. I'm 6-foot-3-inches tall and weigh 295 pounds. Show me the big-assed shirts!
• The IBM guys told me that the Showcase had a T-1 connection to the 'Net. I couldn't verify -- the packet loss and latency was horrible on the connection. I'm hoping this is only because lots of geeks were pounding on the connection like a pack of wild monkeys...
• Food choices were few, and lines were long. Within the Galleria, your choices were Subway, some cafe whose name I don't remember, Ruby Tuesday's, and Chick-Fil-A. If you were bold, you could go to the movie theater downstairs and buy a big tub of popcorn. The group I was with walked across the street to another mall and ate at Arby's. Yum... I think.

THE UGLY

• Where the hell were the Slackware people? I wanted Slackware apparel... Hmmph.
• Linux merchandise places came out of the woodworks to hock their goods. Yay capitalism...
• Don't eat at Shoney's. Our group waited over an hour for food before giving up and leaving.

THE REST

• The andover.net/freshmeat.net/slashdot.org booth was smack dab next to the linux.com booth. Taken together, it looked like one big congregation of slackers with laptops. All things considered, however, I wouldn't have minded flopping down on the couch for a rest after walking around for a few hours...
• I will seek revenge against the guy in the Debian shirt who shot me in the arm with a Nerf dart... muahahahaha
• The Debian folks had a Sun Ultra 5 running XaoS, Netscape, and some Tetris clone in separate windows. Just for kicks, I maximized the XaoS window. Can we say slideshow?
• I had nothing interesting enough to trade with the lady at the VA Linux booth, so I didn't get one of those nifty enlightenment shirts. Dammit.
• NetBSD was there. Go figure.

Overall, it was a pretty cool show, but I wish I didn't have the 2-1/2 hour drive. It was put on very professionally and appeared to be very well organized. I was only slightly disappointed that the show wasn't any bigger... The nifty canvas bag attendees got and the included CD made up for that, though.