Slashdot Mirror

I've been waiting to ask, what ever happened to http://kerneltrap.org/ ?
No activity since September.

The funny thing is that he’s not friends with Theo. Theo tried to make strlcpy and strlcat the de facto standard, in order to reduce the number of buffer overflows, but Drepper famously rejects them as “horribly inefficient BSD crap.”

When I saw this interview, where Theo complains that “one person decided to be difficult,” my immediate thought was Drepper.

"I find it intimidating that the community is unable or unwilling to maintain proper information channels for security-related maintenance"

You could try looking over on the Bug Tracking System or the openbsd-bugs mailing list

This was forseen: Intel will ultimately be forced to redesign their flash write algorithms

The point of this is, please please please if you are an engineering manager, when you make a collective booboo, no smoke screen please! It is unlikely to go unnoticed, and nothing positive will be achieved for you, your company, your potential customers or your tech audience. Instead, just come clean, admit the problem and get busy on the fix. Down that path lies increased trust, whereas the doublespeak path only erodes credibility. I certainly will be double checking any future claims, because of how this played out.

Anyway, big props to the team for implementing what appears to be a superior solution. Hey, how about just open sourcing that firmware and let everybody help make it even better? Just a thought.

Sorry. I was under the impression grub was late getting ext4 support.

http://kerneltrap.org/mailarchive/linux-ext4/2008/10/18/3716214/thread

Oracle have comparatively done bugger all. Redhat employ _real_ kernel developers. Do oracle?

Yes. http://kerneltrap.org/node/7637 as one example.

Ingo Molinar says: "I cannot over-emphasize how much of a deal it is in practice. Atime updates are by far the biggest IO performance deficiency that Linux has today. Getting rid of atime updates would give us more everyday Linux performance than all the pagecache speedups of the past 10 years, _combined_."

Was this not paraphrased in mid-2007 by Theo of OpenBSD fame?

>... exploits usually are not particularly portable.

OK, but there has been at least one attempt at planting a portable back-door in the linux kernel: http://kerneltrap.org/node/1584

Null-terminated strings. The bane of modern computing.

Maybe I'm feeding a troll, but what else would you terminate it with without using something the string may contain? Keep in mind that null-terminated strings were, err, "invented" around the time ASCII was really the only fully widespread character standard, and something was needed to mark the end of a string for detection by software.

The mistakes you speak of are made by programmers that don't know how to securely utilize this in certain environments. Mainly in buffers, but recall the lkml thread about the license macro in kernel modules being abused with '\0'.

The 1 GB limitation is probably due to the way they have the kernel compiled. The Linux kernel has a 1 GB limitation unless you have High Memory enabled. If I remember correctly, the kernel runs faster if High Memory is disabled, which is why Dell probably has the kernel configured that way. Linux mini 9s come standard with 512MB. Way too much information that I don't understand can be found here: http://kerneltrap.org/node/2450

As for the yahoo toolbar junk, I can't defend Dell on that one...

Thanks for the UNR link, I didn't know about that. I actually ordered a mini 9 with Linux a week ago when Dell was having a sale on em. ($284 w/ 1mp webcam, 1gb ram, 8 gb ssd) Can't wait for it to get here.

Remember that Intel has been willing to open its drivers and specifications.

Really? Maybe my information is out of date, but that's not how I remember it. Are they doing something different now?

Because earlier he said, "I think that people who argue for splitting desktop kernels from server kernels are total morons, and only show that they don't know what the hell they are talking about." (source)

Not only do they not mind, they planned it that way.

Unless they're Theo de Raat.

And for those kind words I'm going to post a follow up to my original post of more relevant changes between the 2.4 and latest 2.6 kernels (I'll try and add a few more words after each point).

Kernel configuration was overhauled. Outside support for more GUI menus, it now means you no longer have to do make dep after changing something. Further building modules outside the kernel tree is now not so baroque. The time to build and partially rebuild kernels also dropped. Building a kernel in parallel (i.e. using more than one CPU during the build process) works better.

Better support for configuring out unneeded parts of the core kernel on embedded systems. You can see the seeds of this going mainline in a git commit on 2.5.70. There is an outside project called Linux Tiny that produces patches aimed at being able to configure out features not needed for embedded systems. Over the course of 2.6 many of these patches have trickled into the mainstream kernel.

