Slashdot Mirror
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."
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?
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...
Grub has supported ZFS booting for a while (forget which branch though).
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?
Test your net with Netalyzr
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.
Lacking <sarcasm> tags,
No "co-opting" necessary. Solaris is every bit as much a terget platform for Gnome as Linux is.
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.
By "co-opted" I presume you mean, "Made major contributions to"?
Javascript + Nintendo DSi = DSiCade
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?
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.
If you can suffer the bizarre presentation style Sun have used for this video, it's quite informative about the benefits of ZFS.
Prosperity is only an instrument to be used, not a deity to be worshipped. Calvin Coolidge
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.
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.
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.
Caution: Contents under pressure
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.
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.
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?
I think you underestimate just how much I just dont care.
You know, I have one simple request. And that is to have sharks with frickin' laser beams attached to their heads!
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.
http://blogs.sun.com/darren/entry/zfs_under_gplv2
Probably? It's not like they tried to hide it, or necessarily did anything wrong.
ZFS On Linux - It's Alive!! IT IS ALIVE!!! MWUHAHAHAHAHAHAHA!!!!!
The manic laughter is especially important!
Only to idiots, are orders laws.
-- Henning von Tresckow
> 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'
"Why does he own the trademark Linux?"
Someone has to.
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.
Never trust a man wearing a coat and tie!
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.
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.
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?
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
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.
If something is so important that you feel the need to post it on the internet... It probably isn't that important.
Confuse them again at your own peril.
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.
Lurking at the bottom of the gravity well, getting old
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.
Method of processing duck feet
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.
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?
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.
http://www.dieblinkenlights.com
Funny and sad at the same time.
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.
Read the best of all of Slash: seenonslash.com
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
But does it run on Windows?
80 CC D8 AF AE D3 AB 54 B7 2E CE 67 C7
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.
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!
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.
I calls 'em as I sees 'em.
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
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.
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.
Jesus is coming -- look busy!
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:
What is it about ZFS that leads to it being a 128-bit filesystem?
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.
"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.
http://www.dieblinkenlights.com
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.
Jesus is coming -- look busy!
(massively decaying) UNIX ecosystem
0 070523.1.xml
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.2
You need a server to run samba. it needs decent CPU.
... your network then melts under doubled traffic for disk requests, probably :)
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.
I have no idea if it includes ZFS yet, but Debian GNU/kFreeBSD certainly includes apt.
Preventive War is like committing suicide for fear of death. - Otto Von Bismarck
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.
http://www.dieblinkenlights.com
Red Hat is working on it.
"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.
http://www.dieblinkenlights.com
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.
The horse is still alive lets poke it till it moves.
You mean "GNU/BSD" - after all, C source code doesn't run directly on the CPU
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! ... At least for the immediate future.
Anyone who can afford that much storage can afford to pay a little for a driver built however they like.
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?
"National Security is the chief cause of national insecurity." - Celine's First Law
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.
Leave the gun, take the cannoli -- Clemenza, The Godfather
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
WARN
THERE IS ANOTHER SYSTEM
Maybe it is time to rejig FUSE as a kernel module? *ducks*
Sure, why not? ZFS is - as far as we are today - the be all and end all of filesystems. Indeed - "supported by the Linux community"
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?
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.
Charles Wyble System Engineer
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.)
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.
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.
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
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.
I think there is a world market for maybe five personal web logs.
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.
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.
My God, it's Full of Source!
OUTSIDE_IP=$(dig +short my.ip @outsideip.net)
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.
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.
My God, it's Full of Source!
OUTSIDE_IP=$(dig +short my.ip @outsideip.net)
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.
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).
"National Security is the chief cause of national insecurity." - Celine's First Law
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.
My blog. Good stuff (when I remember to update it). Read it.
what "patch" is for? (i.e. distribute virgin source code, along with scripts and diffs which can fix/compile everything).
"National Security is the chief cause of national insecurity." - Celine's First Law
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."
"National Security is the chief cause of national insecurity." - Celine's First Law
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.
THIS THING CAN TURN ON A DIME, MACROSSZERO STYLE ALSO FUCK BETA, ~NYORON
Linux,
Please re-consider follow a more free license rather than a hate-oriented lincense.
Free the code, free the programmers.
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?
--
make install -not war
Just junk food for thought...
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.
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.
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.
Engineering is the art of compromise.
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.
Of course. ZFS on FUSE is stable enough for most Linux users.
But ZFS on FreeBSD is not for most _FreeBSD_ users.
Taking the "or later" clause out though means there is no choice to switch in the future.
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.
Linux is becoming a microkernel. Linus might even get a passing grade.
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.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.
This is already on System Rescue CD 0.3.6, please see http://www.sysresccd.org/Detailed-packages-list
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 ?
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
"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.
http://www.dieblinkenlights.com
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.
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.
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.
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.
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?
http://www.dieblinkenlights.com
Hah! Good point!
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!
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.
flippant \flip"pant\, a.
Speaking fluently and confidently, without knowledge or consideration; empty; trifling; inconsiderate; pert; petulant. [1913 Webster]
“Common sense is not so common.” — Voltaire
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 :)
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.)
/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).
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
Anyway, if you give it a try, I hope you enjoy the experience.
> 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.
Pretty difficult to do when you troll every GPL and Linux thread!
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.
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
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.
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
WARN
THERE IS ANOTHER SYSTEM