Slashdot Mirror

Whoa calm down! It doesn't matter if Linux actually infringes or not, corporations will still be leary about adoption as long as there are claims out there that it does. That it is the exact definition of encumbered, the adoption of Linux is impeded by a heavy load, that being the bad publicity from the SCO and Microsoft/Novell fiascos.

Do you remember this issue, when there was a BSD driver that was included in Linux and was re-licenced as GPL by mistake? Or how about this one, where the OpenBSD project stripped the comments from a GPL'd driver and re-licensed it as BSD? Obviously there are some copyright issues slipping through the cracks even among the different OSS projects. Since Linux has so many contributors from so many different places, it is easy for a company to start spreading claims that one piece, somewhere, might be infringing.

As soon as the corporate lawyers get wind of that kind of thing, they'll push to avoid adoption and to migrate solutions away from Linux. Look at the Unisys LZW patent in GIF files or the Fraunhofer patents in MP3 files. Companies were panicking because they might have an MP3 stored somewhere, without any understanding of the actual issue.

You're just walked square into the middle of the "free software" vs "open source" debate. Now they've got you right where they want you, there is no escape!

Picasa is free (and awesome) but not open source - so Ubuntu and Fedora will never ship it.

I think you have it backwards. The "open source" crowd would happily use non-free software if they believe it is the best. The "free software" crowd would not touch Picasa. See this article for an example (jump to "bitkeeper issue").

You may be confused because of the two meanings of the word "free". It is sad that in the English language, the word for a concept as great as "freedom" is the same as the word for the meager idea of "no cost".

Of course, there are several shades of grey in between the two camps, but that is the main difference.