I mentioned that 2.6 scales better under load in my previous post. Here are some benchmark comparison graphs of 2.4 versus 2.6 kernels (the graphs also include comparisons against the BSDs but you can see that Linux 2.4 had some serious problems that Linux 2.6 addressed).

The kernel is now (on systems where there is reliable device discovery) able to automatically load the modules it needs to drive hardware. No more having to adjust static lists of which modules need to be loaded.

udev was introduced. This change meant that the entries in /dev were no longer static. In 2.4 all possible device entries (even for devices you didn't have) were shown in /dev and their major/minor numbers were fixed (which was causing problems as new devices were turning up - what major/minor number do you give them?). Additionally the other dynamic /dev system (devfs) was whittled away and killed off.

FUSE support (LWN article about FUSE). Allows filesystem drivers to be written in userspace. Currently the best Linux NTFS driver is written using FUSE and it allows fun things like sshfs. Might be handy if you need users to be able to configure where data is stored remotely, you are writing your own filesystem or you need to support writing to NTFS formatted USB disks...

There is better CFS (Samba/SMB/Windows File Sharing) support. NFS version 4 support was also added.

cpufreq support. The kernel can clock down the CPU speed (usually by changing voltages via some hardware interface) to save large amounts of power. This can be done in response to work load so you run at full speed as often as possible and then when things are quiet you scale down to the lowest setting (you often save the most power when doing absolutely nothing so it pays to finish things as quickly as possible).

Any switch from 2.4 to 2.6 will of course require userspace changes (updated modutils, udev, later gcc, later glibc).

There is also davej's post Halloween document discussing changes from 2.4 to 2.5. This is very detailed and is another excellent reference.

Many many other things have changed too (e.g. ALSA support for sound has been added) but I have tried to keep the ones mentioned at least tangentially related to the original scenario :)

I don't actually use git, but I've heard it's actually possible to add historical snapshots to an archive at a later date. So you could switch over with no history and start using it right away, and worry about important your old repository's history later.

moreSome folks have toyed with the idea of constructing a git tree of historical linux releases.

Linux commented:

The good news is that git would be a lot more natural to the process of
trying to create a history, because you could basically import random
trees, and tag them as just independent trees, and then re-create the
history after-the-fact by trying to stitch them all together. And if you
find a new tree, you'd just re-stitch it - something that was very hard to
do with BK (and BK generally wouldn't help you with keeping multiple
independent trees around, and wouldn't generally accept the notion of
re-doing the histories and keeping various versions of the histories
around).

To me, that suggests you can import history at a later date and still integrate it properly in your tree.

exFAT has support for ACLs. Imagine the madness when *those* get screwed up (Especially when Vista SP1 doesn't have a GUI to manipulate them!). :D

Things *could* get messy with permissions. You could, however, write your embedded FS driver so that it ignored FS permissions and made files that it processed readable and writeable by all. (It is probably running as root, after all.)
[It seems that some (all?) ext2/3 drivers for Windows ignore permissions on ext2/3 volumes.]

WRT ext4: I wonder if you could disable journaling...
A quick search reveals this conversation by Ted Tso.
https://kerneltrap.org/mailarchive/linux-ext4/2008/10/7/3532804
This post implies that an ext4 FS can run without a journal.
http://74.125.77.132/search?q=cache:eivENzNpGUwJ:lkml.org/lkml/2009/1/7/378+site:lkml.org+%22allow-ext4-to-run-without-a-journal%22&hl=en&ct=clnk&cd=1&gl=us

I'm rather unqualified to comment on an issue like filesystem complexity, so I can't address that part of your claims. If you're qualified to comment, would you kindly direct me to some documents that could give me a feel for the complexity of implementing an exFAT driver?

Cheers!

Likewise, Linus also states there are multiple advantages of using git over svn. Most noticeably:

So one of the worst downsides of CVS [and SVN] is _politics_. People, not technology [impede the ease of commits].

He also points out git's advantages in speed and decentralized model.

Backdooring something like the Linux Kernel via traditional means (by attempting to submit malicious patches) would be much, much harder than you think. I mean just read the LKML to understand how thorough the review process is: the owner of the code scrutinizes your patch line by line, suggests improvements, even catches coding style errors, etc. Maintainers are especially cautious about code that comes from unknown developers.

Regarding your comment about hacking servers holding the source code, this would also very likely get caught really quickly, because of the very nature of version control systems whose only purpose is to track changes. As a matter of fact in 2003, a CVS mirror (not the primary repository) of the kernel source tree was successfully hacked and a backdoor was inserted in the code, but the problem got identified and fixed in less than 24 hours

With proprietary software there is only a restricted number of people who review code, typically only a very specific dev/QA team employed by the software vendor. I would even argue that because of the implicit trust between these employees, reviews tend to be shallower. Two examples to prove my point: in 2001 it was discovered that a back door password has been hidden in Borland/Inprise's popular Interbase database software for at least seven years. In June 2008 it was discovered by a security researcher that for multiple years all versions of Windows have been intentionally using a lower-quality cryptographic function for Protected Storage when the locale was set to French.

So, do you trust a development model where malicious code is caught in 24h, or a dev model where backdoors can exist for 7 years ? The answer is obvious to me :)

