ZFS On Linux - It's Alive!

lymeca writes "LinuxWorld reports that Sun Microsystem's ZFS filesystem has been converted from its incarnation in OpenSolaris to a module capable of running in the Linux user-space filsystem project, FUSE. Because of the license incompatibilities with the Linux kernel, it has not yet been integrated for distribution within the kernel itself. This project, called ZFS on FUSE, aims to enable GNU/Linux users to use ZFS as a process in userspace, bypassing the legal barrier inherent in having the filesystem coded into the Linux kernel itself. Booting from a ZFS partition has been confirmed to work. The performance currently clocks in at about half as fast as XFS, but with all the success the NTFS-3g project has had creating a high performance FUSE implementation of the NTFS filesystem, there's hope that performance tweaking could yield a practical elimination of barriers for GNU/Linux users to make use of all that ZFS has to offer."

Comments

Why not in the kernel?

[seanadams.com]

The in-kernel vs userland distinction has always struck me as quite arbitrary. So in one case you're linked at compile time and in another case you compile them separately and go through system calls. Why should that make one of them a derivative work and the other not? In either case the file system can be taken out and you still have a perfectly functional kernel that can run other file systems. Same goes for graphics drivers.

The GPL doesn't attempt to codify all the intricate details that it would take to define such a distinction in the license. It's only described as an accepted rule of thumb in the FAQ. So what's the deal? It seems like this rule is really holding back some commercial support for Linux - is the current situation what we really want, and at any rate how did we get here? Would we be better off if such a separable, non-essential feature could be linked in somehow instead of needing to be put behind extra layers of abstraction?

Re:Why not in the kernel?

[vialation]

It has been decided that the deciding factor with the GPL is whether or not something links to it. Instead of a userspace program which simply makes a system call by tripping an interrupt or using the SYSENTER opcode (which would not require kernel source code to do), a kernel module (which, without FUSE, a filesystem must be) actually gets linked into kernel space, and has its symbols added to the kernel. Any calls to other parts of the kernel directly call the kernel. That is the distinction.

Re:Why not in the kernel?

[Anonymous Coward]

The system call provides the gateway, and is the equivalent of a pipeline. If it were not so, there could be no non-GPL2 software on Linux.

Re:Why not in the kernel?

[Anonymous Coward]

And... where exactly is all of that NEWS?

Re:Why not in the kernel?

[TeknoHog]

The in-kernel vs userland distinction has always struck me as quite arbitrary. So in one case you're linked at compile time and in another case you compile them separately and go through system calls. Why should that make one of them a derivative work and the other not?

I agree the kernel vs. userland issue is arbitrary. However, think about all the closed-source software running on Linux, or opensource with other licenses but GPL v2. These are legally possible only because we make the distinction.

Re:Why not in the kernel?

[LWATCDR]

I am not a kernel hacker but I believe you are confusing loadable kernel modules with user space code.
I am pretty sure that kernel modules run at the kernel level and can access all the same structures that a driver compiled into the kernel can.
FUSE file systems run at the same privilege level as a user program does. In theory it is a slower but more robust system. If a FUSE file system crashes you can just restart the filesystem and remount the drive. If a kernel level file system crashes it can cause a kernel panic and bring down the entire system.
So the distinction between user-land and kernel drivers is anything but arbitrary.

Re:Why not in the kernel?

[Anonymous Coward]

Why not just rewrite the ZFS code as GPL or (hopefully) BSD? Suddenly we care about software patents and not reverse engineering things?

Re:Why not in the kernel?

[aichpvee]

Because you can use ZFS on Linux now? Unless you could do that before. I don't use it so I don't know.

It'd be news if Sun would do The Right Thing(tm) and dual license it under the GPL. Though they'd probably go GPL3 and screw everything up just as much.

Re:Why not in the kernel?

[Paul Jakma]

It has been decided that the deciding factor with the GPL is whether or not something links to it.

This is absolutely not true. "It has been decided": When? By whom? This claim is not only unfounded, it is also quite false (just ask a lawyer..).

The parent absolutely should NOT be modded as informative.

Re:Why not in the kernel?

[BrainInAJar]

How is it Sun's fault that the GPL is incompatible with anything other than itself?

The Right Thing(tm) is to keep the license as it is. It ensures the Solaris code has to be shared (like the GPL), but doesn't pollute source code around it ( GPL - viral clause = CDDL. Same license as firefox, or apache)

Linux wanting to pillage from the project isn't a good enough reason to make it impossible for people to write non-GPL drivers for Solaris

Re:Why not in the kernel?

[PygmySurfer]

Why is Sun switching to the GPL the "Right Thing"?

Maybe the "Right Thing" would be for Linux to switch to a compatible license, like the CDDL, or BSD.

Re:Why not in the kernel?

[notamisfit]

The version of the GPL included with the Linux kernel states at the top:

• NOTE! This copyright does *not* cover user programs that use kernel services by normal system calls - this is merely considered normal use of the kernel, and does *not* fall under the heading of "derived work".

Not sure how far back this clarification really goes, but I think it predates the GPLv2-only one, making it at least six years old.

Re:Why not in the kernel?

[jimicus]

Alright then, how about "The de-facto understanding is..."?

The existence of the LGPL goes some way to suggesting that this indeed is the generally accepted understanding. It's not been codified in any legal judgement that I'm aware of, but that's only becaue there have been relatively few legal judgements worldwide on this particular aspect of the GPL. Most breaches seem to be far more flagrant.

Re:Why not in the kernel?

[afidel]

Why not just use a kernel shim like the commercial closed source drivers do? It would still be faster than usermode!

Re:Why not in the kernel?

[segedunum]

How is it Sun's fault that the GPL is incompatible with anything other than itself?

Because the CDDL was deliberately made incompatible with the GPL, that's why. Also ask Sun about the needless patents they seem to want to hold on ZFS.

Linux wanting to pillage from the project isn't a good enough reason to make it impossible for people to write non-GPL drivers for Solaris

People could still write non-GPL drivers for Solaris regardless. I take that to mean you don't understand the meaning of a GPL compatible license.

Re:Why not in the kernel?

[Paul Jakma]

That's better than "it has been decided" (which is still modded "informative" for some unknown reason), however it's still not true. It may what many programmers roughly understand as a boundary of the GPL, but it is not what a court might understand. A court will take a wider view, not predicated on mere computer technicalities...

Re:Why not in the kernel?

[Vancorps]

This is and was always one of the chief complaints about Windows as well, everything in the kernel so a malfunction can take the whole system down. Now the push to user-space makes everything more robust. Of course you also take a performance hit hence the slowness that is Vista.

Still, if ZFS under FUSE is half as fast as XFS in kernel-mode then you're not talking about an FS that is particularly slow, you would still gain the data protection from ZFS which in my mind at least is the whole point. It would work for a near-line type storage system where performance isn't as critical. When the speed gets up then it can move to online storage where it will utilize the lessons it learned from near-line storage giving it a track record which will make people more comfortable in adopting it.

Re:Why not in the kernel?

[BrainInAJar]

"Because the CDDL was deliberately made incompatible with the GPL, that's why. Also ask Sun about the needless patents they seem to want to hold on ZFS."

The CDDL is more or less the exact same license Firefox or Apache are under. Sun has a lot of ISV's and IHV's that want to be able to write code ( storage drivers, for example ) that can link against the Solaris kernel without having a team of lawyers analyze to see if it's okay.

It wasn't chosen to be incompatible with the GPL, it was chosen to provide some of the same protections ( share my code... ) without being incompatible with other licenses.

As for the patents, ask IBM how many patents they've got expressed in Linux

"People could still write non-GPL drivers for Solaris regardless. I take that to mean you don't understand the meaning of a GPL compatible license."

You can't link to GPL'ed code with an incompatible license. Hypothetically if EMC or Symantec wanted to write a closed-source driver for this hypothetical GPL Solaris, they'd have to pull an nVidia ( which is a lot of effort for purely non-technical reasons ), or stop supporting the platform.

Would that really be in Sun's best interests, if I(S|H)V's stopped supporting them?

Re:Why not in the kernel?

[LWATCDR]

Actually if you take a look you will see that NTFS-G under Fuse is actually faster then XFS. There seems to be some memory fragmentation issues with ZFS currently.
I am a big fan of Microkernels. I keep hoping that Minix 3 will really start to take off soon. I love the idea of self healing systems and that can really only be done with a Microkernel.
I don't think Vista is slow because of any moves into user-space. I think it is more an issue of memory usage and DRM. Let's face it if you are "managing rights" for all sorts of files that takes CPU cycles. Also if you have to keep hitting swap all the time that will also slow you down.

Re:Why not in the kernel?

[Anonymous Coward]

If this was a concern to Sun they could just dual license it under GPL and CDDL. Linux could use the GPL and EMC/Symantec could use the CDDL.

Re:Why not in the kernel?

[Vancorps]

I wasn't aware that NTFS-G ran that fast in user-mode. Every-time I've seen an application go from kernel-mode to user-mode I've seen a performance hit.

I'm a fan of microkernels as well, sometimes you do need something all inclusive though.

You are right in that DRM checks will definitely slow it down, but they only slow it down when the media in question uses it. There is no inherent DRM that I am aware of. Memory management has always been an issue with Windows as well. Seems to be largely driver related which gets back to kernel-mode drivers taking down a system. My RAID drivers seem to be doing that to me right now on one of my file servers. Runs out of memory if I don't reboot the thing every other day. I've never run into that problem before, makes me think twice about 3ware RAID controllers.

Re:Why not in the kernel?

[LWATCDR]

We are have been running a 3ware controller for years on our Linux file server with uptimes of months. I am in south FL so every once and awhile we get a power outage that is longer than our UPS time.
I have never used 3ware under Windows but ours has been rock solid for like 7 years.

Re:Why not in the kernel?

[BrainInAJar]

