Slashdot Mirror

I also claim that Slashdot people usually are smelly and eat their boogers, and have an IQ slightly lower than my daughters pet hamster (that's "hamster" without a "p", btw, for any slashdot posters out there. Try to follow me, ok?).

Last week's Slashdot article on Theo de Raadt was about how he's not using binary drivers.

I was not referring to 2.6.x.y, but to specifically 2.6.16.x, as per this bit of news: http://kerneltrap.org/node/6386 - in effect a "Stable" branch based on 2.6.16 started as soon as 2.6.17 is released.

Even better, call it eMacs and bundle it with GNU/Hurd and Emacs.

*snort* - that would be funny! I'd distribute it with Darwin over GNU/Hurd tho' - for extra (Alanis Morissette style) irony points. (Plus, you could actually ship it)

I think bugfix cycles should be a part of the development process. For example, the current versioning is

2.6.x (all even) is supposed to be stable. (1-2 weeks per release)

Whereas

2.6.x (odd) is a little more edgy, but still a stable release (1-2 months per release)
2.x.x (odd) possibly breaks lots of stuff (1-2 years per release)
x.x.x everything broke. Oh. My. God.

So maybe once every 6 months (I prefer) or at least once per year there should be a cycle completely dedicated to bug fixes. This could simply be a longer 1-2 month 2.6.x (even) cycle. Especially now that there is no 2.7 release and they are dumping new functionality in 2.6 like it's nobody's bizness.

The ones creating the glue for blob hardware abstraction layers? (Madwifi)

More seriously, even if OpenBSD used the GPL, or the Linux kernel used a BSD-style license, the OpenBSD project couldn't just incorporate device drivers from the Linux kernel the way it can do it with the other BSDs: they're still very different operating systems! Most of what is "taken" from the Linux kernel are static values: register offsets and such (see this excellent interview where OpenBSD developers describe what writing their nfe(4) driver for NForce ethernet involved). It's hard to do much more without violating the GPL anyways.

I was hoping he'd say something about his thoughts on Linus' calling the Mach and FreeBSD people 'incompetent idiots'.

Sure he's an OpenBSD guy... but I'm sure he's got an opinion on it.

I'd much rather an excellent programmer with no formal education

You're not the only one. FreeBSD kernel guru Jordan K Hubbard has only high school education. He has self learnt basically everything and he's one of the best in the world.
 
  Here's interview.

A more detailed version is in the kerneltrap interview.

From: Linus Torvalds [email blocked]
Subject: Re: Linux 2.6.17-rc2
Date: Fri, 21 Apr 2006 10:58:46 -0700 (PDT)

I got slashdotted! Yay!

On Thu, 20 Apr 2006, Linus Torvalds wrote:
>
> I claim that Mach people (and apparently FreeBSD) are incompetent idiots.

I also claim that Slashdot people usually are smelly and eat their
boogers, and have an IQ slightly lower than my daughters pet hamster
(that's "hamster" without a "p", btw, for any slashdot posters out
there. Try to follow me, ok?).

Furthermore, I claim that anybody that hasn't noticed by now that I'm an
opinionated bastard, and that "impolite" is my middle name, is lacking a
few clues.

Finally, it's clear that I'm not only the smartest person around, I'm also
incredibly good-looking, and that my infallible charm is also second only
to my becoming modesty.

So there. Just to clarify.

Linus "bow down before me, you scum" Torvalds

I think Linus's comments on KernelTrap here are pretty clear. A binary module is not automatically a derived work. Jeff

The Open Graphics Project recently released schematics for their first product and are steadily making progress towards completing it for sale (http://kerneltrap.org/node/6262). If Libre graphics drivers are REALLY important to you, you might want to consider looking them up at "www.opengraphics.org". Despite being unfunded since early 2005 (which they could use some help with), they are still managing to make some headway. Those people with technical expertise (graphics drivers, graphics hardware, PCB design, chip design) would do well to pitch in to the effort. And those with money who also complain about the lack of Libre drivers should put their money where their mouths are. Rather than sitting around and complaining about it, the founders of the OGP decided to actually DO something about it; if you want to do more than just complain, they could use your help.

It's funny, it teaches careful examination. It also illustrates that this sort of thing is possible in C, and indeed has been done:

http://kerneltrap.org/node/1584

As such, I suspect it's also a jab at the C language, reviled as it is by many computer science professors for exactly this sort of thing. It's hosted on the computer science department pages of Bingham university. They're not exactly Haskell fanatics, but probably not the opposite either.

Just like this

Look I'm an OpenBSD fan but even I'm a little unsure on this one... The Linux folks reverse engineered the Nvidia ethernet driver in forcedeth and in fact forcedeth was helpful in the creation of nfe.

Are you sure that you want to claim that OpenBSD had "the first [nforce ethernet] open source driver" (emphasis is mine)? Can you give some links to back this claim up? I haven't found any yet but then again I don't hang out on the OpenBSD lists all that much...

I thought the 2.6.x series of kernels was stable ? Shouldn't all of these new features being showing up in 2.7.... ?

They have changed things in favor of a faster development model. I believe now it is 2.6.X where when X is odd it is development (includes adding new features) and X is even it is release.

It didn't say the company wouldn't give details to the reviewed projects, and in fact Coverity has sent correspondence to the projects earlier this week offering to do just that. See http://kerneltrap.org/node/6299 re the Linux kernel; similar messages were sent to the other projects.

Most Linux admins don't read the linux-kernel archives.

I did. Specifically because I didn't want to subscribe to the lklm mailing list. I'm not a kernel developer, so there was no need for me to keep up with every person kicking in their $0.02 on some obscure issue. BUT I really appreciated the summaries because Zack gave a quick blurb of what was going on over there in kernelland. It allowed me to gauge matters like "when to move to a new kernel?". Or if there was a problem with a kernel feature, whether it was SATA, SCSI, or whatever.

Kerneltrap is a poor substitute. I will miss the summaries.

Part of what makes Linux and GPL'd software so nifty is that with access to the source code one can do all sorts of wonderful and unexpected things. Port wondershape to the wrt54g. Replace svgalib with aalib and seamlessly render images and video streams as ascii art. Fit linux onto all sorts of silly places, including a windows device driver. Tune the linux scheduler parameters using adaptive genetic algorithms. Cook up packages for compiz before the distro puts it into stable. The ability to think outside the box and hack things in this manner is simultaneously the strongest advantage OSS has, and it's greatest obstacle.

The greatest obstacle? Firstly, if you simply hire people familiar with open source, those who recognize the value of the above traits, you're likely to get something that satisfies their needs not yours. Maybe that compiz package requires a lot of extra effort on your part, because nobody's written a script to handle the simple textfile changes nessecary. Secondly, integrating silly hacks back into the core is a challenge. On the one hand, integrating them into the core encourages more, which we like. It also means that the hack gets all the benefits of future improvements. On the other hand, not every hack is easily maintainable, nor easily integrated. Every time you reject a patch, you discourage people from offering in the future, and the risk of someone pissed off and forking your project increases. Not that forking things is always bad, but a fork in spite is bound to not only divide resources but increase overheads, potentially causing a net loss in future value of the software.

Shuttleworth believes he can fix this by making communication among groups more explicit. I doubt it will improve anything. On his next attempt, perhaps he should make his team a stakeholder in a very dear sense. Not bonuses for completion or anything silly. Make them run a school with the software -- Eat their own dogfood. The core team will have to shift their focus on making the software work for them in ways similar to other schools. Maybe they could start a school about hacking on OSS. Teach the newbs the labrynthian ways of the autotools, how to take a tarball and make it a .deb, that sort of thing. Something the team wants to be successful and proud of.

Already tried - a little while ago someone tried to slip a backdoor into the linux kernel.

Fortunately, the backdoor was caught via exactly the kind of peer review that open source allows.

see http://kerneltrap.org/node/1584

with open source, it's easier to get trojaned code in, but harder for it to stay there. on the reverse, who knows what could be lurking in MS code? I quote:

"A senior Microsoft Corp. executive told a federal court last week that sharing information with competitors could damage national security and even threaten the U.S. war effort in Afghanistan. He later acknowledged that some Microsoft code was so flawed it could not be safely disclosed."
(http://www.eweek.com/article2/0,3959,5264,00.asp)

If security is a concern perhaps one should be a bit vary of Linux due to the big changes (ripping out core components) in the Linux kernel that happens quite often. Even deciding on a 802.11 stack seems difficult:

It's high time that Linux get a serious effort going on a generic 802.11 stack, as it seems we are in danger of having every new wireless driver invent one if we do not.

Linux put great emphasis on performance, not stability nor security, and this is well known. Offering a stable (i.e. usable) Linux kernel is up to the various distributions.

"Security" is in vogue, but it appears to be mostly market speech with little, if any, content.

http://kerneltrap.org/node/6053

The Linux kernel guys are WAAAAY behind OpenBSD on this front, and I partly blame ndiswrappers for this. Because there is a brutal hack available that lets you use the windows drivers, there has been little to no incentive to actually create native solutions.

I'm glad that the OpenBSD guys put so much effort into sorting out binary licences with vendors so that they can do native kernel drivers.

Jeff Garzik posted on LKML on January the 5th a lengthy article about the state of linux Wireless. See here.
John W. Linville claimed the responsibility for Wireless support in the kernel. The archive of the LKML thread is available here.
Hopefully is this going to improve things...

Intel does not allow its cards' firmware to be freely (as in beer) distributed, so it should not be supported even though the drivers itself are nice. See http://kerneltrap.org/node/4818

KernelTrap recently reported on this: http://kerneltrap.org/node/6053

Kerneltrap had an informative article on this. The short summary is that wireless support on Linux sucks, and that it is partially our own problem. A quote:

another banner year has passed, with Linux once again proving its superiority in the area of crappy wireless (WiFi) support. Linux oldsters love the current state of wireless, because it hearkens back to the heady days of Yuri Gagarin, Sputnik and Linux kernel 0.99, when getting hardware to work under Linux required either engineering knowledge or luck (or both).

Linux: Wireless State of the Union

Is this good enough? http://kerneltrap.org/node/4965

I'm not a Linux expert. I can't point to the stuff.

All I know is that OpenBSD absolutely doesn't allow that stuff.

Consider the purpose of the computer when choosing the filesystem? Yep, can't argue with that.

One other point I thought of just after posting my first comment is that CPU power is growing far faster than IO resources are growing, so changes in the technological environment are causing CPU-using filesystems to be increasingly a good idea.

And here's a benchmark which backs up what I was suggesting. It shows Reiser4 as being the fastest, and the most CPU-using, of the 5 main journaling filesystems. And given that CPU cycles are becoming increasingly numerous and cheap, that's probably ok for most uses.

And even better: Buy a card from the Open Graphics Project when it's available (first half of this year, if all goes well).

It's certainly what I'm doing (just sent back an Nvidia 6600 something-or-other I got for ACGPD).

http://kerneltrap.org/node/1071

Yes, X11 acceleration happens largely in user space. I'm of the opinion that even that should live in the kernel, but I have a feeling I'd be shouting at a brick wall. However, all that really does, AFAIK, is access a memory-mapped aperture into the GPU's VRAM. That's not what I'd call a driver, per se. More like a device access routine. The performance-critical heavy lifting---the memory mapping work, interrupt handling, command queueing, etc.---occurs in the kernel, albeit to some degree under control of an application.

More than that, those bits -must- be done in the kernel (though perhaps not entirely at ring 0) in order to provide reasonable resource arbitration policies when multiple programs need to use the GPU simultaneously (e.g. using the GPU to offload generic DSP processing). If you just map the VRAM into a dozen programs' address spaces and hope for the best, they would clobber each other repeatedly....

I like everyone else was trained *never* to use the dreaded goto statement. I'll grant that Pascal was more readable than Basic (with unlabeled gotos).

But, sometimes, it is actually better to use a goto to make the code more readable. The Linux Kernel, for example, uses gotos. I was pretty sceptical at first because it had been drilled into my head how unreadable code was with gotos in it. But, reading the code, I have to admitt is is much more readable for exception handeling, for example.

If the goto would not make your code more readable then don't use it. But, in the cases where it would avoid a bunch of sillyness trying to get out of a bunch of nested loops in case some error happened, then it makes a lot of sense.

Linus Torvalds (and others) explain the reasoning for this at:

http://kerneltrap.org/node/553

In short, there are both readability and efficiency reasons to use gotos.

http://kerneltrap.org/node/553
goto in linux kernel code is not considered harmful. Linus said so in 2003!

Thank you for your generous reply.

Would you mind if I shared this, and your previous post, with the ACM chapter at my university (http://acm.uta.edu/)?

After Kernel Trap did their interview with Hans Reiser, we have been looking for good advice from experienced programmers. While we were originally looking at forming a base of questions to use in interviews, I think this sort of exchange is just as helpful.

Again, thanks for your input.

I had a lot of spamming problems, and could never get the anti-spam additions to work

Try using this for Drupal, if the problem comes up again, I've been using it for a while and it's excellent.

http://kerneltrap.org/node/422

Linux was fairly slow at thread creation. Linux is now wicked fast at thread creation. In one benchmark, what used to take 15-minutes for Linux, can now be completed in 2-seconds! No joke!

I don't have something I can point you at right, however, the information is true. Linux used to have horrible overhead imposed by thread creation. As a result of both the NGTL and NPLT projects, the time needed to create a thread on Linux is tiny...tiny...tiny...some of the well known results from the projects were published... Here's a quote:

"One test mentioned in Ulrich's email - running 100,000 concurrent threads on an IA-32 - generated some interesting discussion. Ingo Molnar explained that with the current stock 2.5 kernel such a test requires roughly 1GB RAM, and the act of starting and stopping all 100,000 threads in parallel takes only 2 seconds. In comparison, with the 2.5.31 kernel (prior to Ingo's recent threading work), such a test would have taken around 15 minutes."

http://kerneltrap.org/node/422
As you can see, the stellar increase in thread performance has been unbelievable. Keep in mind, prior to this effort, Linux's thread creation was no where near the performance delta gained from these projects. Ergo, one can easily deduce that Linux far exceeds (less time) Win's thread creation latencies.

Was that Linus? I thought that was someone else'e attempt at changing the kernel from C to C++?

I'm no Linux hacker, but this has Linus's name at the bottom, so I'm guessing it was indeed Mr. Torvalds's super-crazy and far-out versioning scheme....besides, I hear the man doesn't care for C++.

If the following forum is anything to by, people are talking about it:

    Linux 2.7 kernel

Even if it is not necessarily in active development, people are talking about what they would like to see.

If they didn't have to support that other, lesser OS that is still polluting everybody's desktops, these folks could use the Secure Computing capability of Linux to wall off the grid client from the rest of the box, right at the kernel level: http://kerneltrap.org/node/4005

My guess is that it is referring to VFS, the overreaching file namespace manager that all File System drivers get mapped into.

From Kerneltrap:
VFS Documentation
Reiser4 and VFS Issues

My guess is that it is referring to VFS, the overreaching file namespace manager that all File System drivers get mapped into.

From Kerneltrap:
VFS Documentation
Reiser4 and VFS Issues

These guys(Xen) have all these companies donating money to them, but have been beaten to kernel inclusion by UML.

Being the first to the party doesn't always mean you're going to the best; see DevFS vs. udev.

Xen has much greater performance than UML and supports more operating systems. While UML is currently more mature and stable than Xen, it's only a matter of time before Xen surpasses UML as the preferred virtual server technology. Hell, even Linode, a strong proponent of UML technology and virtual server hosting provider is migrating to Xen.

FYI, I'm currently running a Xen-based system with 15 virtual server instances for a system administration course at UC Berkeley on a server built with cheap off the shelf components (AMD Athlon 64 2800+, 1 GB RAM) and everything is quite snappy. It'd be difficult to even approach such usability with UML, and I'm using Xen 2.0.7. I can't see what Xen 3.0 will bring.

It's time, IMHO, for Linus to pull rank and just order it merged.

It's time, IMHO, for Linus to pull rank and just order it merged.

LUFS is unmaintained, it has been replaced with FUSE. FUSE includes a LUFS-to-FUSE bridge called Lufis

FUSE is now merged into the Linux kernel, and will appear in 2.6.14.

Marcelo Tosatti, who's the maintainer the 2.4, has lived in Brazil his whole life.

Interview and pic can be found here.

What some open source zealots, and the vast majority of open source "consumers" don't recognize is that programmers need to eat to. Until these "consumers" stop taking advantage of open source, and start paying... Open source will stay in Microsoft's (and other big corporations) shadow, and very likely even shrink.

Nessus is not the first, and not the last. Even Hans Reiser has this problem:
See here... Hans Reiser: Doing GPL work is doing charity work [...] That should be and could be changed, but for now it is so. I have done my share of charity, and I would not have a problem doing proprietary work. I think people should keep their lives in balance, and that includes balancing charity work and better paid work. ... It is not an easy life, I am $200k or more in debt and drive a 1989 CRX Si.

Here is another: Mute file sharing. Not sure how long this experiment will last.

And one more: Daniel Robbins founded Gentoo linux, went bankrupt, got job at Microsoft

Either help these programmers feed themselves and their families, or expect other big and large profile projects to disappear and become pay-for-play.

I love open source, and contribute money to many projects -- but open source will just prove to be a fad that will start to wear thin on programmers as they get into debt and can't feed their families. The business case for open source software longterm survival is weak, unforunately.

m

In case you wanted to read the Kerneltrap article mentioned but not linked http://kerneltrap.org/node/5584

My impression is that they're more compliant with Unix specs (as in OpenGroup).
Some BSD developers have a thorough understanding that programming in C is dangerous and have implemented savefty nets around that fact (see Exploit Mitigation Techniques, see a recent discussion on Kernel Trap about OpenBSD's memory allocation :http://kerneltrap.org/node/5584)

Andrew's vision, as expressed at the summit, is that the mainline kernel will be the fastest and most feature-rich kernel around, but not, necessarily, the most stable. Final stabilization is to be done by distributors (as happens now, really), but the distributors are expected to merge their patches quickly