mount -o ssd option, which clusters file data writes together regardless of the directory the files belong to. There are a number of other performance tweaks for SSD, aimed at clustering metadata and data writes to better take advantage of the hardware.

On the security side, I'll just quote Google's description: "modules may not contain certain instruction sequences". That doesn't sound like a robust way to detect malicious code.

Why not? It just means that the permissible instruction sequences are limited to a subset that can be statically analyzed and verified to be safe. The Java VM has similar verification algorithms that are run whenever untrusted code is first loaded.

It's true that this does not allow all x86 code to run; it's at least practically (and probably theoretically) impossible to correctly determine whether or not a piece of code is safe, but as long as the VM errs on the side of caution, there shouldn't be any problems with this approach.

I will grant that this makes it unclear what the advantage is over (say) Java applets. What can this technology do that the Java VM couldn't? As far as I'm concerned, the failure of Java in the browser has more to do with the lack of a standard library for high-performance multimedia applications (think: Flash) than with shortcomings in the bytecode language.

All this means is that google have created a VM in which the "bytecodes" happen to be executable on real hardware, but some of these "bytecodes" have to be intercepted and replaced at runtime with substitute code... this aught to sound familiar; this is what a software hypervisor does (eg VMware).

In other words every man and his dog has jumped aboard the "I can write an x86-hypervisor" bandwagon, the difference being that google have decided to take theirs and embed it into the browser rather than run as a standalone app.

Interestingly enough it took the momentum that VMware created to get intel to correct some of the issues with its' ISA to make it much easier to virtualise, perhaps someone the size of google can prod intel into adding a third wave of virtualisation accelartion extensions to their ISA so as to make this idea safer* with low overhead

*I think virtualisation is a useful thing (I make a living from consulting on it), however I am unconvinced of it being possible, to truly secure it.

Basically the current kernel memory allocator does not typically stop long idle memory being swapped out to make room for pagecache in the updatedb case (you can see the the Linux swap problem being discussed back in 2004 when the allocator had already been set). The classic "OpenOffice left overnight is swapped out by early morning updatedb run" problem is still here (because OOo memory has been idle for so long).

While there is an madvise option to make mmaped memory dodge the page cache there is a need for more. As recently as 2007 there have been attempt to try and let userspace warn the kernel that what it is going to do shouldn't stay in the pagecache, but it's unclear how far it progressed. The current solution seems to be "don't run updatedb".

Basically the current kernel memory allocator does not typically stop long idle memory being swapped out to make room for pagecache in the updatedb case (you can see the the Linux swap problem being discussed back in 2004 when the allocator had already been set). The classic "OpenOffice left overnight is swapped out by early morning updatedb run" problem is still here (because OOo memory has been idle for so long).

While there is an madvise option to make mmaped memory dodge the page cache there is a need for more. As recently as 2007 there have been attempt to try and let userspace warn the kernel that what it is going to do shouldn't stay in the pagecache, but it's unclear how far it progressed. The current solution seems to be "don't run updatedb".

Realtime priority causes lockups if the program isn't written properly. Believe me, I've tried it out on several programs (the X server, mplayer, and others) with disastrous consequences.

What you probably want is the nice value. Giving the X server say -5 or -10 does seem to help a little. Then again, what you want is immediate response, which tuning the kernel's number of timer ticks per second (CONFIG_HZ) and turning on kernel preemption helps much more. I think both are new in kernel 2.6.x. This increases overhead and possibly risk unstability, but your perceived speed will increase.

With mplayer, back when I had the ticks per second at 100, I noticed frames would sometimes stall then skip through really fast for a split second. At higher speeds (300 or 1000) the problem disappeared.