or they could avoid the hassle of managing a dual licensed project & the inevitable GPL-only fork ( what happens if someone wants to import a driver from linux? that's an instant fork ) by keeping the perfectly-fine license they have right now

relicensing Solaris as GPL is entirely unnecessary and doesn't help Sun or Solaris at all... the only people it helps is Linux, and that shouldn't be the primary concern of OpenSolaris.

If OpenSolaris happens to help Linux, great, but it shouldn't hurt itself & go out of it's way to do it

Re:Why not in the kernel?

[Vancorps]

I've never run into any problems either, they are usually very high quality, but this is reasonably new and my latest experiences have been much worse. I had a new 9550 controller that would only start up properly half the time. A firmware upgrade later and it was stable but that seems like an odd product to release when it clearly had issues. That box was with Linux but the OS didn't matter as the bios wouldn't load.

Re:Why not in the kernel?

[Anonymous Coward]

Greetings and felicitations!

I agree this distinction is arbitrary and capricious.

Re:Why not in the kernel?

[Anonymous Coward]

Does anyone know if this module ZFS filesystem is considered open source?

Re:Why not in the kernel?

[Sancho]

When we're talking about filesystem drivers, I doubt we're going to see performance problems from running in userspace. The speed of the disk is likely going to be the bottleneck.

Re:Why not in the kernel?

[ChrisA90278]

"It has been decided": When? By whom?"

Linus decided. He wrote specific terms into the modified version of the GPL he uses with Linux. He makes it very clear. Linux does NOT use the "standard GLP" it makes a few changes for example he removed the "and later versions" part.

Re:Why not in the kernel?

[Schraegstrichpunkt]

Linus decided. He wrote specific terms into the modified version of the GPL he uses with Linux.

Retroactively, AND claiming to cover code for which he is not the copyright holder. The notice at the top of the COPYING file in the kernel source code more-or-less amounts to his opinion---and if you do a little research (read: Groklaw), you'll find that Linus clearly isn't a lawyer and doesn't know what he's talking about when it comes to legal matters.

"Linus said so" is just not a valid argument about a legal matter, unless you're trying to defend yourself against a copyright infringement claim that he's making about code he holds the copyrights for.

Re:Why not in the kernel?

[bfields]

How is it Sun's fault that the GPL is incompatible with anything other than itself?

The FSF lists 30 GPL-compatible licenses other than the GPL itself.

And it's Sun's fault because they chose their license second, without (as far as I could tell) giving a clear explanation why a GPLv2-compatible license would have been impractical for them.

Linux wanting to pillage from the project isn't a good enough reason to make it impossible for people to write non-GPL drivers for Solaris

Whatever else their relative merits, Linux has by far the wider hardware support. I don't know, maybe there's a few crucial drivers Solaris would have to give up for lack of available GPL drivers, but they're giving up access to a ton of Linux driver code.

Re:Why not in the kernel?

[afidel]

Constant changes in and out of kernel space are never good for overall system performance.

Re:Why not in the kernel?

[piojo]

My experience (home directory on zfs for a couple week) is that the benchmarks can't be representative of real use--sometimes my applications temporarily freeze (or completely hang, on occasion). The throughput may be decent, but real use is hundreds of concurrent accesses. My impression is that the scheduling isn't fair enough (perhaps this may have to do with the fact that it's a userspace program). In other words, half as good as xfs isn't enough. Yet. I've heard that performance has yet to be optimized.

Re:Why not in the kernel?

[BrainInAJar]

Why should they have given any care whatsoever about sharing code with Linux? They chose the license most acceptable to them with no regard to Linux whatsoever and that's that. OpenSolaris is not Linux, and should therefore not go out of it's way to either help or hinder Linux.

"Whatever else their relative merits, Linux has by far the wider hardware support. I don't know, maybe there's a few crucial drivers Solaris would have to give up for lack of available GPL drivers, but they're giving up access to a ton of Linux driver code."

Solaris driver support is actually quite good. Whatever obscure hardware that nobody cares about that Linux supports and Solaris doesn't is quite inconsequential to the project. If anyone cares about the hardware either OpenSolaris contributors directly, or one of the BSD's will support with a much more acceptable license anyways.
Solaris has very little of any consequence to gain from sharing code with Linux, but Linux stands to gain a lot from the wholesale looting out of Solaris' tree.

Is it any surprise that the only people you hear calling for GPL Solaris then are Linux users? Solaris users are quite fine with the way things are.

Re:Why not in the kernel?

[Vancorps]

That would be a deal breaker in my mind. If it hangs or becomes unavailable at all then it is pointless as that completely defeats the purposes of moving to ZFS. That is good info though.

Re:Why not in the kernel?

[bfields]

The in-kernel vs userland distinction has always struck me as quite arbitrary. So in one case you're linked at compile time and in another case you compile them separately and go through system calls.

Well, it's a bit more than that.... For one thing, the kernel is like a magic shared library that's used by every application on the system, and requesting services from the kernel doesn't require the context-shifting required to request services from another process on the same kernel. And there's a lot of vfs, memory management, etc. logic that your in-kernel filesystem code has access to that it wouldn't get purely over the system-call interface.

Why should that make one of them a derivative work and the other not? In either case the file system can be taken out and you still have a perfectly functional kernel that can run other file systems. Same goes for graphics drivers.

Userland code talks to the kernel over an extremely stable, well-defined system call interface. Filesystems in the kernel use a much lower-level and faster-changing interface, and are much more dependent on details of linux's implementation. That doesn't necessarily make them a derived work. But it's getting closer to the line.

There's also a practical consideration: the kernel developers reserve the right to change in-kernel interfaces without warning, whenever it would fix a bug, clean up some code, make something more efficient, or whatever, as long as they fix up all of the in-tree users of those interfaces. It can be challenging for an out-of-tree developer to keep up with such changes. So in practice if you want first-class Linux support for your hardware, you probably want to get your driver in the tree. And, even if they could sort out the legal issues, the Linux developers definitely aren't going to be interested in maintaining and distributing your non-GPL-compatibly-licensed driver for you....

Re:Why not in the kernel?

[Ash Vince]

Also ask Sun about the needless patents they seem to want to hold on ZFS.

Patents are usually not needless. Usually you obtain a patent on critical new technology not so you can sue other people who infringe it, but so you can stop some other company patenting your idea and dragging you through the courts after you make money and have some to lose.

I know that the patent system has checks and balances that are designed to prevent this but the reality is that those check and balances have been know to be inadequate for years.

Re:Why not in the kernel?

[lymeca]

The Right Thing(tm) is to keep the license as it is. It ensures the Solaris code has to be shared (like the GPL), but doesn't pollute source code around it

No. First off, do not turn this into a continuation of the debate of which is more Free: copyleft licenses such as the GPL, or BSD-style "our code is SO free you can make it NON-free!". This specific situation is much simpler: Linux has been GPLv2 licensed for about 15 years now, and the GPL itself is much older than that. Sun created the CDDL in the 2000's (not sure which year exactly) and has thereby acheived deliberate license incompatability with Linux and the GPL. There are other non-copyleft licenses which are GPL-compatible that Sun could have chosen, but they didn't: not that there's anything inherently wrong with this of course, it's their decision. Also, the GPL is NOT "incompatible with anything other than itself" like you state, check this list to find all the licenses that disprove this wildly inaccurate statement.

It is not inherently Right or Wrong to use the CDDL for ZFS or the rest of Solaris. Sun holds the copyright on that code, so Sun can choose to license those projects however they see fit. It is not your place to say what license is correct for Sun to use on their code. Perhaps to your dismay, Sun has been seriously considering GPLv3 for Solaris, much like they did with Java and the GPLv2. And for all your talk about Linux "pillaging" code from Sun, you conveniently forget that this was a main driving reason for Sun to license Java under the GPLv2: license compatibility with GNU/Linux for easy inclusion of Java technology in distributions to attract users and developers.

( GPL - viral clause = CDDL. Same license as firefox, or apache)

While the CDDL was originally based on the Mozilla Public License, it is not the same thing. Perhaps more importantly though, Firefox is tri-licensed under the MPL, LGPL, and yes, the GPL. I can get a copy of Firefox licensed under the GPL, so it's especially important not to mislead others into thinking that such a prominent Free Software project exclusively uses a non-copyleft license, the CDDL, which isn't even one of the three licenses Firefox uses in the first place! Oh, and Apache has its own license altogether, albeit a non-copyleft one, the Apache license.

Re:Why not in the kernel?

[notamisfit]

I'd question whether or not kernel v. userland is arbitrary in the case of Linux. Linus didn't pull the syscalls out of his ass, he got them from POSIX. To assert that any POSIX-compatible app is a derived work of the Linux kernel just because it happens to be running there is quite absurd.

This really doesn't make a difference in the case of FUSE, considering that it needs special kernel functionality to be able to do its thing...

Re:Why not in the kernel?

[piojo]

Sorry if I wasn't clear. Zfs has not yet hung--it's firefox that hangs. I'm not sure why, but I know that it never happened before I switched my home directory to zfs. Firefox did not hang, nor did my other applications become temporarily unresponsive. I have enough RAM that everything was snappy (when I used a traditional filesystem).

Re:Why not in the kernel?

[drsmithy]

And it's Sun's fault because they chose their license second, without (as far as I could tell) giving a clear explanation why a GPLv2-compatible license would have been impractical for them.

It's important to note that when the FSF says "the GPL is compatible with license X" it means that in the same way Microsoft does when it says "our standard is compatible with standard X".

That is, it's one-way "compatibility". You can take "license-Xed" code and GPL it, but you can't take GPLed code and "license-X" it.

Re:Why not in the kernel?

[the_womble]

Linux does NOT use the "standard GLP" it makes a few changes for example he removed the "and later versions" part.

Wrong. Here is the COPYING file for the Linux kernel.

He has added a note clarifying that userland programs making system calls are not derivative works. That is clarifying his interpretation of the license. At the most, it adds an exemption, which is common practice.

The "and later versions" clause is not part of the GPL, it lies outside it. In effect, it makes the work automatically multiple licensed as and when new versions of the GPL comes out: so if you distribute something under GPL v2 with that clause, when v3 comes you it will become dual licensed under 2 and 3, when v 4 comes out it will be triple licensed etc. This allows people to redistribute under v2 or any later version, with or without the "and later versions" clause.

Re:Why not in the kernel?

[BitterOak]

It has been decided that the deciding factor with the GPL is whether or not something links to it.

I thought the deciding factor was whether or not you redistributed the GPL code. I've read many times on Slashdot that the GPL only adds rights and doesn't take them away. It grants you the right to distribute GPL'd code as part of your project if you license your project under the GPL as well. As long as the kernel isn't distributed with the code that links to it, how does the GPL come into play at all?

Re:Why not in the kernel?

[Excelsior]

It is valid because the original kernel and all additional contributions were made under that license. Whether Linus said so, his drunk uncle snuck into his room and added that clause behind his back, monkeys typing on keyboards, magnetic interference, time-traveling hippies...it doesn't matter how it got there. It is there, and everyone contributing knew it was there.

Re:Why not in the kernel?

[Anonymous Coward]

The GPL doesn't attempt to codify all the intricate details that it would take to define such a distinction in the license. It's only described as an accepted rule of thumb in the FAQ.

It's not up to the GPL - or the FSF. The only thing that matters is whether the parts can be considered 'derivative works' under copyright law. If the parts exist independently in separate contexts (and zfs clearly exists independently and usefully without the linux kernel and vice-versa) a claim of copyright ownership obtained from the possiblity of optional run-time linkage would be fairly insane.

Re:Why not in the kernel?

[fd0man]

The in-kernel vs userland distinction has always struck me as quite arbitrary. So in one case you're linked at compile time and in another case you compile them separately and go through system calls. Why should that make one of them a derivative work and the other not? In either case the file system can be taken out and you still have a perfectly functional kernel that can run other file systems. Same goes for graphics drivers.

The idea that I have always used has been something along the lines of "if the source code is <em>required</em> to build it, then it must be part of the source tree and thus creates a derivative work."

However, this means that if you have a program that permits plugins that can be called in ("linked") at build-time, and you do not need any of the program source to make said plugins (e.g., you can make the plugins using only an interface spec and none of the headers or implementation files from the program in question) then it is not something that is a derived work. However, if you have compile-time dependencies on the headers or the program itself, that means that the program is a part of the larger work, by the very requirement that it has a hard technical dependency on it.

This also means that the NVIDIA drivers are not likely to be considered infringing, at least by me, because there is a source part that gets built, and it pulls NVIDIA's universal binary blob from there. IIRC, the source part is open/free, and their binary blob is an operating system-independent blob that has entry points that the user-built portion calls into. I would say that this makes the user-compiled portion part of the kernel (because it depends on the kernel source to properly build, and is linked to the kernel by stubs that are put in place by the compiler, which insmod uses to perform the insertion into the running kernel), but not the blob, since the blob does not depend on Linux (e.g., that blob also runs on 32-bit FreeBSD, with a little help from a piece of "glue code" similar to what is present in the Linux system from the user-compiled piece of the module).

It is still definitely a gray area, and at least to my knowledge at present there is no tested hard-core definition of this aspect of the GPL. However, it seems like it is a safe test to use: Does the code require the source of the GPL'd program to build? Yes = creates a derivative work, no = independent program (even if there is a non-theoretical dependency on the larger work in question). It all comes down to a question of what type of dependency relationship exists between the "module" and the application. A good example is Flash for Firefox/Konqueror/etc.--Adobe does not need all of those browsers to link the plugin together. The plugin conforms to an interface standard, and is just linked in at runtime using the <a href="http://www.opengroup.org/onlinepubs/00969539 9/functions/dlopen.html" title="dlopen() definition at Open Group">dlopen()</a> system call. Yet another example might be the telephone--I don't need to know the internals of the phone system to know how to use the interface that the phone plugs into, and how to send DTMF signals and the like. I send signals, and the rest of the system handles the switching and routing and the phone just sends/receives electrical impulses that correspond to sound waves when put through the rest of the phone's devices. The telephone is not a derivative work of a phone network switch, but it is dependent on its functionality.

Re:Why not in the kernel?

[swillden]

It's important to note that when the FSF says "the GPL is compatible with license X" it means that in the same way Microsoft does when it says "our standard is compatible with standard X". That is, it's one-way "compatibility". You can take "license-Xed" code and GPL it, but you can't take GPLed code and "license-X" it.

It's even more important to note that the above statements are false. The FSF is quite clear about what it means by GPL compatibility -- that a module with the GPL and a module with the other license can be combined and released under a license that satisfies the terms of both. This does *not* mean that the non-GPL module has become GPL'd, indeed many of the GPL-compatible licenses do not permit third parties to relicense the software any more than the GPL does.

Re:Why not in the kernel?

[Bronster]

Ah, the blind leading the blind.

I'm more inclined to believe the people who have actually done a diff between the COPYING file in the linux source tree and the GPL as shipped by the FSF which shows that Linus hasn't modified anything other than a clarification at the top to remind people that he didn't add the optional "or later version from the FSF" wording when he applied the licence change to GPL way back when and doesn't intend it either.

But feel free to believe Groklaw instead. There's a lot of good stuff there, but the GPL3 fanboyism is a bit of a crock.

Re:Why not in the kernel?

[aichpvee]

Actually I was just saying that they should release a GPL version since Linux is WAY more popular and run on WAY more systems than Solaris will ever be and maybe if they had a kernel driver available someone might actually give a fuck about ZFS. Since they don't you'll see people doing these stupid license work arounds when they *need* to use it (who knows why) and everyone else will continue not to care.

Not really sure what your rant was about, I stopped reading when I got to "Free" because you'd obviously missed the point. For the recond I think BSD is more "free" but that GPL does a better job of expanding freedom and is better. But we weren't talking about GPL vs BSD. We were talking about if anyone gives a fuck about ZFS, though I think you missed that part.

Re:Why not in the kernel?

[mabinogi]

There is no license that gives you the right to re-license someone else's copyrighted work.
The GPL doesn't require that everything linked to it be GPL'd, it requires that any changes or derivative works be licensed under a license (any license) that adds no more restrictions than the GPL itself does.

Re:Why not in the kernel?

[aichpvee]

Because way more people use Linux on way more machines than will ever use Solaris and if there were a kernel driver some of us might give a fuck about ZFS and if they don't it'll continue to be supported by those who for some reason HAVE to work with it by doing an end-run around the license. Maybe Sun just doesn't care about ZFS having a wide user base, which I guess is fine. It just seems stupid to me, though.

Re:Why not in the kernel?

[Anonymous Coward]

relicensing Solaris as GPL is entirely unnecessary and doesn't help Sun or Solaris at all

Except by giving Solaris drivers for approximately all hardware currently in use (and most hardware ever made).

Re:Why not in the kernel?

[Anonymous Coward]

Firstly people only want the ZFS bit, they can keep the rest of Solaris. Secondly, of course they don't need to, but your initial complaint was that relicensing would hurt some of their business relationships. Fine. If that is their only reason to use CDDL, then keep Solaris CDDL and dual licence ZFS as GPL and CDDL. If they don't want to do it because they don't want to help Linux then that's their decision to make and there is nothing wrong with that, but don't try to pull some "Symantec would be annoyed" rubbish.

Re:Why not in the kernel?

[tkinnun0]

It is still definitely a gray area, and at least to my knowledge at present there is no tested hard-core definition of this aspect of the GPL. However, it seems like it is a safe test to use: Does the code require the source of the GPL'd program to build?
That's no good, because then every Java class would not be derived from any other Java class, which is not the intent of FSF or GPL. It would make GPL the same as LGPL on Java, because you can create an interface-compatible drop-in replacement class from another Java class. There are even tools to automate this.

Re:Why not in the kernel?

[Anonymous Coward]

Simply because Linus and the Linux kernel licensing makes an explicit exception for user space. It has little or nothing to do with the GPL.

Re:Why not in the kernel?

[fd0man]

Hrm. I suppose that you're right. But then again, the C library is just a library that fulfills an interface definition, too. Parts of it or the entire thing can be reimplemented at will. I don't quite get, though, where you mean that the GPL would be the same as the LGPL in terms of the GNU Classpath system--The LGPL says that you must release the source to that which you *use* in your application, with certain restrictions. It can never grow to be beyond what it is, and the GPL itself is a forced-openware license. One can rewrite the needed portions of the GNU Classpath, for example, without ever looking at the GNU software, and comply with the licenses by avoiding them entirely. (Of course, proving that one did not look at GNU code is hard to do.)

Re:Why not in the kernel?

[segedunum]

You can't link to GPL'ed code with an incompatible license.

Which CDDL is. They could easily have used a GPL compatible one, but chose not to.

Hypothetically if EMC or Symantec wanted to write a closed-source driver for this hypothetical GPL Solaris, they'd have to pull an nVidia

No they wouldn't.

Would that really be in Sun's best interests, if I(S|H)V's stopped supporting them?

No reason for that.

You simply don't understand this.

Re:Why not in the kernel?

[fast penguin]

I know the guy that started it off as a Summer of Code sponsored project. The reason is simple; time. It seems that three months wouldn't be enough to make a ZFS kernel module, at least for him, as he is not a kernel hacker. Can't really explain you why. Anyway, I'm sure you can get him, or someone else, to do it; just put your money where your mouth is.

Re:Why not in the kernel?

[MikeFM]

If they don't want to open the source then I don't want it in my kernel. I need something that has the reliability of peer review and the ability for me to get in there and fix it myself if the shit hits the fan. In areas less essential than the kernel I don't care as much but I don't want to make it easy for hardware companies to offer half-assed support for Linux. If they aren't going to do it right then they should go away and stop wasting our time and resources.

It's great to see more work being done with FUSE but I have to wonder why they can't code a clean implementation of ZFS that doesn't have these licensing issues. This kind of solution is just a bandaid. Great, if you absolutely have to have it but not nearly as good as an open sourced offering.

Re:Why not in the kernel?

[Schraegstrichpunkt]

Oh really? According to you, when was the clause added to the kernel? What kernel version? (Hint: It wasn't 0.1.)

Re:Why not in the kernel?

[Schraegstrichpunkt]

I'm more inclined to believe the people who have actually done a diff between the COPYING file in the linux source tree and the GPL as shipped by the FSF which shows that Linus hasn't modified anything other than a clarification at the top to remind people that he didn't add the optional "or later version from the FSF" wording when he applied the licence change to GPL way back when and doesn't intend it either.

So your theory is that Linus didn't "intend" that Section 9 of his own COPYING file apply? Perhaps he didn't "intend" that Sections 1, 2, or 3 apply either? Heck, why bother with a written licence document at all when we can just ask people what they "intended"?

The intent that Linus expressed was to license Linux under GPLv2 in its entirety. That includes Section 9. If that's not what he wanted, then he should have accompanied the license with an appropriate notice that prescribes exactly what it was that he did want. He's done that in later versions of Linux, but he can't---under the guise of "clarification"---revoke the GPL terms he used for previous versions of Linux in order to establish more restrictive terms.

You don't need to believe Groklaw to understand that.

Yet to be included?

[vialation]

The summary makes it sound as if ZFS will ever be included in the kernel. Anything FUSE will never be in the kernel, except the FUSE driver itself. Userspace programs and kernelspace are considered separate for a reason.

Of course, this will all change if both Sun and Torvalds switch to GPL3...

Re:Yet to be included?

[salahx]

Not necessarily; NTFS is both in the kernel AND in FUSE. However, the kernel version is less full-featured than the user-space version (ntfs-3G); because of lack of manpower and that author strict quality control - the old NTFS driver ate filesystems.

That said, I can't see ZFS ever being in the kernel - even licensing problems aside; its a HUGE layering violation. Some say they can do a ZFS without the layering problem; an ambitious project - btrfs exists to try do exactly that. Of course its nowhere near done (currently it'll oops if the filesystem gets full, among other things) - but its one to keep an eye on.

Re:Yet to be included?

[lymeca]

Nobody can say for certain if ZFS will see a legal implementation directly in the Linux kernel, but I think it's fairly obvious that the largest barrier to doing so is a legal one. The summary is worded such that it does not exclude the possibility of the licensing barrier being overcome, which I personally believe will happen. You mentioned at the end of your comment what is in my mind the most likely scenario that would yield full inclusion of ZFS in the Linux kernel: both projects being relicensed (dual-licensed?) under the GPLv3.

I for one didn't quite believe Sun when they made their initial casual talks about deciding to license Java under the GPLv2, but look what happened with that: they followed through, with the primary intention to see Java be as widespread as possible and attract more users and developers. In Sun's perspective, and as they've publicly stated, the fact that their Java technology can now (well, almost) be included by default in any GNU/Linux distribution which chooses to do so was a huge selling point for choosing the GPLv2.

Now Sun has been talking about dual-licensing Solaris under the GPLv3 in addition to the CDDL. Sun sees the GNU/Linux train taking off from the station and doesn't want to miss it: that's why they GPLed Java and that's why they'll probably do the same for Solaris. In addition to this, Linus Torvalds has already stated that ZFS under the GPLv3 is perhaps a good enough reason to relicense the kernel: "maybe ZFS is worthwhile enough that I'm willing to go to the effort of trying to relicense the kernel."


So in summary, we have Sun seriously considering GPLv3 for Solaris, and if they follow through in totality, we have Linus seriously considering starting the move to GPLv3 license Linux, and we also have all of the GNU projects moving to GPLv3 at the hand of the FSF. And the patents Sun has on ZFS? Already taken care of in the GPLv3! Now we just need the licensed to be released....

Grub

[jshriverWVU]

Booting from a ZFS partition has been confirmed to work

Grub has supported ZFS booting for a while (forget which branch though).

Re:Grub

[vialation]

Getting GRUB to load ZFS was easy since Sun released GPL boot code which could minimally read a ZFS partition. The hard part is making it so that the kernel can use the filesystem as root, which requires ZFS to be built into the kernel. Unless you are using an initrd or some other FS for the boot partition. Direct booting is extremely difficult.

Re:Grub

[Anonymous Coward]

You can load FUSE from initramfs, did you know?

Just be cafeful with your shutdown scripts. You wouldn't want killall to drop your userspace end of FUSE just before you remount readonly.

Now if I could only find whose responsible for sysvinit. I have a little patch and a custom script pair that makes this a little easier.

Re:Grub

[lmfr]

Yes, if you can mount it, you can boot from it, with the proper initrd/initramfs.

As for the maintainer for sysvinit, the lsm tells you that. Or you could go with the maintainers of your distribution.

Re:Grub

[catmistake]

Did I miss something? Linux and the future of Linux is always following Microsoft, always cleverly duplicating, for free, in *nixy-land, the expensive proprietary Microsoft stuff... twas always thus and always thus will be. So... when did Microsoft annouce they'll have support for ZFS?? (They won't, btw... we can expect Microsoft to flood the market with a crappier, broken, overpriced knock-off of ZFS)

Re:Grub

[swillden]

Yes, if you can mount it, you can boot from it, with the proper initrd/initramfs

You mean "If you can mount it, you can use it as a root partition, with the proper initrd/initramfs". The boot partition is where the initrd/initramfs is read from, so you can't rely on stuff in your initrd/initramfs for booting.

To boot from a given file system, what you need is a bootloader that can read files from that system, either because they can be guaranteed to be a nice contiguous block which the bootloader can read given a physical disk address (a la LILO) or because the bootloader understands the file system (a la GRUB).

Re:Grub

[lmfr]

You mean "If you can mount it, you can use it as a root partition, with the proper initrd/initramfs". The boot partition is where the initrd/initramfs is read from, so you can't rely on stuff in your initrd/initramfs for booting.

Yes, that's what I mean. Thanks for the correction.

It's time for Sun

[tenchiken]

It's time for Sun to put their money where their mouth is. Linus was absolutely right recently when he noted that Sun wanted access to Linux's drivers. They also have co-opted gnome, and taken advantage of the renaissance that Linux brought to the (massively decaying) UNIX ecosystem.

Let's find a way to settle these license issues. ZFS looks to be great innovation, but Sun appears to be playing license games with the express purpose of keeping Linux at bay.

Re:It's time for Sun

[Anonymous Coward]

They also have co-opted gnome

No "co-opting" necessary. Solaris is every bit as much a terget platform for Gnome as Linux is.

Re:It's time for Sun

[AKAImBatman]

They also have co-opted gnome

By "co-opted" I presume you mean, "Made major contributions to"?

Re:It's time for Sun

[PygmySurfer]

Let's find a way to settle these license issues. ZFS looks to be great innovation, but Sun appears to be playing license games with the express purpose of keeping Linux at bay.

Sorry, it's Linux that's playing the license games, not Sun. One only needs to look at ZFS support in FreeBSD to see that (Speaking of, where's the 'ZFS On FreeBSD!' story?).

The GPL "everything under our license" philosophy is the sole cause of these so-called "license issues". If Linux wants to use Sun's code, why should Sun have to release it under Linux' license?

Re:It's time for Sun

[Anonymous Coward]

If the Linux community don't like the way Sun does things, then maybe they shouldn't use ZFS at all. Or any other Sun technology.

Re:It's time for Sun

[Anonymous Coward]

Linux has already stated that he just wants to write code. He's a programmer, not a lawyer. So for christ's sake, leave him alone and let him write code.

Re:It's time for Sun

[Braxton_Bragg]

I've been around the block a few times. I've noted that one of the founders, Bill Joy, "probably" brought over a lot of the code from the Berkeley distribution to Sun OS ( pre Solaris, of course).

I agree that Sun is a dying concern.

Re:It's time for Sun

[OYAHHH]

Wrong,

Sun exists to make money for it's shareholders. If and when it becomes advantageous to their share price to release ZFS then they will do it.

They have already stepped up to the plate and released Star/OpenOffice, Java, and significant portions of Solaris. Each of those software products is a very significant level of magnitude of work. How about a little bit of appreciation for those several person-years worth of work?

To imply that Sun is playing licensing games is disingenuous, at best.

And if you want to call someone out on licensing then how about Linus himself. Why does he own the trademark Linux? Yes, he provides free sub-licensing terms, but those are Linus' terms.

Much as Linus has his limits, Sun has it own limits of what it is willing to give up.

When Linus decides to give up the Linux trademark freely then he can legitimately start complaining about Sun Microsystems.

Re:It's time for Sun

[RedElf]

Sorry, it's Linux that's playing the license games, not Sun. One only needs to look at ZFS support in FreeBSD to see that (Speaking of, where's the 'ZFS On FreeBSD!' story?). Thank you, couldn't have said it better myself. In fact while reading the article I couldn't help but keep thinking if they were using FreeBSD instead of Linux they could already be playing with ZFS.

Re:It's time for Sun

[Anonymous Coward]

Probably? It's not like they tried to hide it, or necessarily did anything wrong.

Re:It's time for Sun

[Anonymous Coward]

"Why does he own the trademark Linux?"

Someone has to.

Re:It's time for Sun

[jimwelch]

Everyone that has a license is "playing the game". That is required by most copyright laws. The only truly free software is in public domain, the downside to PD is code confiscation that is possible. BSD, GPL, M$ all use a license with restrictions. A restriction limits one or more freedoms. You have to choose which freedom to give up.

Re:It's time for Sun

[Alphager]

Sorry, it's Linux that's playing the license games, not Sun. One only needs to look at ZFS support in FreeBSD to see that (Speaking of, where's the 'ZFS On FreeBSD!' story?).
There is no "ZFS on FreeBSD"-story, because all five users of FreeBSD allready know about it. Linux has a much wider adoption out there, thus the focus on linux.

Re:It's time for Sun

[drinkypoo]

Sorry, it's Linux that's playing the license games, not Sun.

ZFS is on OpenSolaris and Sun has claimed to be considering GPL for OpenSolaris. Are they, or aren't they? On top of that, the FSF has muddied the waters through their activity on the GPLv3, further complicating the entire issue.

I don't think you can blame the whole situation on Linux's use of the GPL, which is not coincidentally the reason why many people contributed to Linux. Given that Linux is today considerably ahead of all BSDs in most ways, I think adoption of the GPL is likely the only reason Linux is here today.

Finally, if you don't care about software freedom, and only your freedom, why don't you go run BSD, and stop complaining about Linux?

Re:It's time for Sun

[jellomizer]

This is the general Flaw with the GPL. It assumes given the approprate environment everyone will want to use GPL. In Real Life this isn't the case. There are pleanty of well informed and smart people who don't like GPL. There are many reasons not to choose GPL or a GPL Compatible License. Not all buisness models or software is or can be profitable with GPL. Everyone is different and it is impossible for GPL to gain the level accecptance it wants (Every Software). It isn't that great of a license, it is to restrictive for the developer who actually puts their time and effort into the work.

GPL is like a Cult which doesn't allow people to converse with people outside the cult or its compatible cults. Any sharing of idea or information outside of its core beleafs are considered Evil so must be avoided at risk of banashment. Software wants to be free but the creator normally wants some rights to his work. Either it being money, their Name in the Text File so it looks good on a resume, or just control of the process. Sun want to keep control of their process so they don't want to make it GPL. And now Linux users are suffering from it not because Sun doesn't want linux users to use it but because the Rules that the linux Devlopers agreed appon wont allow it.

Re:It's time for Sun

[Anarke_Incarnate]

Linux is a kernel (OS If you don't want to be pedantic) and LINUS (Linus) is a programmer and benevolent dictator.

Confuse them again at your own peril.

Re:It's time for Sun

[Deagol]

Sorry, it's Linux that's playing the license games, not Sun. One only needs to look at ZFS support in FreeBSD to see that (Speaking of, where's the 'ZFS On FreeBSD!' story?).

Maybe because FreeBSD 7.0 hasn't been released yet? Sure, it's there, but not all of us run CURRENT. Personally, I'm chomping at the bit to get ZFS, but I'm sticking with STABLE.

Re:It's time for Sun

[rbanffy]

Is there a BSD "distro" that uses APT for package management (or something as good as)? I would love to have ZFS, but not at the expense of sane package management.

Re:It's time for Sun

[PygmySurfer]

ZFS is on OpenSolaris and Sun has claimed to be considering GPL for OpenSolaris. Are they, or aren't they? On top of that, the FSF has muddied the waters through their activity on the GPLv3, further complicating the entire issue.

I don't care if Sun says they're considering GPLing OpenSolaris, ZFS, or anything else for that matter. The poster I replied to accused Sun of keeping ZFS from Linux by not GPLing it - when it's the goddamn GPL that Linux uses that is preventing the inclusion of ZFS!

I don't think you can blame the whole situation on Linux's use of the GPL, which is not coincidentally the reason why many people contributed to Linux. Given that Linux is today considerably ahead of all BSDs in most ways, I think adoption of the GPL is likely the only reason Linux is here today.

I'm not sure how Linux can be ahead of the BSDs, as Linux is just a kernel, while the BSDs are entire operating systems. But let's say you were referring to Linux distributions being "considerably ahead" - I've never seen this. I've always found the BSD's to be elegant systems to work on, and Linux systems to be a mess (I unfortunately have to admin hundreds of Linux boxes at work). Linux supposedly has better driver support, yet I've always found FreeBSD supports my hardware just fine (and for many things, like wireless drivers, I've found the BSDs to have better supprt than Linux). Linux may perform a bit better in some instances, but IMHO the negligible performance gains aren't worth the aggravation.

Finally, if you don't care about software freedom, and only your freedom, why don't you go run BSD, and stop complaining about Linux?

I use FreeBSD on my personal server, and I believe BSD code to be more free than GPL code, but that's irrelevant. Frankly, I'm sick of the Linux community telling everyone else what to do with THEIR code. Besides, you can hardly call my post a complaint - if anyone was complaining, it was the original post I replied to.

Re:It's time for Sun

[PygmySurfer]

Maybe because FreeBSD 7.0 hasn't been released yet? Sure, it's there, but not all of us run CURRENT. Personally, I'm chomping at the bit to get ZFS, but I'm sticking with STABLE

Are you saying ZFS on FUSE is a production-quality release? At this point, I'd have more faith in the stability and reliability of ZFS on FreeBSD than ZFS on FUSE. If ZFS on FUSE warrants a front page article, surely ZFS on FreeBSD warrants a blurb in the BSD section of /.

Re:It's time for Sun

[drinkypoo]

I'm not sure how Linux can be ahead of the BSDs, as Linux is just a kernel, while the BSDs are entire operating systems.

I'm talking about kernels vs. kernels. The linux kernel tends to includes substantial functionality not yet available for *BSD.

Although I could as easily talk about distributions vs. distributions; more software is developed on Linux than *BSD and it sometimes takes time/effort to port from Linux to *BSD, so there is more software available to the average end user.

Linux may perform a bit better in some instances, but IMHO the negligible performance gains aren't worth the aggravation.

It's notable that these days Linux runs on more platforms than anything else but maybe netbsd, the least advanced (but apparently most portable) flavor of *BSD. Linux runs on 16 bit systems with no MMU (albeit a somewhat hacked up version of the kernel) and it runs on some of the most complex systems on the planet. Linux provides the potential for more hardware than it is possible to get with any *BSD system. And less!

Finally, if you don't care about software freedom, and only your freedom, why don't you go run BSD, and stop complaining about Linux?

I use FreeBSD on my personal server, and I believe BSD code to be more free than GPL code, but that's irrelevant. Frankly, I'm sick of the Linux community telling everyone else what to do with THEIR code.

My response can only be "wah wah wah". I'm tired of BSD-types telling everyone else what attitude they should have about software licensing.

Sun claims they want ZFS to be taken up. The GPL has important features which are there for good reasons and which are obviously supported by the Linux community (which would, again, otherwise just go to BSD and shutthefuckup.) If Sun is serious about wanting to see ZFS be taken up, they are going to have to license it accordingly. If they aren't, then they don't. As it is, it's present in FUSE today, so it's there and working, and it should only get faster as both the implementation and FUSE itself are improved. So frankly I don't give a good goddamn regardless. But ultimately if you don't want to listen to whiners, don't listen to them and for dog's sake don't egg them on or you will only create more of what you are complaining about.

I just think you like to complain.

Besides, you can hardly call my post a complaint - if anyone was complaining, it was the original post I replied to.

I calls 'em as I sees 'em.

Re:It's time for Sun

[notamisfit]

BSD's really aren't package management heavy; they've got programs for installing and removing packages, and scripts to upgrade, but that's about it. The BSD's generally focus around *ports* instead of packages, which are more like Gentoo's ebuilds; the user downloads the framework from CVS, executes the script, and the port downloads source code and compiles a binary package which is then installed. It's probably not as robust or as simple as APT, but allows for more customization. (For the record, there is something called PC-BSD out there that supposedly uses a more Linux-like package management interface; it's supposedly one of the most easy-to-install and easy-to-use systems out there, according to some pointy-hat I couldn't be bothered to remember the name of).

The real genius of the BSD way, IMO, is the separation of the base system from the package manager. Whenever I've had troubles with upgrades on Linux, it's usually on account of the kernel, glibc, or some essential library. With the BSD's these components are compiled and installed as a whole.

Re:It's time for Sun

[GnuAge]

When Linus decides to give up the Linux trademark freely then he can legitimately start complaining about Sun Microsystems. I think Thorvalds' complaints about Sun's efforts to accommodate Linux sound pretty legitimate even if he does trademark the OS name.

Re:It's time for Sun

[Anonymous Coward]

This is the general Flaw with the GPL. It assumes given the approprate environment everyone will want to use GPL.

Only if you assume that the point of the GPL is to be all-inclusive. It isn't. The point of the GPL is that it minimizes hassles for developers. If you release software under the GPL then you know what the rules are and always will be with regards to that code from the outset, which makes things simple. If that's what you want, then you release your software under the GPL. If that isn't what you want, then you don't release your software under the GPL.

Re:It's time for Sun

[rbanffy]

"With the BSD's these components are compiled and installed as a whole."

You could simply have a large "bsd-base" package (that depended on a specific version of a "bsd-kernel") with all the base system in it and still have package management (even buildable and depending on source packages) for all user applications (like Firefox, Thunderbird, Emacs and so on). When you upgrade it, you are effectively, upgrading the whole OS.

My problems with package management on Ubuntu are very rare (and mind you I am running Feisty on a Gutsy kernel). I had some with Debian, but I was running a box pegged on testing with parts from unstable, experimental and several external non-kosher package sources, so, I suppose, I deserved what I got.

Re:It's time for Sun

[notamisfit]

Sounds good. Go do it.

But seriously, I think that's what PC-BSD already does. Really, there's not a whole lot of difference in package management across the board; everyone's still installing, deleting, or upgrading packages, and almost all of them handle dependencies. Are BSD's tools in the same degree of usability as APT/Synaptic? No. Can I get what I need within a short amount of time? Undoubtedly.

Re:It's time for Sun

[Anonymous Coward]

(massively decaying) UNIX ecosystem

I guess I shouldn't be surprised about a Linux zealot spreading misinformation about other OSes.

http://www.sun.com/aboutsun/pr/2007-05/sunflash.20 070523.1.xml

Re:It's time for Sun

[crumley]

I have no idea if it includes ZFS yet, but Debian GNU/kFreeBSD certainly includes apt.

Re:It's time for Sun

[rbanffy]

Sounds extremely worth a try. Thank you very much.

Heck... A BSD kernel with BSD-ish tools and APT coming from the usual *BSD players would sure be very interesting. The key to a decent package manager like APT is not installing stuff. Anyone can get a tarbal and do the "./configure-make-make install" dance. The trick is to do it and still keep your box up-to-date with the latest and greatest (and safest) stuff.

Re:It's time for Sun

[rbanffy]

"Are BSD's tools in the same degree of usability as APT/Synaptic? No. Can I get what I need within a short amount of time? Undoubtedly."

The key thing in package management is not getting stuff. It is certainly convenient to be able to get stuff and install it easily, but it is not as easy to keep it up to date. If a gaping security hole is discovered in the program you installed yesterday, will it auto-update as soon as a new version is released? I am not sure and being unsure about it is a big reason why I don't run BSD as my main OS. The "-h human readable" options being the other good ones. ;-)

Re:It's time for Sun

[Ant P.]

Linux is just a kernel, while the BSDs are entire operating systems.

You mean "GNU/BSD" - after all, C source code doesn't run directly on the CPU ;)

Re:It's time for Sun

[Solra Bizna]

Have you read any of the FSF's material on the subject? Much of it tries pretty hard to convince you that it is wrong to release your code under a different license.

Speaking as a developer, the GPL has caused nothing but hassle for me.

-:sigma.SB

Re:It's time for Sun

[DavidpFitz]

Sun claims they want ZFS to be taken up.

Sure, why not? ZFS is - as far as we are today - the be all and end all of filesystems.

The GPL has important features which are there for good reasons and which are obviously supported by the Linux community

Indeed - "supported by the Linux community" ... which not everyone cares about. Sorry to burst your balloon, but Linux is still a minority player and in no position to dictate terms. I suspect Sun would truck right on if the Linux "community" didn't adopt ZFS. A great deal of people consider the GPL viral and bad for what they do. Let me say this again - it is LINUX people playing licensing games - not anyone else. It's not your ball, so you don't have the right to take it home when you get upset.

If Sun is serious about wanting to see ZFS be taken up, they are going to have to license it accordingly.

Absolutely right. Who do they want to see it taken up by, though? And whose terms are they entitles to see this happen, if it happens?

Re:It's time for Sun

[charlesnw]

Um. Everyone trademarks there product name. Including the most ardent of free software distros Debian (Software in the public interest owns the trademark). If the name wasn't trademarked I would be very wary. If you don't have enough belief and passion in your product to trademark it, I don't want to even consider using it.

Re:It's time for Sun

[drinkypoo]

Indeed - "supported by the Linux community" ... which not everyone cares about. Sorry to burst your balloon, but Linux is still a minority player and in no position to dictate terms.

I'm not sure who you think you're kidding, but you ARE kidding NOBODY.

Linux is a major player in computing today. It is used at every level of business. It is in cellular telephones and several of the top ten supercomputers on the planet. It can be found on the desktop (sometimes) and on the server (quite often) and in switches, routers, and the like (regularly.)

I suspect Sun would truck right on if the Linux "community" didn't adopt ZFS.

Right, that's why Sun is currently working to make Solaris more like Linux (at the userspace level) - because Linux is irrelevant. Good thinking. I suppose next you'll tell me that IBM thinks Linux is irrelevant too, which is why they sell more Linux than AIX today.

A great deal of people consider the GPL viral and bad for what they do.

The problem with that reasoning is that the GPL (let us speak of v2 for now) is only bad for people who want to do bad things. It's bad for people who want to benefit from the code without respecting the wishes of its author. It's bad for people who want to prevent you from properly utilizing the hardware for which you paid. And that's it. No one is forcing you to use GPL code, and until they do, the viral nature of the GPL (it is viral, but it's amazingly easy to avoid, it doesn't leap from one directory to another and infect your code without your knowledge) is totally harmless to you. If you want to write non-GPL code, you have that right and no one will stop you. On the other hand, they will [try to] stop you from using their GPL code in their project. But due to copyright law, even without the GPL, you still wouldn't have the right to use their code. So you have no basis for your complaint.

As for GPLv3, the major additional requirement is that if you extend patent protection to any recipient of the code, you must extend it to all of them. This is only logical, because it again prevents you from using the code in a way that is not blessed by the author of the code. So again, there is no basis for complaint. If you find the author's requirements too arduous, don't use their code! You don't have a god-given right to use it anyway, and they would not have distributed it at all (meaning that no one would benefit from it but them) if not for the GPL - because obviously those are the terms under which they wished to distribute it.

Basically, the GPLv2 or v3 harms only those persons who wish to benefit from the works of others without their consent.

The GPL might be viral, but it's not contagious.

I suppose there's another group of people who could be harmed by this; if you need functionality you can't develop, and there's no BSD-licensed or commercial code available and your only options are GPL'd, then you have two choices. You can go back to school and learn how to do the development yourself, or you can go GPL. But that's a pretty farfetched example. There will likely always be demand for closed code; there will likely always be proprietary software. And if it does happen, then it indicates nothing less than a paradigm shift in software development, and by that time it will be well past time to get with the program, join the big parade, and develop Free Software.

Since that day is probably nowhere close, I am at a loss to determine what you're complaining about - unless you're one of those people who would prefer to use the author's code without their permission. In which case I hope the same happens to you, over and over.

Re:It's time for Sun

[Sancho]

Honestly, I have to agree with DavidpFitz.

Sun releases nifty filesystem.
Linux users drool, decide they want filesystem.
Linux developers realize that licenses are incompatible.
Linux users complain that Sun is playing 'licensing games.'

The CDDL is not all that restrictive. However, it just happens to be incompatible with the GPL, because the GPL doesn't allow additional restrictions to be placed on derivative works, and the CDDL has requirements that aren't in the GPL.

Sun is already being open with their filesystem. Linux users are the ones who want it in the kernel. The GPL is at least as much to blame as the CDDL. Since I consider the CDDL to be a more free license than the GPL, I'm inclined to think that the GPL is more at fault.

Re:It's time for Sun

[bill_mcgonigle]

those several person-years worth of work?

person-centuries, I presume.

Come back here when OpenSolaris goes GPL3 and see what tune folks are singing.

Re:It's time for Sun

[Sancho]

Just for your information.

You can install the portaudit package to check your ports for security problems. If a problem is detected, it's usually just a matter of portsnapping up a new ports tree and "make install"ing the port. Of course, you can also check freshports to make sure that the issue was addressed in the latest tree before going to all of this trouble.

Re:It's time for Sun

[PitaBred]

How so? If you want the benefits and bootstrapping of someone else's free code, play by the GPL's rules. Otherwise, write it yourself. It's not that hard of a concept. You get something for free to start with, but have to give your changes away for free too, or you just write something completely closed, but you have to write it end to end.

Re:It's time for Sun

[Doctor Memory]

Bill Joy, "probably" brought over a lot of the code from the Berkeley distribution Seems fair, insofar as he wrote a goodly chunk of it. After all, he was the one who assembled and distributed the release tapes for 1BSD (a large set of patches for Sixth Edition Unix), wrote the ex editor and the C shell for 2BSD, wrote the widely-copied TCP/IP stack for 4.1BSD, and also created NFS and vi (maybe you've heard of them). The impression I get is that he was the de-facto leader of the CSRG until he left to co-found Sun. We started using 4.2BSD in '82, and IIRC all we had to do was get a source license from AT&T (~US$500) for those few modules that CSRG hadn't rewritten. Everything else was (of course) under the BSD license...

Re:It's time for Sun

[LingNoi]

Frankly, I'm sick of the Linux community telling everyone else what to do with THEIR code.

Frankly, I'm sick of the BSD community trolling GPL/Linux threads on Slashdot when they have no purpose commenting in the article at all.

The constant "meh! Wouldn't have this problem with the BSD license" is the equivalent of the GPL zealot saying "Meh! Linux is superior to winblows"

My only view of the BSD community comes from Slashdot and what I see is a bunch of jealous losers cry babying in GPL/Linux threads because their license is not the most popular and never will be when compared to GNU/Linux usage.

Re:It's time for Sun

[LingNoi]

I'm inclined to think that the GPL is more at fault.

It is not the GNU GPL's fault its because Linus and kernel co. decided to take out the "or any later version" clause for selfish reasons of wanting to restrict what license people choose to use the Linux kernel under.

Now its backfiring in their faces as a lot of code gets moved to GPL3 and they're left behind not being able to include any of it. ZFS being the best example here.

If they stuck with the original GPL2 license and did not screw with it then it would not have been a problem and people would have more choice over what licenses the Linux kernel could be used under.

Re:It's time for Sun

[Sancho]

ZFS is not currently licensed under GPLv3, so your argument is pointless.

Also, I have to agree with Linus' reasoning for taking out that clause. If the FSF went crazy and put really stupid terms in a later version of the GPL (for example, giving exceptions to the requirement that source be distributed), suddenly the Linux kernel could have become closed source. Linus' point, "Would you sign something before you had read it?" is perfectly valid, and in my opinion, not selfish at all.

Re:It's time for Sun

[TheLink]

Of course. ZFS on FUSE is stable enough for most Linux users.

But ZFS on FreeBSD is not for most _FreeBSD_ users.

Re:It's time for Sun

[LingNoi]

ZFS is not currently licensed under GPLv3, so your argument is pointless.

Linus's argument is that they're playing license games by deciding to license it as GPL 3 instead of GPL 2 because they then could not add that code to the kernel.

If the FSF went crazy and put really stupid terms in a later version of the GPL

They haven't done that so your argument is pointless and no one said they have to use later versions of the GPL license but what they have done is taken away the choice to use a different license. When GPL 3 comes out it doesn't automatically make GPL 2 licensed programs with the "or later" clause have to use GPL 3.

Taking the "or later" clause out though means there is no choice to switch in the future.

Re:It's time for Sun

[Sancho]

They haven't done that so your argument is pointless Nice attempt to mirror my own argument back at me, but I said if. You stated, indirectly, that ZFS was licensed under the GPLv3.

And you conveniently disregarded the point. If the licence terms of a later GPL aren't suitable to the copyright holder, then they shouldn't be used. It is, as Linus said, and as I quoted, very similar to signing a contract without knowing the terms. He would have been releasing software with no idea how it might later be used.

Linus wanted changes to his code to remain free. That wholly within the spirit of the GPL, and while I consider it to be annoying at times, I have to respect that he bucked the system and went with the modified version of the GPL, and I also respect his reasons for doing so. GPLv6 might not be backwards compatible with GPLv2, so modifications created under GPLv6 would have resulted in a forked kernel with proprietary extensions--wholly against the spirit of the (current) GPL.

Does he take away some choice? Sure. But doesn't the GPL do that already? Absolutely.

Re:It's time for Sun

[LingNoi]

If the licence terms of a later GPL aren't suitable to the copyright holder, then they shouldn't be used.....Linus wanted changes to his code to remain free....I have to respect that he bucked the system and went with the modified version of the GPL, and I also respect his reasons for doing so.

That is entirely his decision and now he has to live with that decision. Linus having a rant on a public mailing list at Sun because they are planning on releasing their code as GPL v3 instead of GPL v2 so it can not be used in the GPL v2 kernel is unacceptable.

It is Linus that put himself in that position in the first place by taking out the clause so the point that he is arguing that it is somehow someone else's fault is wrong since it is his own is doing by changing the GPL license.

Does he take away some choice? Sure. But doesn't the GPL do that already? Absolutely.

So Linus has to make the license even more restrictive to the point of preventing newer versions of GPL code going into the kernel and restricting development. From my point of view that would lead to a lot of problems in the next ten years or so when a lot of projects have all switched to the newer license or when no one wants to use GPL 2.

That doesn't mean development on the kernel would stop. I doubt it that would ever happen.

Re:It's time for Sun

[SnowZero]

No one is forcing you to use GPL code, and until they do, the viral nature of the GPL (it is viral, but it's amazingly easy to avoid, it doesn't leap from one directory to another and infect your code without your knowledge) is totally harmless to you. I've had it with you people! I'm going to develop an airborne variant of the GPL, capable of jumping from host to host, and call it GPLv4 (thus infecting all the "GPLv2 or later" code). It will be an OSS epidemic, and you'll see what happens to all that BSD/MIT code which does not have resistance to being infected by other licenses. Only then will the truly viral nature inherent in the GPL be appreciated, but it will be too late to prevent *BSD from dying, and the CDC and NetCraft will confirm it.

Re:It's time for Sun

[rbanffy]

"If a problem is detected, it's usually just a matter of portsnapping up a new ports tree and "make install"ing the port"

It must be bad not to have something as convenient as "yum update" or "apt-get update && apt-get upgrade" available. I have several servers doing things like that on cron and mailing me if they need further attention. It seems PC-BSD has something similar that is worth a look.

ZFS (the major reason I would consider for going BSD) rocks, but APT does rock too and I have managed to live without ZFS until now. ;-)

I can wait.

Re:It's time for Sun

[Sancho]

Linus having a rant on a public mailing list at Sun because they are planning on releasing their code as GPL v3 instead of GPL v2 so it can not be used in the GPL v2 kernel is unacceptable. I didn't see it as 'a rant at Sun.' In fact, if you actually read through it, all he's doing is pointing out that they are a company with shareholders to whom they are beholden, so don't read that much into their FOSS agenda. He wasn't complaining that they were releasing it GPLv3, he was pointing out to others the reasoning. Seriously, go read it. The posting is here: http://lkml.org/lkml/2007/6/12/232, but I'll quote an interesting piece of it:
Am I cynical? Yes. Do I expect people to act in their own interests? Hell
yes! That's how things are _supposed_ to happen. I'm not at all berating
Sun, what I'm trying to do here is to wake people up who seem to be living
in some dream-world where Sun wants to help people.

So Linus has to make the license even more restrictive to the point of preventing newer versions of GPL code going into the kernel and restricting development. From my point of view that would lead to a lot of problems in the next ten years or so when a lot of projects have all switched to the newer license or when no one wants to use GPL 2. I don't see how the license of usermode software is relevant, and any projects which aim to get included in the kernel are going to go "GPLv2 or later" (which is interoperable, legally, with the "GPLv2" kernel.) The only issue are when corporations have an agenda and want to specifically exclude Linux. They get the opportunity to do so by releasing their component as GPLv3 only. But you know what? Then they can't incorporate much of the Linux kernel code, so doing this could be detrimental.

Re:It's time for Sun

[Sancho]

portsnap is the equivalent of apt-get update. And you can actually use portmanager or portupgrade to upgrade all ports. I'm not a fan of doing this, however, unless there's a really good reason, e.g. a security vulnerability that we deem actually makes us vulnerable. Otherwise, software upgrades are just asking for trouble, so in these situations, I prefer to just upgrade the one port.

On my desktop, I use Ubuntu, and I do like apt. But on my desktop, I don't mind too much if I hose the OS--it's easy enough to reinstall. On servers, downtime is bad.

Of course, there are no binary updates (that I'm aware of). Maybe that's what you were referring to.

Re:It's time for Sun

[rbanffy]

There should be no non-security related updates on a stable OS (like Debian/stable), so, yum update or apt-get upgrade should never, ever hose the machine unless you are running a beta release. Servers should also have the least software possible installed on them (this includes unneeded compilers) so that less is exposed. While binary updates are nice, they are not essential. What is essential is proper configuration file change management. Most APT software updates nicely step around local configuration files and try not to overwrite what I may have changed, but provide nice starting points so I don't have to figure out how to do it from scratch.

Of course, I never used BSD very much, so, I may be in for a nice surprise.

Are there any BSD tutorials for those familiar with Linux and package management?

Re:It's time for Sun

[PygmySurfer]

Hah! Good point!

Re:It's time for Sun

[PygmySurfer]

My response can only be "wah wah wah". I'm tired of BSD-types telling everyone else what attitude they should have about software licensing.

So, let me get this straight - I'm telling others telling everyone else what attitude to have about licensing by asking the Linux community not to dictate to Sun what terms they should license their code under? That's rich!

Re:It's time for Sun

[PygmySurfer]

Frankly, I'm sick of the BSD community trolling GPL/Linux threads on Slashdot when they have no purpose commenting in the article at all. The constant "meh! Wouldn't have this problem with the BSD license" is the equivalent of the GPL zealot saying "Meh! Linux is superior to winblows"

Apparently you have the reading comprehension skills of a 3rd grader. Had drinkypoo not told me to "go run BSD" I wouldn't have even brought it up. My point was the Linux community should fuck off, and let Sun license their code under whatever goddamn license they want, rather than demand everything be GPL or GPL-compatible.

Re:It's time for Sun

[Sancho]

I don't know of any such tutorials. The handbook is a pretty useful read for FreeBSD. It has a section on ports, which includes very light information on portsnap, portupgrade, and portmanager. It also has information on the older cvsup method of updating your ports tree (roughly equivalent to apt-get update.)

I use the portsnap/portmanager combination, personally. It works well for me.

I definitely think that the ports system could use some work, however FreeBSD still wins out over Linux for manageability, in my opinion. I'm a big fan of the way that the base system is separated from installed ports (all ports are in /usr/local/, compare to some Linux distributions where they can be all over the place and intermixed with the base system). This sometimes causes a 'gotcha' for new users, who expect all of the configuration files to be in /etc--for installed ports, they are in /usr/local/etc. And init scripts are similarly divided, so that to restart Apache (which is not a part of the base system), you'd run '/usr/local/etc/rc.d/apache restart', but to restart OpenSSH (which is a part of the base system), you'd run '/etc/rc.d/sshd restart'. Some people don't like this separation, and would prefer unity of all init scripts, but it makes a certain amount of sense to me (and a lot of other people who love FreeBSD).

Anyway, if you give it a try, I hope you enjoy the experience.

Re:It's time for Sun

[LingNoi]

My point was the Linux community should fuck off

Pretty difficult to do when you troll every GPL and Linux thread!

Re:It's time for Sun

[PygmySurfer]

Pretty difficult to do when you troll every GPL and Linux thread!

Except I wasn't trolling, and I think this is really the first time I've ever said anything about the GPL or Linux that might be construed negatively (and it was really the Linux community, NOT Linux OR the GPL that I had a problem with).

I suppose this is Slashdot though, and anyone who doesn't suckle from the GPL teet is obviously a troll.

Limitations of Linux

[Anonymous Coward]

Seriously, not to start a holy war but doesn't this show a limitation of the "openness" of Linux. I mean FreeBSD was able to integrate it into the kernel (more specificaly with geom) because their BSD licensing structure doesn't put limitations on the code. But Linux's GPL seems to restrict development so that code is open as according to GPL... I'm still amazed more people don't complain about the way Linux is licensed and released.

Re:Limitations of Linux

[vialation]

People do not complain because they realize that the lack of openness that you greatly exaggerate is only to require GPL'd code to remain GPL'd. GPL is not a license of "openness" -- it is a mechanism by which to counteract copyright (by means of copyleft). It is restrictive in the sense that proprietary software has restrictions, but in the opposite manner. You must keep it free in the same way that you must keep propietary software closed and proprietary by law. My opinion is that this is a good thing for furthering the Free Software movement. Stallman tries to make it clear that the number of people using your code is of no importance, but rather that it remain free.

Can't you make a binary blob kernel module?

[nweaver]

Can't you just make a binary blob kernel module? I know the GPL zealots hate the idea, but wouldn't this also get around the liscencing problems?

Re:Can't you make a binary blob kernel module?

[jshriverWVU]

Can't you just make a binary blob kernel module? That is basically what they are doing. In the case of Nvidia they write the binary blob driver and have an OSS driver to interface between the kernel and the blob. In this case ZFS is using FUSE instead of creating it's own interface code into the kernel.

Re:Can't you make a binary blob kernel module?

[Wesley Felter]

Then a lot of "opener-than-thou" distros would refuse to ship the blob, making it harder for users to install, leading to very few users using ZFS-blob, leading to the developers wondering why they bothered. At least IMO.

Re:Can't you make a binary blob kernel module?

[hitmark]

and this makes me wonder if not they could create a fuse like system for display drivers.

oh wait, isnt that what X is? hell, its kinda like a mini-os inside the os...

but then i think i read something about a want for cleaning up how to do the display drivers as right now if X goes AWOL, one cant tell the kernel to retake control and give you a prompt to recover from. and jumping between framebuffer and X can be hit or miss iirc.

Never mind ZFS

[overshoot]

What I desperately need is a reliable caching filesystem with decent performance.

The $COMPANY network is loaded with Linux workstations and servers, all with their own lotsabyte drives -- and the only things those drives are used for is a tiny system image. Meanwhile the network is getting hammered.

I might not kill to get a several-hundred-gigabyte local network cache -- but don't tempt me.

Re:Never mind ZFS

[Krondor]

What I desperately need is a reliable caching filesystem with decent performance.

The $COMPANY network is loaded with Linux workstations and servers, all with their own lotsabyte drives -- and the only things those drives are used for is a tiny system image. Meanwhile the network is getting hammered.

Are you asking for a network based filesystem like AFS? Did I misunderstand your issue?

Re:Never mind ZFS

[mhall119]

I don't know about several-hundred-gigabyte, but Linux's smbfs does pretty good caching, better than NFS in my experience.

Re:Never mind ZFS

[belg4mit]

Network yes, AFS, probably not. Seems to me he wants a cheap distributed filesystem,
probably closer to something Google uses... networked JBOD. Of course he doesn't say
what he wants the cache for: Squid?

I'm guessing the hassle of managing AFS and its requirements (kerberos, synchronized
time, client-side cache) are more than he'd like just to recover some disk space.

Re:Never mind ZFS

[andrei_r]

One thing would be to migrate your Linux workstations and servers to Solaris x86, and use cacheFS.

"When you enable cachefs file system, the data read from the remote file system or CD-ROM is stored in a disk-based cache on the local system. Subsequent read requests to the same data are fulfilled by the local cache, which improves read performance."

Of course, a migration is not always an option, and I'm not sure if something like this available for Linux.

Re:Never mind ZFS

[bill_mcgonigle]

Of course, a migration is not always an option, and I'm not sure if something like this available for Linux.

Try the I'm Feeling Lucky search for 'linux cachefs'.

Re:Never mind ZFS

[Just Some Guy]

I'm guessing the hassle of managing AFS and its requirements (kerberos, synchronized time, client-side cache) are more than he'd like just to recover some disk space.

Kerberos? It's only hard the first time, and an Active Directory server will probably get you 99% of the way there (although I haven't specifically tried AFS against one). Time? apt-get install ntp-simple and be done with it; NTP should be absolutely mandatory on all networked devices anyway. The client-side cache is the only tricky part, but that was what he wanted to do in the first place. Oh, and I'm pretty sure he's wanting to trade local store for network usability, not vice versa.

Cheesy Intro to ZFS Video

[kaleco]

If you can suffer the bizarre presentation style Sun have used for this video, it's quite informative about the benefits of ZFS.

Re:Cheesy Intro to ZFS Video

[suv4x4]

Talking about bizarre presentation of technology, nothing beats a singing ensemble of hard drive parts and bits.

Re:Cheesy Intro to ZFS Video

[Anonymous Coward]

My first thought was: their accent is awful, sounds almost like mine. ;-)
And then it says "CSI: Munich", so they are Germans too.

Re:Cheesy Intro to ZFS Video

[this great guy]

Also, people interested in ZFS should read these slides: http://www.opensolaris.org/os/community/zfs/docs/z fs_last.pdf

Re:Cheesy Intro to ZFS Video

[kaleco]

Thanks for posting that link. Very interesting.

Why the big deal about booting from it?

[pair-a-noyd]

Really? Stick an old 20gb drive in as your boot drive and boot from whatever you have to to get up and going, load ZFS modules, mount all drives and enjoy. What's so terrible about booting from a different drive / file system? Most mobos now let you hang boatloads of drives of all types on them.
I can't think of any reason why it would be so terrible to boot up from an old 20gb with ext2/ext3 or anything else, then run the rest of your system under whatever. I'm doing that now anyway, I boot from ext2 then everything else is ext3. Doesn't make my performance suffer any that I can tell.

Besides, I suspect that most people that would run ZFS are the type of people that leave their machines up for months at a time. In that case, why the panic attacks over booting issues?

I hope they can find some way to resolve the license issues, I'm excited about ZFS (in concept and theory) and I would love to give it a go. Finally a system that's up with the times.

Re:Why the big deal about booting from it?

[drinkypoo]

Really? Stick an old 20gb drive in as your boot drive and boot from whatever you have to to get up and going, load ZFS modules, mount all drives and enjoy. What's so terrible about booting from a different drive / file system? Most mobos now let you hang boatloads of drives of all types on them.

By using a single boot drive you are introducing a single point of failure. But booting from a ZFS volume spread across multiple physical volumes means that even the boot process is protected by redundancy. It also allows you to enjoy all the many other benefits of ZFS, such as the RAID-like behavior, the ability to grow partitions, et cetera.

I can't think of any reason why it would be so terrible to boot up from an old 20gb with ext2/ext3 or anything else, then run the rest of your system under whatever.

That's because you lack imagination and, apparently, experience.

Besides, I suspect that most people that would run ZFS are the type of people that leave their machines up for months at a time. In that case, why the panic attacks over booting issues?

In a responsible work environment, we would like things to happen on time every time. That includes rebooting.

If a machine is up for months at a time, then it clearly did not get critical security updates, which often are in the kernel. You should never have uptime that high. High uptimes are for fanboys (my machine has been up for 369 days! and I've only been owned twice!)

Finally a system that's up with the times.

Actually, ZFS is missing a lot of functionality that we'd like to see in a modern filesystem. But it's a better effort than most.

Re:Why the big deal about booting from it?

[jimicus]

What's so terrible about booting from a different drive / file system?

Nothing per se, but AIUI ZFS allows you to specify how much (if any) redundancy you want, which with other filesystems requires setting up RAID separately which in turn adds complexity.

I suspect that most people that would run ZFS are the type of people that leave their machines up for months at a time. In that case, why the panic attacks over booting issues?

Generally speaking, the kind of system that you want to have up for months at a time is also the kind of system you want to come back up as quickly and painlessly as possible should something happen which causes/necessitates a reboot. That's one of the main reasons journalling was invented.

I'm excited about ZFS (in concept and theory) and I would love to give it a go. Finally a system that's up with the times.

Not sure about "up with the times". I have yet to see any convincing explanation of what amazing features ZFS offers which hasn't been in AIX's logical volume management system for years.

Re:Why the big deal about booting from it?

[wytcld]

a machine is up for months at a time, then it clearly did not get critical security updates, which often are in the kernel. You should never have uptime that high.

Depends on what the machine's doing, my friend. If you have dozens of people you don't know on shell accounts, sure, you better keep the kernel current - scheduled downtimes to do that are fine, and the inevitable kernel panics because the latest kernel introduces a new bug for your particular hardware configuration - well, the users will understand.

On the other hand, if you have no shell accounts, but just are running one or a few public-facing daemons, if you keep those daemons current, and follow solid security practices in configuring and using them, and lock down your firewall - well, if the kernel's stable, and your business's customers expect you up 24x7, why the heck should you want to be on the front lines testing the latest kernel release? In 14 years of running public-facing systems I've taken both strategies. I've had systems I kept on the bleeding kernel edge - and filed at least one fundamental bug report to the kernel folk about a most inconvenient cause of random kernel panic that took them months for them to eradicate. And I've had systems where I let the kernel get a few years out-of-date - and never had a system owned. Have I been lucky? Sure. But if you've kept running bleeding-edge kernels without downtime, you've been lucky too.

Re:Why the big deal about booting from it?

[Anonymous Coward]

If you are NOT running linux in your mom's basement, it really helps not having to put old 20gb disks in your systems. You don't have to use different physical disks to run different filesystems btw, just use partitions. Why boot from ext2? The only problem with booting linux i remember is the reiserfs and notail ordeal. Grub and lilo boots ext3 fine.

Re:Why the big deal about booting from it?

[drinkypoo]

On the other hand, if you have no shell accounts, but just are running one or a few public-facing daemons, if you keep those daemons current, and follow solid security practices in configuring and using them, and lock down your firewall - well, if the kernel's stable, and your business's customers expect you up 24x7, why the heck should you want to be on the front lines testing the latest kernel release?

Because all it takes is one remote hole in the kernel, perhaps in the IP stack or the firewalling code, and you have been owned.

By definition, unless you are using a proxy system for ingress, any holes in those systems are still quite accessible through the firewall if any services are exposed.

But if you've kept running bleeding-edge kernels without downtime, you've been lucky too.

I haven't, because I install security patches. The one time I didn't, I got owned (www.circus.com's index.html pages were all replaced by some group back in the day, probably through a known vulnerability.)

Re:Why the big deal about booting from it?

[Anonymous Coward]

Not sure about "up with the times". I have yet to see any convincing explanation of what amazing features ZFS offers which hasn't been in AIX's logical volume management system for years.

Checksumming. Ditto blocks. Creation of multi-terabyte file systems in seconds.

Re:Why the big deal about booting from it?

[larien]

Not sure about "up with the times". I have yet to see any convincing explanation of what amazing features ZFS offers which hasn't been in AIX's logical volume management system for years.

Ok, I'll bite on this one.

• Ability to detect & disk corruption. Say you get a bad block/corruption on the bus/bug in a driver; your lovely mirror now has 2 different sets of data. Under every other volume manager I'm aware of, you have to guess which one has the correct data and resync (generally the whole drive). ZFS will automatically detect the corruption, figure out which drive has the correct data (using a checksum) and resync the data to the "bad" disk.
• Filesystems grow & shrink on the fly with no intervention. You have a 100GB disk (mirrored of course...) with two filesystems on it, but due to workloads, data moves between them. During the day, /data1 has 80GB, /data2 has 10GB. At night, /data1 shrinks to 40GB but /data2 expands to 50GB during the batch; ZFS will let this happen with no intervention. You can also, if you want, allocate a minfree and max size of a filesystem if you want more control. You can shrink filesystems as of AIX 5.2 or 5.3, but that's fairly new and you'd need to manage it manually.
• Snapshots. They've been in various other VMs (e.g. Veritas) or filesystems (UFS snapshots have been in Solaris since Solaris 8 IIRC) but I don't recall them in AIX.

As for booting ZFS, the fact you could shrink or grow root & var filesystems is something new - Certainly, Solaris does not support resizing the root filesystem on the fly, even with Veritas on your root disks. The only way to resize is a backup/restore cycle (booting from CD) or using something like Live Upgrade (build a new image on some spare disks, then boot into it).

Re:Why the big deal about booting from it?

[Vancorps]

I didn't appreciate the parent's tone on this as you've said, both methods can and do work for a lot of people.

This is why a lot of us do a hybrid approach, a cluster which is up to date and a cluster with the previous release. If the current release is working out then you update the previous release servers to current and the clusters switch roles. This ensures zero downtime as a new release causing a kernel panic will result in a the other cluster taking over duties. Not an inexpensive solution but it does indeed work and is not technology difficult or even complicated to implement.

For more cost conscious environments I've got a server or two public facing, when it's update time I have a third server with identical hardware, do my testing, do a load simulation and you have enough confidence to move forward upgrading one public server, then the next. Not a 100% solution but if you're cost conscious it's your best bet.

Re:Why the big deal about booting from it?

[pair-a-noyd]

Of course it does. But booting is a one shot deal. Does it really matter if your boot drive (or partition) is journalled or not? The amount of time spent in the boot drive is in the order of a few seconds. Once booted you don't go back there again until next time you boot. AFAIK.

As for why I use old 20gb drives to boot from, well, I have LOTS of them laying around. Why not?
If something happens to it I can always stick another in and I'm back up. I just dd my working boot drive to a spare and set it aside. I have a replacement drive I can drop in and never skip a beat.
I have LOTS of hard drives here. And now that bigger drives are so dirt cheap, I see no reason not to spilt my system up and spread it about on multiple drives. No single point of failure. I have mirrored my critical drives to spares and I promise you, I won't be having any catastrophic failures or data loss.
I may experience some annoying down time for a bit to change drives out but I can live with that.

I'm looking forward to ZFS, I have a LOT of computers here with a large variety of file systems running and it would be interesting to have 100+ computers running ONE file system.

Re:Why the big deal about booting from it?

[Hatta]

Wouldn't you like to be able to boot in the case of a hard disk failure because your / is mirrored on several different disks? Or maybe you'd like your system to run faster because it's striped across several disks?

Re:Why the big deal about booting from it?

[Sancho]

A hybrid approach is the best approach. If a kernel update includes a patch for a remote hole, of course you fix it. If it's a local exploit, you have a lot more leeway. It all comes down to your configuration, but in general, I don't think that it's a best practice to upgrade to the latest Linux kernel unless it's necessary. There are just too many changes that aren't due to security issues.

I like FreeBSD a lot because of their kernel development policy. You can track the security branch of the kernel, which exclusively addresses security issues. Or you can track the stable branch, which is usually pretty stable, contains no ABI changes (so you generally don't need to recompile userland software), but it contains performance and feature updates. Or, of course, you can track -current. But you get the choice--you can get security updates without feature updates, which is essential for production services (in my opinion).

Re:Why the big deal about booting from it?

[marcansoft]

Use a tiny RAID1 DOS partition on every one of your redundant drives. GRUB will read that just fine, and it'll be able to boot from any one of them. Then, just use the rest of the space as a physical volume for LVM, md, or whatever the ZFS equivalent is.

Re:Why the big deal about booting from it?

[Anonymous Coward]

I stand corrected, thank you for the detailed explanation. As strictly a Windows hacker, this Linux stuff is relatively new to me.

Re:Why the big deal about booting from it?

[Anonymous Coward]

DOS partition? Yuck. Doesn't even have journaling. And who says I use RAID-1? Look, we're all quite able to imagine this kind of ugly hack but most would have used Ext3. Doesn't matter it still remains what it is: an ugly duck of a hack.

Re:Why the big deal about booting from it?

[heson]

Strange, I remember clearly that I did lvextend then e2fsresize without any reboots on my ext3 root partition yesterday. But yes, zfs is cool and is atleast a coupple of years ahead in its combined features.

Time for L4 / Coyotos / Mach / Hurd?

[Anonymous Coward]

Maybe a microkernel OS wouldn't have this problem. But then again, people can put any restrictions they want in a license, can't they?

Most important distinction is not kernel-space (or monolithic) vs. user-space (or microkernel) but rather whether the license allows linking with incompatibly licensed software. I.e. if the relevant parts of the OS have an LGPL-like license rather than GPL-like.

Lets be realistic

[dilvish_the_damned]

there's hope that performance tweaking could yield a practical elimination of barriers

Hows that memory copy from userspace comming, has it healed up yet?

God damn you slashdot

[EvilRyry]

I almost jumped out of my skin when I read the headline... then they threw in the little tidbit of information that its running through FUSE. I certainly appreciate the work that went into it, but I'm quiet certain FUSE will never catch up to in-kernel filesystems for speed and performance.

Re:God damn you slashdot

[Zantetsuken]

Either way, its a start towards getting support on whatever the underlying OS is to support someodd filesystem until the licensing bs can be worked around...

Parts of ZFS already GPLv2'd

[andrewd18]

According to Darren Moffat at SUN, parts of ZFS are already licensed under the GPL v2. Maybe there is still hope for a native solution. Not, of course, that I mind using FUSE.

http://blogs.sun.com/darren/entry/zfs_under_gplv2_ already_exists

Now about that headline, yes I really did say that ZFS code is already available under the GPLv2. I will be completely honest though and make it clear that it isn't all of the ZFS source. It is, sufficient amount to be able to boot an OpenSolaris based system from GRUB, that means that support for mirroring and the checksum and compression support is there but radiz isn't nor are the userland commands. It is possible that this might be enough to get someone started. Still don't believe me check out the updated GRUB source on opensolaris.org, specifically all the files with zfs in their name - every single one of them under the GPLv2 or later.

Re:Parts of ZFS already GPLv2'd

[harry666t]

afaik the problem with ZFS under linux is not ZFS not being GPL, but software patents that Sun is holding on ZFS. The only (free) way to use ZFS and not infringe any patents is through Sun's license, but I might be wrong...

Re:Parts of ZFS already GPLv2'd

[thesandbender]

Lets be more specific... ZFS (as a whole) is not GPLv2'd.

From the TFP : Now about that headline, yes I really did say that ZFS code is already available under the GPLv2. I will be completely honest though and make it clear that it isn't all of the ZFS source.

Well that's fantastic... which parts do we get? The ones that make ZFS revolutionary or the ones that make it a rehashed XFS, JFS, Rieser, etc? I don't see how this is any different than any of the bait-n-switch scams that people post to /., digg or other sites. Yes... you can use "part" of the FS but if you want the whole thing you'll have to use Solaris or FUSE (or BSD as others have pointed out).

FUSE defeats the entire purpose. ZFS is meant to run and support a large/huge file store. What admin in their right mind would do that through userspace unless it's solely for backup?

The point is, ZFS is not functionally viable for Linux on the environments for which it was intended.

Re:Parts of ZFS already GPLv2'd

[irgu]

"FUSE defeats the entire purpose. ZFS is meant to run and support a large/huge file store. What admin in their right mind would do that through userspace unless it's solely for backup?"

Who doesn't want his system to crash when a transient hardware error hit non-redundant ZFS kernel code.

Re:Parts of ZFS already GPLv2'd

[Anonymous Coward]

What admin doesn't have a backup of their large/huge file store?

Have you seen the benchmarks of NTFS-3G? It is quite fast. In fact, IIRC, Minix proved userspace drivers including FS can be very fast. If I recall there was only 10% performance loss. And for that you do get a lot of benefits like the whole system would not crash if the FS driver crashes.

"ZFS is meant to run and support a large/huge file store."

Yes, it is primarily aimed for those purposes, but would also serve on laptops, workstations, servers and desktops. Various people and blogs have posted about that. Yes, even including Sun employees.

The headline...

[Savage-Rabbit]

ZFS On Linux - It's Alive! Shouldn't it be more like:

ZFS On Linux - It's Alive!! IT IS ALIVE!!! MWUHAHAHAHAHAHAHA!!!!!

The manic laughter is especially important!

Re:The headline...

[evil_aar0n]

They covered that in the "dept." identifier...

Re:The headline...

[Fred Ferrigno]

Maybe I've been watching too much late night TV, but in my head I "heard" it as the intro to Robot Chicken. No maniacal laughter, just a chicken clucking.

Re:The headline...

[ThePengwin]

And then Voltron got served.....

I don't think the GPL is what Sun dislikes...

[Anonymous Coward]

> The GPL "everything under our license" philosophy is the sole cause of these so-called "license issues". If Linux wants to use Sun's code, why should Sun have to release it under Linux' license?

Given that Sun promised to GPLv3 it, the problem might be more than Linux uses an outdated version of the GPL than that they use the GPL at all.

They may not be doing it out of benevolence, but Sun did open Java, so I'll give them at least some credit. Heh, even my captcha is 'eclipse' ...

Re:I don't think the GPL is what Sun dislikes...

[BrainInAJar]

Sun made no such promise.

Sun said they might look in to it, nothing more.

The CDDL is a perfectly fine license, it's similar to what Apache & Mozilla use, and one that the current OpenSolaris community seems quite happy with.

Forget ZFS - go native with btrfs

[Anonymous Coward]

There's a Linux filesystem under development that might be able to compare favourably with ZFS if shown some love by developers:

* http://oss.oracle.com/projects/btrfs/
* http://kerneltrap.org/node/8376

Avoid the license squabbles and do what we do best: build it ourselves, only better.

Re:Forget ZFS - go native with btrfs

[Part`A]

I don't care how smart you are, or what your history is, if it's a file system I would want it very well tested before I trust it with any of my data. To move from the point of "Btrfs is not suitable for any uses other than benchmarking and review" to I'll rely on it for my company's primary server will be at least a million hours worth of real world use, after the code is finished.

Re:Forget ZFS - go native with btrfs

[swillden]

I'll rely on it for my company's primary server will be at least a million hours worth of real world use, after the code is finished.

Code is never finished.

Re:Forget ZFS - go native with btrfs

[Part`A]

Of course, after it's feature complete and declared stable then if you must..

Legal question

[TopSpin]

Why couldn't ZFS be distributed separately in kernel module form and installed by the user? Ubuntu and others integrate mscorefonts, NVidia drivers and others this way. Is the OpenSolaris license so heinous that it's worse than those examples?

I doubt it.

Re:Legal question

[Yvanhoe]

Well yes, it is that heinous. It would simply be illegal under current terms to run it this way. It would be interesting, however, to develop such a rogue project and see if Sun is really OSS friendly or if they would be ready to send cease and desist letters to such a project. Linus suggests that Sun's apparent friendliness toward linux and OSS is only a pose, let's figure !

Re:Legal question

[Anonymous Coward]

Actually, there is nothing wrong with Sun's license. The problem is the GPL, which does not allow CDDL code to to link to it; so the Linux foundation would be the one sending C&D letters to that project, since it would violate the kernel's GPL.

Re:Legal question

[Yvanhoe]

Point taken.
It still would be interesting to see a kernel patch project that would add this useful feature to the kernel and watch it being kept away because of a license disagreement. Maybe it would point out the absurdity of all this. There would be one project that wold be legal and one that would work better.
Anyway a way to make Sun react would be to license this project under the GPL

Re:Legal question

[bill_mcgonigle]

Is the OpenSolaris license so heinous that it's worse than those examples?

It's not just that, OpenSolaris is 99.44% likely to be GPL3'ed when GPL3 is ready.

But GPL3 and GPL2 aren't even compatible. This is my only complaint about GPL3 and I see ZFS as being at Ground Zero of a coming GPL2/GPL3 fustercluck. We ought to see a few stories a week on GPL2/GPL3 problems over the next few years.

Just wait until Debian switches to the OpenSolaris kernel....

Re:Legal question

[burndive]

Actually, there is nothing wrong with Sun's license. The problem is the GPL, which does not allow CDDL code to to link to it; so the Linux foundation would be the one sending C&D letters to that project, since it would violate the kernel's GPL.

Only if you distribute binaries.

There is nothing that stops me from developing and distributing a version of Sun's ZFS such that it works with a Linux kernel. I can do anything I want with GPL code while I have it, including link it with my CCDL patch (and publish said CCDL code under the CCDL license), as long as when I distribute GPL source or binaries, I abide by the terms of that license.

Re:Legal question

[smiltee]

This is what I think since the beginning. Seriously, if someone would write a ZFS module for the kernel, what's the problem? Linux developpers can call this illegal, everybody will use it anyway.

True, even Linux uses this approach

[Anonymous Coward]

Very true. And its not just drives which matter here; basicly you're talking filesystems so this issue can simply cover several partitions. Just take a look at the latest Ubuntu and try to install it onto a single partition. You'll get an error warning you that Grub might have a problem with this setup and that its adviced to use a seperate /boot partition or use Lilo.

If thats "commonly accepted" (I know I'm generalizing) then whats so bad about doing the same with ZFS? Maybe because this gem is a Sun product and no matter what Sun does for the open source movement as a whole or, in this thread, Linux in particular some people simple need to have something to whine about. Ofcourse thats just my 2 cents here.

Wow... nice duct-tape OS, Lunix d00dz!!!

[Anonymous Coward]

Wow, how cool is it to run your file system with the same priority given to a web browser or music player. But hey, it's ONLY a file system!!

Keep duct taping stuff onto Lunix, d00dz!! It's what made Lunix the #1 operating system it is today!

Re:Wow... nice duct-tape OS, Lunix d00dz!!!

[FunkyELF]

Funny and sad at the same time.

kernel patch?

[FunkyELF]

Why couldn't this be implemented in the kernel and have the patches to that kernel be hosted in a country which doesn't care too much about licensing?

Re:kernel patch?

[burndive]

Why couldn't this be implemented in the kernel and have the patches to that kernel be hosted in a country which doesn't care too much about licensing?

Why hide? Nothing in the CCDL or GPL licenses prevents you from publishing a CCDL patch to a GPL kernel. Publishing the patched kernel source or binary might run you into some problems, but I don't see anything preventing you from publishing the patch itself.

Please correct me if I'm wrong.

Re:kernel patch?

[eklitzke]

Because it's GNU/Linux, not GNU/Warez.

That's great!

[greginnj]

... but does it run on Plan 9 ?



/me ducks ....

Re:That's great!

[BattleBlow]

Maybe not, but it does run on FreeBSD.

Good to see Linux catching up. Too bad it won't be in the kernel for you ;).

Re:That's great!

[Etyenne]

... but does it run on Plan 9 ?

Nobody care about Plan 9. The real question is: does it run on Haiku ?

Re:That's great!

[notamisfit]

Mainly because the FreeBSD kernel is the "Heinz 57" of software licenses. CDDL? Sure, why not? Binary-only? Go right ahead! I'm surprised they haven't stuck the nVidia display driver in there for x86.

sounds really great and all

[MadJo]

But does it run on Windows?

"The FSF guideline is"

[Per Abrahamsen]

The FSF has used the syscall interface as a guideline to determine whether something is a derived work or not. It is a guideline, not a hard rule though, and I suspect they would consider user-space ZFS for a derived work using a technical trick to avoid being linked into the kernel. I.e. infringing. However, since the FSF doesn't own the kernel, their opinion on the subject doesn't matter.

Re:"The FSF guideline is"

[pthisis]

The FSF has used the syscall interface as a guideline to determine whether something is a derived work or not. It is a guideline, not a hard rule though, and I suspect they would consider user-space ZFS for a derived work using a technical trick to avoid being linked into the kernel. I.e. infringing. However, since the FSF doesn't own the kernel, their opinion on the subject doesn't matter.

OTOH, some respected kernel developers (e.g. Alan Cox) certainly have explicitly said they believe binary kernel modules must be GPL and that things like nvidia's drivers are probably infringing. Not exactly the same thing but it's enough that I'd still call this a grey area until it's tested.

Re:"The FSF guideline is"

[Paul Jakma]

The FSF has used the syscall interface as a guideline to determine whether something is a derived work or not.

I don't believe that's true. I think you're thinking of the explicit exemption Linus put in the COPYING file of the Linux kernel to say that the syscall interface was a GPL interface (there are Linux contributors who disagree to an extent with him on that).

Why is it called "128-bit"?

[ari_j]

I have been wondering this for awhile now and I finally have a relevant story to ask it on: Is ZFS 128-bit or not? It claims to be 128-bit, but Wikipedia gives:

• 2^48 - Number of snapshots in any file system (2 × 1014)
• 2^48 - Number of files in any individual file system (2 × 1014)
• 16 EiB (2^64 bytes) - Maximum size of a file system
• 16 EiB - Maximum size of a single file
• 16 EiB - Maximum size of any attribute
• 256 ZiB (2^78 bytes) - Maximum size of any zpool
• 2^56 - Number of attributes of a file (actually constrained to 2^48 for the number of files in a ZFS file system)
• 2^56 - Number of files in a directory (actually constrained to 2^48 for the number of files in a ZFS file system)
• 2^64 - Number of devices in any zpool
• 2^64 - Number of zpools in a system
• 2^64 - Number of file systems in a zpool

What is it about ZFS that leads to it being a 128-bit filesystem?

Re:Why is it called "128-bit"?

[imbaczek]

128 bit addresses, perhaps?

Re:Why is it called "128-bit"?

[ari_j]

Define "address." That was the thought I had, but I couldn't find anything that actually specified a 128-bit pointer to data in ZFS.

Re:Why is it called "128-bit"?

[Anonymous Coward]

[In Nigel Tufnel accent]

It's 64 better.

Re:Why is it called "128-bit"?

[Anonymous Coward]

The addresses (known as DVAs, or "data virtual addresses") used in the SPA (storage pool allocator) are 128-bit. This is currently divided into a 63-bit offset within a vdev (virtual device), 32-bit vdev id, and some additional bits for implementing RAID-Z and fragmented (gang) blocks. For more information, see:

http://src.opensolaris.org/source/xref/onnv/onnv-g ate/usr/src/uts/common/fs/zfs/sys/spa.h#107

However, the ZPL (ZFS POSIX layer) and DMU (data management unit) currently use 64-bit object identifiers based largely on the fact that no 128-bit POSIX interfaces exist (open128, stat128, etc). This could be changed in the future without affecting the on-disk block pointers, but for the time being the maximum size of any filesystem is 2^64.

Re:Why is it called "128-bit"?

[ari_j]

So ZFS supports a smooth expansion from a current limit of 2^64 bytes per filesystem to a future limit of 2^128 bytes per filesystem?

Re:Why is it called "128-bit"?

[Anonymous Coward]

That's great captain obvious. Only Sun forgot one thing. There are about 2^256 particles in the known universe. So, even in the best case were one particle is used to encode one bit, you will never be able to actually use all those amazing features of ZFS -- not in this dimension at least.

ops?

crackhead idea

[Anonymous Coward]

You need a server to run samba. it needs decent CPU.

You need NBD (network block device) clients on all those workstations with the spare disk.

Your samba server uses these NBD blocks in a RAID5+1 or whatever, array, which exports to the network. ... your network then melts under doubled traffic for disk requests, probably :)

CacheFS

[Wesley Felter]

Red Hat is working on it.

For... Windows

[suv4x4]

Don't kill me now - but ZFS looks like something all OS should support. With the great innovations of this file system, it just looks wrong to be confined to any given OS or a set of OS.

Now... NTFS supports some of the stuff (not all) found in ZFS, but it's proprietary, so it doesn't qualify.

Re:For... Windows

[EvilRyry]

ZFS is proprietary as well, hence the issue. Just because its open source doesn't make it open.

As a side note, I hope ZFS+Linux stories hit the front page more often... maybe it'll convince Sun to GPL ZFS, or atleast give the green light on a GPL port. :-)

Re:For... Windows

[Anonymous Coward]

What exactly is innovative in ZFS?

Re:For... Windows

[itzdandy]

it is completely open source and completely open. it has no restrictions in use period.. have you read the license? the GPL is the less open of the two, by virtue of forcing any GPL'd code into remaining GPL.

ANALOGY WARNING:
this is like the difference in having free beer until you grab it, then it becomes your beer(CDL)
VS.
having free beer that is still everyones beer even after you have pissed it out, then some barley soaks it up, then it is brewed back into beer and it is still everyones beer.(GPL). in fact, the analogy would be better to say the the GPL forces you to save your pee, then poor that pee on some barley and tag the barley as 'beer barley per GPLv2', then harvesting and brewing that into beer which then needs to be labeled 'beer brewed in accordance with GPLv2' and then must be given away OR the recipe must be given away via the internet or for the cost of delivering the formula on CD.

i like the GPL, but the other OSS licenses are also quite good

yeah horsey

[genner]

The horse is still alive lets poke it till it moves.

Re:yeah horsey

[genner]

Wow sleep depervation takes it's toll. I could have sworn I posted this on the wow forms.

ZetaBytes?!

[sheepzilla]

I don't have a ZetaByte Disk, and I'm not going to any time soon, so why do I care about a ZetaByte files system!
Anyone who can afford that much storage can afford to pay a little for a driver built however they like. ... At least for the immediate future.

Re:ZetaBytes?!

[itzdandy]

i believe the point is that there are no real filesystem limitations to worry about and the point is being made with some emphasis

Re:ZetaBytes?!

[Anonymous Coward]

You can get significantly closer by combining disks...

Re:ZetaBytes?!

[sheepzilla]

One zettabyte is a billion terabytes, even combining disks thats quite a lot.

Re:ZetaBytes?!

[sheepzilla]

The real limitations of any system are the hardware ones, after all no matter how clever your file system is, it can't beat thermodynamics. I find it quite remarkable that an assumption is blindly made that the hardware will keep up with exponential growth, although i admit that is likely for the foreseeable future.

I acknowledge that sure, something like this may be necessary one day, some people are very foresightful!

But, doesn't Linus...

[msauve]

hold the copyright to the Linux kernel? It seems to me that he must, as everyone seems to agree that he has control over what license it is issued under (see discussions of GPL v2 vs. v3). If the kernel copyright is not entirely held by Linus, then he would have to get unanimous consent to make any change (impossible?), if he at some point wanted to move to GPL3, right?

So, if he controls the copyright, he can place it under a "GPL plus you're allowed to link ZFS" license. Where's the problem?

Re:But, doesn't Linus...

[tolan-b]

No he doesn't.

Re:But, doesn't Linus...

[Sancho]

He certainly owns the rights to parts of the Kernel, and thus his opinion on the matter has some importance. However he has incorporated patches into the source tree without requiring that the copyright be turned over to him, and thus, just about everyone who has contributed to the kernel collectively 'holds the copyright' to it.

The Linux kernel, for better or for worse, is going to be stuck at GPLv2.

Re:But, doesn't Linus...

[Anonymous Coward]

Someone asked a question and I answered it. How is that redundant?

Re:But, doesn't Linus...

[Anonymous Coward]

You're and idiot, that's how.

Re:But, doesn't Linus...

[Anonymous Coward]

Someone asked a question and I answered it. How is that a troll?

Re:But, doesn't Linus...

[slash.duncan]

> The Linux kernel, for better or for worse, is going to be stuck at GPLv2.

What you said previously is AFAIK correct, but this conclusion doesn't necessarily follow.

1) Until Linus changed the default kernel license to GPLv2 only, submitted code would have been GPLv2 or later by default. That's a lot of code, and it's the older code which would presumably be the most problematic in terms of tracking down authors to even discuss license changes.

2) Note the "by default" in the above. Any GPLv2 compatible licensed code can be merged, and there's a significant amount of code that's under 3-clause BSD or similar "less strict" license terms, or specifically GPLv2 or later, even if merged after the default changed.

3) Assuming an agreement between the major contributors to head toward GPLv3, and not to merge additional GPLv2 only code, a huge portion of what remains could be switched to GPLv2/v3 dual license "overnight".

4) Finally, some contributors have merged code with a "GPLv2, but I give person X (where X is generally Linus, Alan Cox, or similar well recognized major kernel contributor) the authority to make licensing decisions in my stead" type license/agreement. Obviously, if the assumption of #3 is correct, most or all of this code can equally be license switched overnight.

The above four categories would cover, wild but reasonable guess, 2/3 of the code base. Given the rate of kernel code churn, with no additional effort, only changing the default for new code to GPLv2/v3 and not accepting anything not compatible with both, within say five years, half to 2/3 (again, reasonable WAG) of the remaining code will be taken care of, simply due to code churn.

That would leave, using my for sake of argument "reasonable WAGs", ~11% of kernel code as needing further attention. Of that, it's fairly safe to assume half of the contributors will be easily found and readily agree to dual license their code GPLv2/v3.

That leaves ~5% of the current codebase as problematic. If there's anything the Bitkeeper thing demonstrated, it's how fast the kernel community can turn on a dime, code-wise, if it's in their interest and common agreement to do so. If over that same five year period, the first two years little is done besides "watchful awareness", waiting to see what areas change on their own, then years 3-4 can get increasingly focused on changing the remainder. That simple act of increasing focus is likely to half the remaining problem code again, so we're now down to perhaps 2% of the current code base for the final year's attention, with probably two releases focused almost entirely on license based code rewrite (staggered with 1-2 regular releases between them). With the code churn numbers Andrew has tracked and discussed several times since 2.6.0, 2% code base rewrite is certainly possible.

After the last GPLv2 only code has been removed, the kernel would be fully GPLv2 AND v3 compatible, and it would be legally possible to drop the GPLv2 side of the license, leaving only GPLv3 as the default for further new code, and GPLv3 compatibility fully required.

Thus, it /could/ be done, but it would be a HUGE effort, would require the general consensus agreement of nearly every one of the major contributors since the default changed to GPLv2 only, and would take some serious time. I expect it could actually be done in less than five years if required by say patent attacks or the like, but believe it's still safe to say it'd take two, minimum, and likely at least three. Five, however, should certainly be doable, PROVIDED there's consensus agreement that it's needed.

Linus doesn't hold copyright on all the code in the kernel, certainly, but he's certainly the pivotal consensus leader. If he doesn't think it's worth moving the kernel to GPLv3, it simply won't be done. If he DOES decide it's worth doing, THEN it's a question of whether a consensus agreement can be reached with all the other major kernel contributors as well. It's no

Re:But, doesn't Linus...

[Anonymous Coward]

You're and idiot

"an".

A selling point for microkernels?

[iPaul]

I often like the u-kernel/hybrid kernel idea of running stuff in userspace as opposed to kernel space for security, extensibility, etc. etc. However, I never would have thought licensing issues. However, what if we did start running more parts of Linux in user-space, creating a hybrid kernel, to get around licensing? Don't want to play with GPL? That's fine, just user-space it. Of course, the down-side is some XYZ Linux distro with all sorts of stuff running in user-space because of licensing restrictions. The idea of trading performance for legality (as opposed to a "real" issue like security or reliability) is somewhat unappealing.

After a quick port...

[hhcv]

Maybe it is time to rejig FUSE as a kernel module? *ducks*

Re:After a quick port...

[Anonymous Coward]

FUSE is a kernel module.

Re:After a quick port...

[Anonymous Coward]

I really can't tell...was this meant as a troll?

Re:After a quick port...

[irgu]

"FUSE is a kernel module."

FUSE is a kernel module, a user space library (libfuse), a user space helper application (fusermount) and a user space helper script (mount.fuse). Well, at least :-)

Interesting

[drix]

This is an interesting development in light of recent comments made by Linus about Sun and ZFS in particular, to which Jonathan Schwartz wrote a personal response.

no C structures larger than 64-bits

[Anonymous Coward]

16 EiB (2^64 bytes) - Maximum size of a file system
16 EiB - Maximum size of a single file
16 EiB - Maximum size of any attribute
256 ZiB (2^78 bytes) - Maximum size of any zpool

It is 128-bit clean, the problem is that ANSI C does not provide an data types larger than 64-bits, so they can't actually write (portable) data structures any larger.

Once ANSI defines larger 'int's (96? 128?) then you can write code.

Sun could probably use some kind of bignum library if they wanted to, but since they have not hit 64-bit restrictions on volume sizes yet there's no rush at this moment. They're just planning ahead a decade so they won't have to switch to another FS in the future. UFS lasted for about twenty years and they're hoping ZFS will last just as long.

According to some basic math it would take as much energy to boil the earth's oceans to flip every bit on a 128-bit file system.

NBD

[bill_mcgonigle]

Stick an old 20gb drive in as your boot drive

That's *way* overkill. Grub can read minimal ZFS - just have Grub pull off an initrd image from your '/' drive (ZFS), load it into RAM (it'll be ext2 or squashfs or something the kernel can handle) and include a zfs.ko module on the initrd. Load it into RAM, do a pivotroot onto your ZFS / drive, and continue along your merry way.

The 'you can't boot off of ZFS' canard is just a bit of hand-waving by the Sun-haters who are afraid of ZFS. We Sun-haters who like ZFS know how to hack around half-truths.

Ah, well then...

[msauve]

Thank you for the informative response, it was much better than the other "no" one.

If I understand things correctly, it is possible for users to legally compile the Linux kernel and ZFS together, the sources may even be distributed together as long as there are no pre-linked binaries (ready to run). That should make it possible for a distribution to compile ZFS support into the kernel at install time (i.e. by the user, for their own use, not for distribution).

Re:Ah, well then...

[Sancho]

I'm not qualified to comment on this (read: I am not a lawyer), however I think that this still may be legally questionable. Because the CDDL ZFS files won't compile cleanly without modification to make them work with the Linux kernel, and because those modifications could be considered derivative works, it's possible that you'd be creating source files which are derivative works of both ZFS (CDDL-licensed) and Linux (GPLv2-licensed). Such a derivative work cannot be distributed legally.

Re:Ah, well then...

[cibyr]

This is what's wrong with copyright law: it is supposed to encourage the creation of new works, but in situations like this it actually prevents the very thing it was created for.

Re:Ah, well then...

[Sancho]

Yes, there are many times when copyright prevents the creation of new works. For example, I can't modify Harry Potter 6 so that Dumbledore doesn't die at the end and re-sell it. At least, not until the copyright expires. Once the copyright expires, you get great works like Wicked and Son of a Witch, both of which are based upon The Wizard Of Oz. Of course, no more copyrights will ever expire, thanks to greedy copyright-holding corporations and a corrupt government.

The idea, though, is that the work which you wish to modify might not have existed at all had copyright not existed. The person who created the work might not have desired to if s/he wasn't going to be able to sell it. Or they might not have been able to devote their lives to their craft, and thus ended up not having enough time to create as much. I highly doubt that the entire library of Stephen King would exist today if he wasn't a professional writer, paid for his craft.

It's obviously impossible to know what might have been, but I think that the reasoning behind copyright (in general) is sound. The problems in the current implementation are that copyright is effectively endless (meaning that the creation of new works based on the original is forever forbidden--forever being the key word) and that fair use rights are going out the window.

Re:Ah, well then...

[Anonymous Coward]

For example, I can't modify Harry Potter 6 so that Dumbledore doesn't die at the end and re-sell it.

Thanks for the spoiler. Any other critical plot surprises you'd care to ruin?

Way to shit on an otherwise thoughtful post.

Re:Ah, well then...

[Anonymous Coward]

I can't modify Harry Potter 6 so that Dumbledore doesn't die at the end

Thanks for the spoiler, you stupid fuck.

Isn't that...

[msauve]

what "patch" is for? (i.e. distribute virgin source code, along with scripts and diffs which can fix/compile everything).

Re:Isn't that...

[Sancho]

I would consider a patch to be a derivative work. I don't know what the courts think on that matter.

Though I guess it worked for LAME....

Re:Isn't that...

[Marillion]

I think the thorny issue is which license applies to the patch? Is it CDDL or GPL? Arguably both or neither could.

It is a shame that two open source licenses are preventing users from utilizing both Linux and ZFS.

Re:Isn't that...

[Sancho]

Indeed, this is true, however I wouldn't be surprised if Sun's CDDL was deliberately designed to be incompatible with the GPL.

Re:Isn't that...

[Kymermosst]

I get around that problem by simply running Solaris on Sun boxes as my preferred server platform.

Seriously, I don't need drivers for obscure hardware or shiny video cards to serve files, DNS, web pages, etc.

Re:Isn't that...

[drsmithy]

I would consider a patch to be a derivative work.

Huh ? Would you consider random notes pulled out of a musical performance, or random words pulled out of a book, to be a "derivative work" as well ?

Re:Isn't that...

[Sancho]

A patch does not contain random information, but nice strawman.

Re:Isn't that...

[drsmithy]

A patch does not contain random information, but nice strawman.

Yes, it does. A patch (typically) cannot stand on its own as usable, compilable software and usually doesn't even contain syntactically correct statements. It is source-code gibberish, meaningless without the source it is patching.

In that, it is similar to my analogy. Certainly, by pulling out random notes and sounds you will get the occasional grammatically correct sentence fragment, short tune, or proper chord - but without the context of the original document or music, they are simply random, meaningless, words and sounds.

Re:Isn't that...

[Sancho]

You clearly do not understand the word random.

A patch is structured, and further, contains specific (nonrandom) information on how to transform an input file into a previously created output file. It is, by definition, derived from two input files.

Furthermore, you appear to believe that a derivative work must somehow have structure or purpose similar to that of the original work. If I take Stephen King's The Gunslinger novel and remove every other word, I have created a new work derived from his. The novel might be somewhat readable, and it might not be. However it is clearly derivative.

Taking this further becomes tricky. What if I remove two out of every three words? It's probably still clearly derivative. Three out of every four? Maybe. It eventually becomes difficult to prove that the work is derivative--however this does not apply to patch files, which are reversible by design.

Re:Isn't that...

[drsmithy]

You clearly do not understand the word random.

In hindsight, perhaps "arbitrary" would have been a better word.

A patch is structured, and further, contains specific (nonrandom) information on how to transform an input file into a previously created output file. It is, by definition, derived from two input files.

An SSH public keyfile, too, is structured, and further, contains specific (nonrandom) information that facilitates transforming input data into output data.

An SSH public keyfile, however, is still just a few strings of randomly generated characters.

Furthermore, you appear to believe that a derivative work must somehow have structure or purpose similar to that of the original work.

I believe that a derivative work must bear some resemblence to the work from whence it is derived and must actually be a coherent "work" in and of itself. After all, if that were not a requirement, surely any random jumbling of sounds or words that just happened to also be present in another piece of music or literature could be deemed derivative (or vice versa), could it not ?

Personally I find the whole concept of a "derivative work" - pretending for the moment I believe in the concept of "intellectual property" at all - to be forced, counter-intuitive and fundamentally ignorant. A "derivative" work is either so similar to the original that the differences are irrelevant (and they are effectively identical), or it is different enough to stand on its own merits and therefore warrants discrete recognition. Further, since all "works" are influenced in some way by the "works" that have preceded them, surely all "works" are derivative ?

But that doesn't matter...

[msauve]

if I'm not mistaken (derivative works). Doesn't the GPL allows you to make all the derivative works you want without restriction (i.e. with confidential/proprietary code, for your own use), just no distribution? I don't see how distributing a virgin source file, along with a separate patch file (which is logically just info on how to link the code, not the linking itself, which can only occur in a binary), constitutes a "derivative work."

Re:But that doesn't matter...

[Sancho]

Maybe. Like I said, I'm not a lawyer. The FSF seems to think that binary blobs (e.g. the NVidia driver) violate the GPL, even though they work under a very similar premise to what you are suggesting.

Re:But that doesn't matter...

[randomjohndoe]

That is correct. That's what makes it "open source". You can view and modify the code to your hearts content. If you don't distribute it you don't have to share your changes.

If you add code that violates someone else's copyright, for example you violate the terms of the CDDL, that's between you and the copyright holder. It has nothing to do with Linux or the GPL as long as you are not distributing the code.

So there's nothing to stop someone from releasing source code for a patch that will allow people to recompile their kernels with ZFS support unless that would be a violation of the CDDL. And as long as you're not distributing, you can add that non-GPL code to your kernel.

Also, "distribution" means public distribution, so your GPL non-compliant kernel can be distributed for internal use within your company if it has a desire to run Linux on ZFS.

This is why.

[Ayanami Rei]

Sun knows that it is impossible to switch Linux to another license. Even if a majority of people in the contributors list all said tomorrow "Let's use license X" (nearly impossible) there are still missing and _dead_ contributors who effectively lock it into a 70 year GPL configuration (at which point it goes public domain and could be re-licensed).

Sun just recently got a chance to sit down with their lawyers decide how they wanted to license OpenSolaris (Nevada, Solaris 11, whatever), as a whole.

Their lawyers modeled the CDDL on the Mozilla Developer License. They wanted to get the code out there without losing sole control, and to be able to option/exert patent influence on people who got access to the technology.

But unlike AOL/Mozilla, they did not dual license it under the GPL. This probably because they knew that Linux could not incorporate OpenSolaris code at all without violating the GPL and CDDL clauses. This preventing Linux from becoming more competetive with Solaris by means of appropriation (they don't want to hurt their own technology advantage and cannabolize sales of licensed/supported Solaris).

But both camps could really use each other's code. It sounds like upper management at Sun is going to change the license for Solaris (as they have the authority to do so; this is impossible for the Linux community to do effectively) to allow this soon, on the heels of GPL'ing java (which has done wonders for its acceptance in the development community).

Project inertia will guarantee that Linux will be Linux, and Solaris will be Solaris. Sun doesn't have anything to fear. Perhaps they were testing the waters with the initial code release to see what the reaction would be.

Linus, more freedom, less hate

[kentsin]

Linux,

Please re-consider follow a more free license rather than a hate-oriented lincense.

Free the code, free the programmers.

Re:Linus, more freedom, less hate

[petrus4]

Wow...

I can just imagine what the response to this is going to be. At the very least, I'm surprised the parent hasn't been modded down to -1 already. Although I expect it will be.

Can't have anyone stating the truth, after all.

Re:Linus, more freedom, less hate

[Slashcrap]

Linux,

Please re-consider follow a more free license rather than a hate-oriented lincense.

Free the code, free the programmers. I just had a quick look at your posting history.

Incoherent ramblings on random subjects? Check.

Appears to speak English as a twelfth language? Check.

Has never replied to anyone else's post? Check.

You sir, are a bot. It's a real shame that your author didn't have sufficient coding or language skills to make you convincing. With a bit more effort, you could have been a contender. As it is, you blend into the background so much that you've barely been noticed at all. I guess your author had the same problem. I can only assume that he was such a non-entity that he failed it even as a troll and decided that a few lines of code would have more personality. I'm imagining a basement, probably somewhere in Eastern Europe, where the bloated, decaying corpse of a failed programmer swings from a rafter. The only illumination provided by a flickering CRT displaying the Slashdot "Comment Submitted" screen on a slow, endless loop.

Debian Solaris?

[Doc Ruby]

What would it take to run the OpenSolaris kernel instead of the Linux kernel in, say, a "Debian" OS? How much of the apps, including the rest of that "Debian Solaris", would have to be revised to use the OpenSolaris kernel? How much revision (to the apps or the Debian bundle) would be required to run OpenSolaris apps on that Debian Solaris?

Re:Debian Solaris?

[opk]

What you suggest exists: Nexenta - http://www.gnusolaris.org/gswiki

Re:Debian Solaris?

[Doc Ruby]

Do you know what it would take to convert Nexenta to a "Trusted Solaris" with the GNU environment?

Re:Debian Solaris?

[swordgeek]

Short answer, probably not possible.

Trusted Solaris is heavily based on the Sun toolset and RBAC (role based access control) in particular. By stripping these bits out and replacing them with GNU packages, you've eliminated the possibility of Trusted Solaris.

TS is a _very_ different beast. Superuser privileges haven't just been removed from /etc/passwd, but actually taken out of the code. There is no 'uid_0 = God' principle. Also, TS is based on the Solaris 8 kernel and OS, so the idea of making any Solaris 10 kernel base trusted before Sun gets there is moot.

Finally, consider the premise of Trusted Solaris: A very specific and fixed environment which has an EAL4 CC certification. Any changes to that, and the 'trusted' part (and the certification) become invalid.

So in short, the answer is no.

Re:Debian Solaris?

[Doc Ruby]

Ah, but Sun promised they were factoring out the "Trusted" functionality of TS into a module with which OpenSolaris could be deployed.

A tall order, given how different TS and vanilla Solaris have been, but that's what Sun promised, over a year ago (delivery date in 2006Q4). Do you know if they delivered that? And how it could be used in a Debian Solaris, even if the TS components have to displace (or otherwise exclude) some GNU components? Which would require replacement with some GNU API and Trusted glue to allow apps dependent on the deprecated GNU components to work.

Re:Debian Solaris?

[swordgeek]

That's true, and in a sense they have.

Solaris 10 03/05 has been certified at EAL4+, for specific configurations. There are a lot of limitations and exceptions to how it can declared secure in those configurations. (For instance, DHCP may be installed, but the functionality of it isn't included in the CC certification, so a certified S10 system with DHCP installed doesn't address the security risks of DHCP itself.)

The question, I guess, is what you're actually trying to accomplish. If it's a system running something called Trusted Solaris, then you buy the (Solaris8-based) software from Sun and install it according to their instructions on specific hardware. If it's Solaris with a CC certification, then you can get S10 03/05 and install it according to the certification notes. If it's a heavily secure Solaris, you can throw JASS at a current version of S10, and then customise it afterwards. (i.e. remove accounts with UID=0, set up heavy auditing, etc.) If it's a Solaris kernel with GNU tools that either (a) is heavily secure, or (b) is CC certified, then you're on your own. The former hasn't been done yet, and the latter isn't likely to be done, at least in the near future.

Re:Debian Solaris?

[Doc Ruby]

Moderation -1
    100% Redundant

TrollMods imagine they thought of Trusted GNU/Solaris, and posted it, first.

Yup, that's the point of FUSE

[EmbeddedJanitor]

FUSE is pretty cool as a file system extender and development system because it allows development of file systems in user space. FUSE-based file systems can use all sorts of calls that the kernel cannot and can be debugged with regular gdb (unlike the kernel).

I think though that the original comment was not concerned with this but with the legal issues of kernel vs application space. The Linux license states that it is OK to run closed apps with Linux. As such, the Linux license is distinct from the standard GPL which makes no mention. Thus, you really have to say that the Linux license is no longer GPL, but is GPL-based.

However this can get rather silly. If you muddy the distinction between apps and OS because it is all code, then why stop there? Why not include data too? After all, different data causes different code execution. Data like spread sheets are stuffed with macros etc which are really just code.

Noooooo!!!!

[r00t]

Linux is becoming a microkernel. Linus might even get a passing grade.

Old news

[Anonymous Coward]

This is already on System Rescue CD 0.3.6, please see http://www.sysresccd.org/Detailed-packages-list

Linux is under the standard GPL v2

[file-exists-p]

So to summarize what you wrote, L. Torvald "wrote specific terms into the modified GPL v2", and these terms are that Linux is under the non-modified GPL v2 and not under a yet unwritten, hence unknown license ? Ain't you making a confusion between the license and the statement about under what license the code is ?

Linux is GPL and will stay GPL

[theologu]

Folks, don`t fool yourself, Linux is GPL and will stay GPL(v2). Linus is very clear on this, and the man has good reasons, if linux was BSD, it never be what it is today. BSD is everyone for himself and encourages branches not merging. GPL(v2) is the guardian of pure linux evolution. Binary modules should however find their place on linux, but there are drawbacks which are normal

ZFS is also being cloned

[Anonymous Coward]

btrfs looks like a clone, at least functionally, of ZFS (and NetApp WAFL for that matter). It is still pre alpha but it has the snapshots, checksums etc, but not the RAID functionality yet. Though that is planned. Comes from Oracle who did a cluster file system before, BTW.

FUSE on ZFS is for compatibility

[nanosquid]

The FUSE implementations are for compatibility--when someone hands you a ZFS or NTFS formatted disk and you have to be able to read it. FUSE is also useful for remote file systems, where the extra overhead doesn't matter.

For your primary local disk file system, you really need a kernel-based implementation.

Well, the main thing I regret about the ZFS/Linux license incompatibility is that we don't get a chance to see ZFS fall flat on its face like all the other supposedly terribly advanced file systems. But that's a minor regret. In the end, we all know that the next file system for Linux will be ext4, and that's a good thing as far as I'm concerned.

Why you were marked as redundant and troll

[OrangeTide]

flippant \flip"pant\, a.
    Speaking fluently and confidently, without knowledge or consideration; empty; trifling; inconsiderate; pert; petulant. [1913 Webster]

Re:Why you were marked as redundant and troll

[Anonymous Coward]

It wasn't flippant at all. The OP asked if Linus owned the copyright to *all* of the Linux kernel, clearly understanding that there were multiple parties involved and that the two possibilities were that Linux is assigned copyright of all check-ins, like with the GNU project, or that he didn't in which case the copyright was distributed.

Given that it was clear the OP understood the two possibilities, what need was there for more than a simple answer? No, he doesn't own all the copyright.

Try UnionFS?

[Flimzy]

What if you layer an ext3 filesystem on top of an NFS filesystem using UnionFS? UnionFS 2.0 just came out, which supposedly takes care of the problem of "what if I modify the underlying filesystem?" It might work... Then again, it might not, too :)

bullshit

[Anonymous Coward]

> It wasn't chosen to be incompatible with the GPL

Bullshit! There is video of sun folk stating exactly this. At a Debian meeting or something IIRC.

I find it interesting that ZFS on Linux is news

[linimon]

but ZFS on FreeBSD isn't. (It was imported to the FreeBSD kernel on Fri Apr 6 2007 by pjd).

We are currently working on tuning and memory usage issues so that it will be as solid as possible for the 7.0 release this fall. It is already being used by some users, who are reporting good results.

It wasn't even mentioned in the Slashdot "bsd" section. Someone will have to tell me why.

mcl

How the GPL hassles me

[Solra Bizna]

How so?

Here's how.

I'm developing (under contract) an open source, ultra-modular game engine. I originally intended to release it under the GPL, but upon closer examination of the license determined that it would then be impossible to make a game or other addon package licensed under anything but the GPL.

So now, rather than use a less restrictive license directly, I will have to release under a customized GPL (similar to the LGPL) which allows for linking with "proprietary" packages and set up a very elaborate and clumsy subsystem to prevent GPL and "proprietary" packages from being loaded at the same time, in stark contrast to the elegance of the rest of the code.

cue FSF zealots telling me that I am morally wrong for supporting proprietary software in this way

On top of that, I had to sell the idea of not using the vanilla GPL to my boss, who was freaking out about how that would keep it out of Debian forever.

If you want the benefits and bootstrapping of someone else's free code, play by the GPL's rules. Otherwise, write it yourself.

What if I'm writing code and I want others to benefit and bootstrap from my code without the GPL's restrictions on what they can do? By using a less restrictive license, I forbid them from releasing their own code under the GPL. The LGPL doesn't always cut it for this case, either.

-:sigma.SB