(That said, neither Ubuntu nor Fedora are very strong supporters of "free software"... specially not Ubuntu. It wouldn't surprise me that one of them decided to include picasa)

Not that I'd ever claim that the BIOS is wonderful either, but at least
everybody knows that the BIOS is just a bootloader, and doesn't try to
make it anything else.

http://kerneltrap.org/node/6884

I quite like Linus on EFI:

...EFI has this cool shell, a loadable driver framework, and other nice features. Where "nice" obviously means "much more complex than the simple things they designed in the late seventies back when people were stupid and just wanted things to work".

Linus continued in a followup email, "don't get me wrong - the problem with EFI is that it actually superficially looks much better than the BIOS, but in practice it ends up being one of those things where it has few real advantages, and often just a lot of extra complexity because of the 'new and improved' interfaces that were largely defined by a committee." He went on, "so EFI has this cool shell, a loadable driver framework, and other nice features. Where 'nice' obviously means 'much more complex than the simple things they designed in the late seventies back when people were stupid and just wanted things to work'. Of course, it's somewhat questionable whether people have actually gotten smarter or stupider in the last 30 years. It's not enough time for evolution to have increased our brain capacity, but it certainly _is_ enough time for most people to no longer understand how hardware works any more." As for BIOS, Linus noted, "not that I'd ever claim that the BIOS is wonderful either, but at least everybody knows that the BIOS is just a bootloader, and doesn't try to make it anything else."

Useless abstraction layers are useless.

The problem is that the RT2500 chipset is proprietary, closed-source that's "maintained" by a Taiwanese manufacturer who doesn't care about his users at all and only wants to sell cheap hardware and as much of it as possible.

Well, actually, Ralink has for a long time been providing documentation to open source developers writing drivers for their devices, without requiring an NDA.

• http://www.thejemreport.com/content/view/293/
• http://kerneltrap.org/node/6550

The Citrix stuff had little to do with it. Th Linux kernel developers favor code that is easy for them to integrate and maintain, and KVM fit better into that model than Xen. There are some situations where it performs quite a bit better too, and frankly few people care about those stuck with processors that don't have the right extensions to use KVM. Some good reading on the background here includes Discover the Linux Kernel Virtual Machine, Linux: KVM Paravirtualization, and The truth about KVM and Xen.

There are signs of life at KernelTrap (http://kerneltrap.org/).

There have been a number of postings by Jeremy since the beginning of April.

The porting of ZFS to NetBSD is in progress.

http://wiki.netbsd.org/users/haad/porting_zfs/

NetBSD is also seeing work done on integrating DTrace, incidentally.

http://mail-index.netbsd.org/tech-kern/2010/02/15/msg007333.html

I'm not very familiar with DragonFlyBSD, but they have a different approach called HAMMER.

http://kerneltrap.org/DragonFlyBSD/HAMMER_Filesystem_Design

Anyone know a good place to get access to ZFS in another place? Would BSD or FUSE on Linux be better?

FreeBSD - ZFS is no longer in experimental status as of version 8.0. I haven't heard anyone recommend FUSE on Linux. As far as other BSDs go, I know that at least OpenBSD has no plans to include it at this stage.

http://kerneltrap.org/mailarchive/openbsd-misc/2009/1/17/4750954 - But that was over a year ago.

At the moment I'm learning FreeBSD over OpenSolaris because I want ZFS, FreeBSD is fully free and open source, FreeBSD looks to have a wider array of ports, which should be easy to install, even though with the LiveCD of OpenSolaris it boots up straight to X. On a production server or maybe even workstation, I think the choice would be down to FreeBSD versus Solaris, rather than OpenSolaris. Someone correct me if I'm wrong. Solaris does have a lot of nice features though, FMA (fault management architecture - lets you know when something has gone kaput and what to do about it.) And FreeBSD will lag in terms of the version of ZFS it supports. Deduplication looks to be a pretty cool feature - if you copy some data to another part of the HDD, and then you leave it a bit and your hoarding nature kicks in and you don't know whether you can delete it or not - no fear, ZFS will recognize the data as the same, only store it in one place (unless modified of course) and so there is no benefit to deleting the copy other than being a neat freak.

I'm presently wrestling with setting up FreeBSD on wireless. After that I have to get X set up. It would be nice if FreeBSD had version specific handbooks ala PostgreSQL, but they don't. So it's a combination of man pages, handbook, googling, etc to get me where I want to go. It's a bit of a contrast to Ubuntu which I set up on another box in the space of about an hour, including updates. Unmetered FOSS mirrors on ISPs kick ass!

Anyway, I suspect that the user base of FreeBSD will grow by leaps and bounds when people realize the advantages of ZFS and don't want to wait for BTRFS or whatever the results of this meeting might be: http://blogs.sun.com/bonwick/entry/casablanca

That's strange, I find that behavior much worse in Linux (i.e., Linux is more aggressive swapping out applications). I usually tune the "swappiness" (see http://kerneltrap.org/node/3000 ) to very low levels, but sometimes after having to wait a few seconds each time I switched to some huge application such as NetBeans made me disabled the swap space.

If the RAM is needed for another purpose the blocks can be freed by simply changing a flag and mapping them as quickly as if they had been totally free. This does not slow things down. After a while most of the blocks you need will be in RAM when you need them. Thus caching makes the system faster, not slower.

The above describes Linux. I assume Windows works similarly.

As I understand other comments to this article, Windows runs at the equivalent of 100% swappiness, making the system far more likely to evict a process from RAM than to evict things from disk cache. Writes are slower than reads, especially on a RAID or on a laptop with a low-cost SSD. Or to express it more graphically:

8==D : Swappiness on Linux properly tuned for slow writes
8=========D : Swappiness on a Windows box

Assuming, of course, that you're not running any binary blobs like, for example, the nVidia driver that had a remote exploit allowing an attacker to gain kernel privilege and wasn't fixed two years after it was first reported. No one outside of nVidia could audit the code and fix it, but other people (like the person who reported it) had found it and were able to exploit it.

Someone tried something similar to that.

When did the linux kernel deprecate it? Like a decade ago?

Depends on your definition of "deprecate" and "decade". As late as last year (2008), the kernel people were still working on removing it.

most GPL code, including most of Linux, was simply taken from BSD sources and relicensed GPL. What you would do better to look at are clean GPL implementations

Conjecture

Er no, experience rather, from having worked with both GPL and BSD code for many years.

I am not aware of wholesale re-licensing just for the sake of it.

You're not aware of the Atheros relicensing then?

    http://kerneltrap.org/OpenBSD/Atheros_Driver_Developments

Where BSD code HAS been incorporated into GPL it has been done to comply with the BSD license, exactly as intended by the author

That's a novel way of looking at it, but it doesn't really hold water. The Atheros developers certainly did not want their work published under the more restrictive GPL. They, like myself, want all developers to benefit from our code, not only those who agree to publish deltas under the GPL exclusively. But then the GPL never has been about giving.

    http://lwn.net/Articles/247872/

I don't get where the resentment comes from

Conjecture! ;-) The resentment is in your assumption, it was neither intended in nor implied by the original message. So go ahead and downmod (again) anything critical of the GPL, just be aware that when you do you move Slashdot further from the facts and closer to a popularity contest.

It's possible for ZFS, but not really wanted. And it's also a HUGE job.

Btrfs (a work in progress for now) is better than ZFS: http://lwn.net/Articles/342892/

ZFS is protected by patents http://kerneltrap.org/node/8066. A binary compatible rewrite in GPL wouldn't be legal. Thanks again `Free as in Freedom' GPL ;)

The main corner case in your suggested "unit file" implementation is where someone is overwriting a file too large for the filesystem to contain two copies of it. You have to truncate when this happens to fit the new one, you can't just keep the old one around until it's replaced.

At that point, the program creating the huge file should get an I/O error, and the old copy should be intact. If you're creating files that big, you usually check the available space before writing the file, as installers have done for many years now. You may have to delete the old file first. UCLA Locus did this in the 1980s, incidentally, and some of that machinery went into AIX. (Locus had unusual file system semantics. If you started to overwrite a file, you created a new file which shared blocks with the old one in a copy-on-write sense. The new file appeared to other readers when you closed the file or called "commit()". If you called "revert()" or the program crashed or the network disconnected, the file reverted to its previous state.)

As for your "managed files" case, that won't work for all database approaches.

Torvalds has written about how databases should talk to file systems. Databases and file systems need to know something about each other. There's posix_fadvise() and fsync() as well as the open modes, and the use of any of those generally indicates that it's a managed file.

That's why to the greatest degree possible, libraries, programs, and algorithms should be auto-tuning. You can provide all the knobs you want, but people won't actually touch them.

I've seen a push for a pluggable process scheduler in the Linux kernel, starting almost two years ago. To this date, Linus has refused to include it in his kernel and I have to say I agree to that.

Speaking of fine-grained locking, how much of the BKL is left in Linux? I know they've been getting rid of it for a long time, and it's mostly gone. But I thought there were a few paths that used the BKL, and ioctl was one. For instance...

On May 15, 2008, the BKL was returned to non-preemptible. http://kerneltrap.org/BKL

On Oct 10, 2009, the BKL was removed from soundcore_open. http://groups.google.com/group/linux.kernel/browse_thread/thread/d4d323a4781f1c05

On Oct 15, 2009, the BKL was removed from the realtime clock on the 68000 arch. http://www.gossamer-threads.com/lists/linux/kernel/1142631?page=last

In 2008 there were 1300+ uses of BKL, and it looks as if they've been chipping away. Any idea what's left?

The Linux Kernel has 3 schedulers in the mainline:
- Anticipatory http://www.kernel.org/doc/Documentation/block/as-iosched.txt
- Deadline http://www.kernel.org/doc/Documentation/block/deadline-iosched.txt
- CFQ http://kerneltrap.org/node/8082

Linux containers give you jail-type functionality and - unlike VServer and OpenVZ - are in the mainline. http://lxc.sourceforge.net/

The OpenVZ people have, I understand, been a strong force in getting the container stuff into mainline.

There was an LSM implementing BSD-style Jails but I'm not sure what happened to it ... http://kerneltrap.org/node/3823

Welcome back Con! I wonder how long it is before Ingo "Kudos Con" Molnar rips of the new design? The kernel team has developed a very bad case of "not invented here." http://kerneltrap.org/node/8059

The "bad maintainer" part is referring to bad blood over the adoption of Ingo Molnar's CFS over Kolivas's own RSDL

Yeah but Con just didn't give the impression that he intended to be around to support his code. He is an anaesthetist. Software is a hobby which he could give up whenever he wants to. I think that is very different from somebody who is doing software for their career.

Oh yeah, and which other scheduler's, if any, did this guy write?

SD scheduler

My question is: is it in the kernel tree yet? Is this that 2.6.31 scheduler change I heard about earlier yesterday, or is it something Completely Different?

No, and probably won't ever be, though perhaps some ideas will be borrowed.

From his FAQ:

Are you looking at getting this into mainline?

LOL.

No really, are you?

LOL.

Really really, are you?

No. They would be crazy to use this scheduler anyway since it won't scale to
their 4096 cpu machines. The only way is to rewrite it to work that way, or
to have more than one scheduler in the kernel. I don't want to do the former,
and mainline doesn't want to do the latter. Besides, apparently I'm a bad
maintainer, which makes sense since for some reason I seem to want to have
a career, a life, raise a family with kids and have hobbies, all of which
have nothing to do with linux.

Can it be made to scale to 4096 CPUs?

Sure I guess you could run one runqueue per CPU package instead of a global
one and so on, but I have no intention whatsoever at doing that because it
will compromise the performance where *I* care.

The "bad maintainer" part is referring to bad blood over the adoption of Ingo Molnar's CFS over Kolivas's own RSDL, in particular at least one LKML poster suggesting that, all else being equal, it'd be better to merge Molnar's code, as he was more likely to be a reliable maintainer (Molnar's more tied into the workings of the mainline kernel development/merging/etc.).

Some years ago, the kernel development model version numbering had changed, and at some point Linus basically said there would probably not be an unstable 2.7.x series, ever, except that they might want to number the version after 2.6.99 2.7.0 instead of 2.7.100, just to keep the numbers short.

In all likelihood, 5 years from today, the kernel will still be 2.6.x.

We won't: http://kerneltrap.org/mailarchive/linux-kernel/2008/7/15/2497614

Yeah right Compiler bugs don't really exist, and this one was found by Linus Torvalds maybe someone ought to fire him, it is not the compiler it is his kernel source code. :)

She must have been using Visual BASIC and found a bug.

As a Programmer I usually try to write code around the bug by defining my own functions to replace DLLs and API calls.

When I did so in college back in 1986 it was Turbo Pascal and it had a rounding bug in the compiler. So what I did was write my own rounding function by converting the floating point into a string and then operated on the string to round up and avoid the rounding bug. I was the only one in my class to get the correct answer, but I got a C because I didn't get the same answer as the rest of the class due to a bug in the rounding function. I was accused of 'hacking" and told that writing my own rounding function was illegal use of the language. I felt like Captain Kirk in the Kobayashi Maru scenario, I programmed it so that it was possible to win, but in doing so instead of being celebrated for being innovative I was punished instead. But then later the Star Trek remake made more sense to me. :)

So, where's your example?

Structured Programming with go to Statements (Donald Knuth) (Note: PDF file).

Linus et al. on the use of goto statements in the Linux kernel

Is the kernel compiled to be tickless? http://kerneltrap.org/node/6750

"Formally proving" a kernel is something like formally proving your memory allocation algorithm will never fail, providing there's infinite memory available, proving your IO is perfect, providing there's 0 latency, infinite bandwidth and storage, and your security is unbreakable, providing absolutely everything is protected by one-time pads.

In real life, the situation is best described by the old saying: no battle plan survives first contact with the enemy. Kernel bugs are surely not uncommon but at most contribute to about 50% of the system (in)stability - the other half being the "real world" with which the kernel interacts: hardware, its greater environment (e.g. the network) and users. The kernel might be perfect, but at the same time can very elegantly go to pieces the first time it receives an invalid ATA response due to a flaky cable or it misses and interrupt timing because memory allocation algorithms take a little bit too long to defragment or find free space, or the users sets the root password to "god" and leaves a root-login-enabled sshd running. Even CPUs themselves have bugs.

In short, it's nice but the world will not suffer much if other popular kernel don't ever get to be formally proven.

There's an exception allowing binary modules for the Linux kernel.

Well, okay, it's not an exception, exactly. Linus simply doesn't consider all possible kernel modules to be "derived works".

http://kerneltrap.org/node/1735

Disagreement and thinking that the FSF is controlling and putting its fingers where they don't belong is _not_ misunderstanding. It's just not "blind and unquestioning obedience".

Their additions - whether they be "modules" or just the UI - do not, necessarily, fall under the GPL. (Yes, there have been discussions about whether a kernel module is a derived work, but most of the time those discussions ended "Legally they aren't, even though I feel they should be")

If you want to use GPL for a library.. take a look at the LGPL...

In 2003 Alan cox stopped kernel development for a year whilst he learnt Welsh.

http://kerneltrap.org/node/759

It seems he left with little notice then (although he was maintaining the older kernel - 2.2) . Kernel development still continued in his absence....

Well what's happened before with BSD licensed code is some numpty has made a couple of minor changes, which was enough to let them relicense it under the GPL, keeping within the letter if not the spirit of the licenses.. At least this way Microsoft has control over GPL2 versus GPL3

Funny, I thought the spirit of the BSD licence was "do whatever you like as long as you give credit".

Well what's happened before with BSD licensed code is some numpty has made a couple of minor changes, which was enough to let them relicense it under the GPL, keeping within the letter if not the spirit of the licenses.. At least this way Microsoft has control over GPL2 versus GPL3

Linux fixes this by using the aforementioned new compiler option to not have the NULL pointer check optimized away.

Really? I thought the fix was http://kerneltrap.org/mailarchive/git-commits-head/2009/7/7/6148853 . Can you show me where this is reverted in favor of changing the compiler options?

The patch.

No foaming at the mouth tantrums that someone is using your code and not kissing your fat ugly ass in reverence.

Oh, really?

To be bad enough that these low-end board shops would reject it this Marvell part must be truly heinous. Asus et al. usually don't hesitate to ship boards with badly flawed components. Cox talked about this a few years ago.

If you want good SATA avoid the third party chips these board makers integrate. Especially the RAID crap. Wait for Intel to build it into their regular chipsets.

Isn't that already the case with most of the free software anyway? I mean not many people might be contributing to every project, but I don't think that is because the core team wouldn't accept outside contributions. In fact, what the hell does "outsider" mean in this context? I suppose anyone is usually free to start contributing to any project they like; usually it is hard to get accepted as part of the team but that is mostly because you can't expect to just get up one morning and figure out everything about an already existing project or convince everyone that what you want to add is in fact a desirable feature.

The major problem is in fact that people who control a project can be incredibly hostile to doing things that improve usability, and will just not compromise because they see no reason to do so.

A relevant example: Linus's uncompromisingly negative attitude toward Unicode normalization of filenames. OS X's HFS+ filesystem guarantees that all names are stored in normalized UTF-8; Linux's ext3 apparently just lets you use whatever you want. This means that in a Linux system, you could search for a file called Martínez.txt (note the accent on the "i"), search for a file whose name contains the subtstring Martínez, and not get a match because the filename and the search string are using two different representations of the accented "i". Or, from the user point of view, you get a search term that doesn't match itself.

At any rate, you do seem to agree that getting project owners to accept usability contributions is an obstacle. What I want to point out is that very often the obstacle is just not practically surmountable, period.

Secure, yeah sure, adding more code doesn't make it more secure, you'll just have more security bugs:

http://kerneltrap.org/OpenBSD/Virtualization_Security

I didn't said "exception handling", but "error handling", like linux kernel developers use.

Anyway, exceptions in languages like Java which enforces its treatment in compile time are more than just a "goto error handling". It all depends on the language you are using.

If you do go the flash swap route, such as if you're using a subnotebook PC with an SSD, tune your operating system's memory manager to swap less often. (For example, in Linux, set swappiness to 10 percent on machines with slower writes than reads.)

Is there a way to do this on Vista Ultimate 64 bit?

And that's what matters for swap, as pages in memory are 4KiB.

Memory pages on i386 were 4 KiB. In modern x86 CPUs, they're often 4 MiB, which fits a lot better with the 128 KiB to 1 MiB erase blocks of high-capacity flash memory if your operating system supports 4 MiB page mode. But then I'd recommend adding RAM over swapping to flash because it takes a lot more writes for RAM to wear out. If you do go the flash swap route, such as if you're using a subnotebook PC with an SSD, tune your operating system's memory manager to swap less often. (For example, in Linux, set swappiness to 10 percent on machines with slower writes than reads.)

Does OpenBSD have any of the SELinux type security features?

systrace is a different kind of tool. It does allow you to set access policies, but for the system calls. Also, SE Linux is an add-on for the Linux kernels only. Systrace is available for Linux and the BSDs, which would include systrace for OpenBSD, You'll have to check if OS X is still covered.

The reason you can only see 3.2GB or so of RAM in 32 bit versions of Windows is because of hardware I/O reservations.

You left out the part about 32 bit versions of Microsoft Windows not supporting PAE, a feature that has been present in some O/Ses for years. http://kerneltrap.org/node/2450

> what ever happened to http://kerneltrap.org/ ?

Good question. The only explanation I've been able to find is this brief comment at the Kerneltrap Wikipedia page :

"The site is operated by Jeremy Andrews. As of November 2008, Jeremy has stopped updating the site due to a lack of time."

which cites this page as its source. There, Jeremy is stating he will resume updates when he's not so overloaded, and various people are trying to get him to let some volunteers help out.

> what ever happened to http://kerneltrap.org/ ?

Good question. The only explanation I've been able to find is this brief comment at the Kerneltrap Wikipedia page :

"The site is operated by Jeremy Andrews. As of November 2008, Jeremy has stopped updating the site due to a lack of time."

which cites this page as its source. There, Jeremy is stating he will resume updates when he's not so overloaded, and various people are trying to get him to let some volunteers help out.