You may be interested in: Which is better -- the preempt patch, or the low-latency patch? Both! .... Feature: Robert Love Explains Variable HZ

Realtime priority causes lockups if the program isn't written properly. Believe me, I've tried it out on several programs (the X server, mplayer, and others) with disastrous consequences.

What you probably want is the nice value. Giving the X server say -5 or -10 does seem to help a little. Then again, what you want is immediate response, which tuning the kernel's number of timer ticks per second (CONFIG_HZ) and turning on kernel preemption helps much more. I think both are new in kernel 2.6.x. This increases overhead and possibly risk unstability, but your perceived speed will increase.

With mplayer, back when I had the ticks per second at 100, I noticed frames would sometimes stall then skip through really fast for a split second. At higher speeds (300 or 1000) the problem disappeared.

You may be interested in: Which is better -- the preempt patch, or the low-latency patch? Both! .... Feature: Robert Love Explains Variable HZ

Linux kernel maintainer Andrew Morton sets his swappiness to 100 (page as much physical memory as you can, the opposite of this Ask-Slashdot's desires), which he justified in an interview (see above link) by saying:

My point is that decreasing the tendency of the kernel to swap stuff out is wrong. You really don't want hundreds of megabytes of BloatyApp's untouched memory floating about in the machine. Get it out on the disk, use the memory for something useful.

Of course, there's another view, also presented at the above kerneltrap article: If you swap everything, you'll have a very long wait when returning to something you haven't touched in a while.

If you have limited resources, milk the resources you have plenty of; workstations should have high swappiness while laptops, who suffer in disk speed, disk capacity, and power, are probably better suited with lower swappiness. Don't go crazy, though ... swappiness = 0 is the same as running swapoff -a and will crash your programs when they need more memory than is available (as the kernel isn't written for a system without swap).

I recall back in 2002 or so, a friend of mine maxed out his Windows XP system with 2gb of memory. Windows absolutely refused to turn off paging (swap), forcing him to whatever the minimum size was. The solution? He created a RAMdisk and put the paging file there.

On Linux (and other modern systems, perhaps now including Windows), you can turn off swap. However, the Linux kernel's memory management isn't so great at the situation you hit when you need more memory than you have, but you can't swap. Usually, the memory hog crashes as a result (thankfully, Firefox now has session restore). I might be slightly out of date on this one.

A well-tweaked system still has swap (in nontrivial amounts), but rarely uses it. Trust me, you can afford losing the few gigabytes from your filesystem. Again in Linux, /proc/sys/vm/swappiness can be tweaked to a percentage reflecting how likely the system is to swap memory. Just lower it. (Though note the cons to this presented at the kerneltrap article above.) My workstation currently has an uptime of 14 days, a swappiness of 60, and 42/1427 megs of swap in use as opposed to the 1932/2026 megs of physical memory in use at the moment.

This is summarized for Windows and Linux on Paging at Wikipedia.

Hey, ext4 actually speeds up fsck quite a lot, so maybe ext4 won't be around a lot of time ;)

Go read the link again - note that Theo was talking about the OpenHAL code. http://kerneltrap.org/mailarchive/openbsd-misc/2007/9/13/259448/thread

OK, I read the entire thread. As I did so, I realized that it looked familar. I think that I read the whole thing a year ago in response to an earlier posting here. It struck me then as a tempest in a teapot. It still does.

Since Mr. Reyk hasn't filed suit, it's totally academic what the 'madwifi fuckers' did or did not do.

In other words, if a copyright owner chooses not to bring a lawsuit, no one else can bring one on his/her behalf. So yes, any discussion of what happened is academic, just like discussions about Lori Drew or Hans Reiser. You can discuss and argue all that you want, but nothing you say will have any legal standing. Maybe, if enough people scream about something, you can encourage a prosecutor to look into something (as apparently happened with Lori Drew), but since copyright cases are civil suits, not criminal cases, I don't see you making much headway there. I don't know why Mr. Reyk hasn't filed a suit. Maybe he's lazy. Maybe he and the accused have a private understanding that we know nothing about. Who knows? I don't know and I don't care.

Since Mr. Reyk hasn't filed suit, it's totally academic what the 'madwifi fuckers' did or did not do.

For someone who make such strong claims on being intellectually correct, this is an interesting position to take. So, in your world, as long as no suit is filed, any action taken is just "totally academic"?

If you have an axe to grind, take it up with them.

I don't really have an axe to grind. It's just two people in the madwifi group that did that "totally academic" but unethical thing. And have not apologized for it.

If, alternately, you have a thoughtful and reasoned criticism (and preferably some strong evidence for your allegations), please share it.

Umm... you did not manage to follow the original link that I had originally responded to? Would you like a signed and sealed piece of paper? Go read the link again - note that Theo was talking about the OpenHAL code. http://kerneltrap.org/mailarchive/openbsd-misc/2007/9/13/259448/thread

If you want to look for evidence, you can find it yourself. OpenBSD's CVS is open. I'm sure madwifi's repository is available too. Look at code check in dates. Make up your own mind. *big hint* OpenBSD's OpenHAL is dated a year earlier, according to 3rd party reports. Please do not let this *big hint* color your perception or conclusion. KTHXHAND

But once in a while the manufacturer suggests installing another BIOS, which is available only as an executable. This, clearly, is installing a non-free program--it is just as bad as installing Microsoft Windows, or Adobe Photoshop. As the unethical practice of installing another BIOS executable becomes common, the version delivered inside the computer starts to raise an ethical problem issue as well.

Reyk Floeter, an OpenBSD developer, explains his position like this:

there is a major difference between binary blobs and firmware images; the blobs are loaded as code into the OS kernel, but the firmware runs directly on the device on crappy embedded micro CPUs. asking the vendors for releasing their firmware source code is just ridiculous or a nightmare since I don't even want to see this code

OpenBSD likes the ISC license. deRaadt was a bit unhappy with the old arrangement.

I believe that the OP referred to that OpenBSD have been quite strong in their opposition to blobs in the OS. On the other hand they don't seem to mind unfree firmware.

I believe that the OP referred to that OpenBSD have been quite strong in their opposition to blobs in the OS. On the other hand they don't seem to mind unfree firmware.

Nope.

http://kerneltrap.org/node/6497
http://www.onlamp.com/pub/a/bsd/2006/04/27/openbsd-3_9.html
http://kerneltrap.org/blobs

Nope.

http://kerneltrap.org/node/6497
http://www.onlamp.com/pub/a/bsd/2006/04/27/openbsd-3_9.html
http://kerneltrap.org/blobs

1. I don't know if RMS has ever stopped anyone from anything physically, but he talks tough. (see the section on Non Free Software) He says if you create proprietary software you must stop and do something else instead. I am not arguing that he is physically forcing anything, however I can see how he would if he were a dictator and he certainly has a mindset of one. That's my main point of contention with this person.

2.

* Every single one of us is going to end up dead. If you have something that you believe in, -especially something that doesn't hurt others- don't you owe it to yourself to spend the time that you have in service of that belief? You're never going to get to try again. Ever.

- hey, go for it, do whatever you want, preach whatever you want, just don't expect others to follow you into that perfect world you have created in your head.

The link to the article where RMS says that developers must not develop proprietary software as a matter of idealism and go do something else instead.

(Non-free software section).

He does no such thing. You are free to develop, market, and sell your own code however you like.

- ORLY?!

Richard Stallman: Any development of non-free software is harmful and unfortunate, whether it uses GNU tools or other tools. ...

JA: How do you react to the opinion that non-free software is justified as a means for raising dollars that can then be put into the development of completely new software, money that otherwise may not have been available, and thus creating software that may have never been developed?

Richard Stallman: This is no justification at all. A non-free program systematically denies the users the freedom to cooperate; it is the basis of an antisocial scheme to dominate people. The program is available lawfully only to those who will surrender their freedom. That's not a contribution to society, it's a social problem. It is better to develop no software than to develop non-free software.

So if you find yourself in that situation, please don't follow that path. Please don't write the non-free program--please do something else instead. We can wait till someone else has the chance to develop a free program to do the same job.

JA: What about the programmers...

Richard Stallman: What about them? The programmers writing non-free software? They are doing something antisocial. They should get some other job.

My reply to that article was exactly the same as the reply of the GP here.

Yet for many, the Mac remains sluggish and poorly tuned for development, with developers citing its virtual memory system's poor performance in paging data in and out of memory

As opposed to the Windows paging system? Has the author used a Windows OS lately? Swapping is a *bleeping* killer! Especially when you have more than enough memory not to swap. :-/

Well, here we go with another "I've got lots of RAM I don't need swap" thread:

What's going to happen when you have a runaway application that allocates all of your RAM at the expense of other apps, sure it well eventually be OOM'd but you loose swaps' ability to lessen the effect via LRU.

More-so is the fallacy that without swap there will be no disk activity when freemem falls near to zero. In actual fact the kernel will start purging part of the buffer-cache, which means that everytime you access a page of a binary or of a library it'll have to re-fetch from the filesystem.

Unless of course, your binaries and libraries are all stored on ramdisk too you'll hear the click of servo motors, and the whirr of platters.

(There's quite a long discussion of this here)

likening use of the default-network file system, AFS, to engaging oneself with 'some kind of passive-aggressive torture.

So don't use it. Macs support CIFS/SMB pretty darn well these days. I keep hoping that someone will come up with a better replacement, but CIFS/SMB will continue to work until that day comes.

Unfortunately SMB is not the most desirable protocol from a security or performance standpoint.

AFP hasn't been updated to support any filesystem metadata except for resource forks, making it not particualarly useful, and...

Apple's NFS implementation is so buggy that it is completely unusable.

"You can even be a programmer. Most paid programmers are developing custom software--only a small fraction are developing non-free software. The small fraction of proprietary software jobs are not hard to avoid." Richard Stallman

"Programmers could develop custom software by day, develop general purpose free software for fun. Or pay people for developing free software. Or sell support, or copies of free software." Richard Stallman

It seems RMS fully supports the idea of paid software development. I wonder why so many people think differently - poor reporting, or just personal bias?

Here's the problem:

Let's say that we live in RMS's ideal world, and all software that exists is FOSS.

Say I want some software developed that doesn't exist yet.

I can either:

• pay a developer to write it, or
• I can sit around and hope that someone else with deeper pockets and a more urgent need will pay a developer to write it, and that it'll be released under a free license, and then I can simply make use of it.

And there you go. Rather than taking initiative and doing something, it becomes advantageous to sit around and wait and hope that someone else will do it for me.

"Leeching" innovation in this way doesn't advantage the state of the art, but it does advantage leechers who can afford to sit back and wait forever if need be.

If you're a company and your choice is to lead or to leech, the only benefit you gain in leading is that you control the direction of software development, because you're the one funding it.

However, if every one of your competitors can derive just as much benefit from your capital investment simply by sitting around, waiting for you to release a FOSS solution to everyone's problem, then your competitors are going to eat you alive because they don't have to foot the development costs, yet can recoup all of the ROI without having to put up the I.

So, sure, Stallman supports paying people to program. But, so say the objectors, in Stallman's ideal world, no sane company would ever want to pay developers for work that they could get for free by virtue of their competitor doing all the work and releasing it for them.

In reality, I think that the demand for software will force someone to put the money up for its development. Rather than being proprietary products wholly owned and controlled by a corporation like Adobe or Microsoft, we'll see groups and non-profits like Mozilla and Canonical making contributions to open projects, and getting their funding from corporate sponsors that need them.

But there will also be a tremendous amount of software that simply won't get written, because there's no way to turn it into a product and sell it to directly recoup the costs of its development.

The software development ecosystem is probably healthiest when all models are permitted to flourish. FOSS is the best option, if you can get a community to sustain the developers; for small-scale niche projects hobbyist development is OK; but for certain types of software (large-budget games, perhaps?) proprietary just makes the most sense.

This isn't Stallman's pure utopian vision, however, and if a developer can't keep his source closed and sell compiled binaries if that's what he wants to do, then he isn't truly free, even though his software might be.

"You can even be a programmer. Most paid programmers are developing custom software--only a small fraction are developing non-free software. The small fraction of proprietary software jobs are not hard to avoid." Richard Stallman

"Programmers could develop custom software by day, develop general purpose free software for fun. Or pay people for developing free software. Or sell support, or copies of free software." Richard Stallman

It seems RMS fully supports the idea of paid software development. I wonder why so many people think differently - poor reporting, or just personal bias?

I'd wish he'd drop dead but that may just make him a bigger "hero" for more RMS goodness see: http://kerneltrap.org/mailarchive/openbsd-misc/2007/12/10/486713 *sigh* The guy is nothing short of mental

The Linux kernel has been GPLv2 for a long time. If Sun wanted ZFS support in Linux they could have made it work easily. The license they chose, and the patents they hold, allow them to call it "open source" while avoiding the possibility of native support in the most popular open-source alternative to their own Solaris operating system. I don't think that's a coincidence.

A much more detailed debate on the LKML is summarized on KernelTrap in support of my position. About a third of the way down the page you'll find this quote: "there are senior Sun programmers who have on record stated that one of the reasons why Sun picked the CDDL was precisely because it was incompatible with GPL and Sun fears Linux."

SMP support is has been here quite awhile.

I suppose you consider PF, OpenSSH, and all the other things cooking in -current to be far behind too?

He didn't know any of this, because he only heard it from somebody else (who probably didn't know what they were talking about), and subsequently blew it out of proportion.

Actually, it sounds like you only heard this from somebody else (who probably didn't know what they were talking about), and subsequently blew it out of proportion. He doesn't claim it contains non-free software, but that it suggests non-free software, which is true. To quote from his e-mail to the OpenBSD-misc mailing list,

From what I have heard, OpenBSD does not contain non-free software (though I am not sure whether it contains any non-free firmware blobs). However, its ports system does suggest non-free programs, or at least so I was told when I looked for some BSD variant that I could recommend. I therefore exercise my freedom of speech by not including OpenBSD in the list of systems that I recommend to the public.

Sounds like he understood the issue well, and if you know about his philosophy, its extremely clear why he won't recommend OpenBSD. By doing so, he would recommend the ports system that suggests the use of non-free software, and by recommending it he will implicitly also suggest the non-free software.

And to clear things up, OpenBSD does not contain non-free blobs in the kernel, and they even themed their 3.9 release on this issue. Because the emphasis is on security, they did so for primarily for security reasons. In a sense, the OpenBSD kernel really is more free than the Linux kernel you get with most distributions, as many distributions include non-free binary blobs with the kernel (including Ubuntu). To push this point through,

The fact that OpenBSD is not a variant of GNU is not ethically important. If OpenBSD did not suggest non-free programs, I would recommend it along with the free GNU/Linux distros.

It is entirely about the ports system. Other than that, he's all for it. In fact, I doubt you will find him telling people not to use OpenBSD, but rather warning them to be careful with the ports system.

You don't have to agree with him, but at least get the facts right about his argument.

He didn't know any of this, because he only heard it from somebody else (who probably didn't know what they were talking about), and subsequently blew it out of proportion.

Actually, it sounds like you only heard this from somebody else (who probably didn't know what they were talking about), and subsequently blew it out of proportion. He doesn't claim it contains non-free software, but that it suggests non-free software, which is true. To quote from his e-mail to the OpenBSD-misc mailing list,

From what I have heard, OpenBSD does not contain non-free software (though I am not sure whether it contains any non-free firmware blobs). However, its ports system does suggest non-free programs, or at least so I was told when I looked for some BSD variant that I could recommend. I therefore exercise my freedom of speech by not including OpenBSD in the list of systems that I recommend to the public.

Sounds like he understood the issue well, and if you know about his philosophy, its extremely clear why he won't recommend OpenBSD. By doing so, he would recommend the ports system that suggests the use of non-free software, and by recommending it he will implicitly also suggest the non-free software.

And to clear things up, OpenBSD does not contain non-free blobs in the kernel, and they even themed their 3.9 release on this issue. Because the emphasis is on security, they did so for primarily for security reasons. In a sense, the OpenBSD kernel really is more free than the Linux kernel you get with most distributions, as many distributions include non-free binary blobs with the kernel (including Ubuntu). To push this point through,

The fact that OpenBSD is not a variant of GNU is not ethically important. If OpenBSD did not suggest non-free programs, I would recommend it along with the free GNU/Linux distros.

It is entirely about the ports system. Other than that, he's all for it. In fact, I doubt you will find him telling people not to use OpenBSD, but rather warning them to be careful with the ports system.

You don't have to agree with him, but at least get the facts right about his argument.

You can get a dump of usage pretty smply now days (echo 1> /proc/sys/vm/block_dump), but it's going to be slow logging via syslogd to local disk. And you only get reads from files not dirs.

Or you can use blktrace haven't done that myself.

Well I guess if I ever plan on encoding an extensive number of movies and music, I'll just reinstall 7.04. Hmmm, this couldn't have anything to do with the many applications that do not yet take advantage of the latest kernel features could it? There have been major advancements in kernel development in the last 2 years, too many to list just go here and read a little: http://kerneltrap.org/

See instead: Linus Torvalds