License to thrill: Ahead of v13.0, the FreeBSD team talks about Linux and the completed toolchain project that changes everything It's not as well known as Linux, but FreeBSD has plenty of hardcore fans. In a wide-ranging chat covering licensing, architectures including RISC-V, and a development model that's free of a "dictator", The Reg spoke to members of the project about new release features and more. FreeBSD 13.0 has just reached release candidate 1 …
Whether it's a single person, a Board, a Council or however else you want to call it, some entity has to be calling the shots.
You want to take a dig at Torvalds ? He can take it.
But, functionally, your method is no different. A decision is made from On High, and it is enforced in the community.
I'm glad you found a method that suits you, but don't go feeling all smug about it. Nominet used to be managed by its community, now look where it's at.
Nope, origninally started as bits of software developed for the original unix, it became at one point bigger than the original and was able to replace it, though this took a long battle in court with the lawyers from AT&T, who weren't interested in the system just how much they thought they could milk it for.
This blog describes the FreeBSD governance model. tl;dr a group of 9 committers is democratically-elected to 2-year terms on the Core Team. This team "constitutes the project’s “Board of Directors”, responsible for deciding the project’s overall goals and direction as well as managing specific areas of the FreeBSD project landscape." https://freebsdfoundation.org/blog/freebsd-core-team-10-in-review/
People have been working on BSD longer than Linux has been around. They've seen different approaches, including the cult of the core developer, and have been enormously successful with their own. It's not a committee, and it has rarely been unable to take decisions. There have been disagreements and these have generally led to forks like OpenBSD and later Dragonfly. Interestingly, userland is the same on nearly all the forks; something that Linux definitely could learn from, as long as userland isn't just what RedHat wants it to be.
I've written elsewhere about choosing FreeBSD for my Internet facing servers, but I still use some pre-made Linux (or Linux adjacent) products (e.g. Android, Raspbian, etc), where the hardware support is well aligned and the distro install is pretty much an image. Also a few pre-built VMs for running particular service platforms.
I'd tried RedHat (4.2, ISTR) before BSD so it's not a case of who got there first; FreeBSD was a compelling choice for my use case at the time. I haven't subsequently adopted Linux more widely for two main reasons; distro fragmentation, and systemd; don't have the time to invest in the nuts and bolts of a particular distro only to get hosed later. I did use CentOS for a while as my goto Linux, but recent events there just go to show what can happen. If there had been no BSDs, I'd have just sucked it up and probably gone Slackware at the time.
it's more of a consensus among similarly-thinking people, actually... from directly dealing with them. I've contributed a couple of things, in the kernel and in userland, jumped through the hoops and complied with their standards to get things approved, and so on. it works. Not as bureaucratic as it could be, but generally everyone just wants quality and maintainable code.
A good point about LLVM being better for research. GCC is deliberately non-modular, as Stallman wanted to discourage the creation of components like new optimisers that could easily be ported to other complier suites. The idea was to get GCC into a position where it was the primary target for development and tightly couple any new components to it. So politics trumped good design and implementation in GCC. LLVM is very modular and makes it much easier to develop and test various new components for it.
I liked this look at the current state of FreeBSD.
At one time I used an earlier version (around 4.x in 2004) in a project at work. Was pleased by its sane resource use, and the way it booted up almost instantly. Occasionally looked at it since, but getting a usable desktop with it is still more work than with Linux distributions (especially if your keyboard and character set is not bare ASCII). The article says they still care about desktops, good, but it clearly is not the focus, and it shows.
Probably I will give v13 a try.
I was testing it periodically a while back, and giving feedback to the devs. They were beginning to focus on gnome 3 though and I was more interested in seeing gnome 2 continue and become uber-stable, which it came close to doing, and then move forward with mate, so I kinda lost interest over the whole gnome 3 path.
But the good news is that GhostBSDs live CD/DVD setup method works pretty well, last I tried it.
"A lot of people consume FreeBSD as a toolkit to build things, like appliances. For many of those vendors, the BSD license is very important compared to the GPL license, particularly GPLv3."
That's right, corporations "consume" BSD and crap out their own proprietary software without giving anything back. Good for Sony, Nintendo, countless others but not so much for the end-users. Utterly unsurprising that dev time is spent on Linux emulation for binaries so that the poor users can actually have a range of software to run. This is why, as the article states in the opening sentence, "It's not as well known as Linux" and I believe it will continue to be irrelevant.
I am a small startup and I have greatly benefited from BSD licensed code (especially networking libraries). Can you point specifically where in the article I should be reading to the contrary?
The GPL is great, however unless the AGPL is seriously used, companies are just going to make things "services" anyway so in some ways, the GPL is actually damaging the concept of self-sustaining open platforms.
And there was no _need_ for Apple to give you Clang at all.
There's several reasons why GPLv3 and GPLv2 added together amounted to only 20% of open source development during 2020, but one of them is definitely avoiding the religious zealots and their narrow-minded black and white worldview.
GCC is the epitome, as per the article. Poorly architected, in a conscious attempt to lock people in.
BSD is very much the original form of open source: no restrictions means no legal headaches. And the idea that a company can FreeBSD, add very little to it and have some kind of wonder software that they can charge gazillions for was debunked years ago.
Companies that use FreeBSD almost always have engineers who contribute actively to its development. Whether this is in the form of code, bug reports or whatever doesn't matter. Not having to ask for permission to use it means not having to get the lawyers involved and that often means that something will get done that otherwise wouldn't.
"The foundation is a US-registered charity funded by donations and has a budget of a little over $1m per year. We receive donations from individuals, and from companies that use FreeBSD.""
Although it doesn't say so exactly, I am guessing that helps to pay the bills, including reliable family health insurance which is A HUGE FACTOR in the US, - i.e., they are not working for free. And also being ones "own boss" is huge bonus too.
I've never understood why the BSD people are so proud of working for rich people for free. No one loves a martyr quite as much as they love themselves, I guess.
So, lets talk about Linux masochistic fanatics flaying themselves with btrfs instead of just accepting that zfs is the better bet and knuckling down to use it. Linux is riddled with rewrites of other peoples' free software because the Linux outfit doesn't like it when free gifts come with the wrong wrapping paper. Dtrace is another example...
No one likes a self righteous masochist who says that everyone else should be exactly like them...
As stated in the article, some corporations using FreeBSD do give back in the form of development.
One not mentioned in the article is iXsystems who not only do that but give away TrueNAS Core (was FreeNAS) - a popular storage OS. This gives the same code that is used (with additions) on their heavyweight commercial systems much more exposure.
I have been a happy FreeBSD user for over twenty years, for a long time knitting my own firewalls and storage servers, but a while back I switched over to pfSense and FreeNAS / TrueNAS appliances. I now have just two FreeBSD systems - and they are Hyper V VMS.
There is of course also nas4free, ahem, sorry XigmaNAS that forked off when iXSystems trademarked FreeNAS. I stuck with nas4free for some reason or other (might have been easier upgrade route from older FreeNAS or something to do with the slightly different feature sets) but both are excellent NAS software.
Good for Sony, Nintendo, countless others but not so much for the end-users.
How is it not good for end users? You think Sony, et. al should write their own OS, network drivers/stack, filesystem drivers/stack...etc etc... why? It'd cost them more, putting up prices (bad for end users) and surely running well tested and mature code is a benefit for end users?
Utterly unsurprising that dev time is spent on Linux emulation for binaries so that the poor users can actually have a range of software to run.
For binaries..... <whisper> the ones without source code. </whisper> ;)
This is why, as the article states in the opening sentence, "It's not as well known as Linux"
It isn't. That's due to a court case in the 90s and momentum.
and I believe it will continue to be irrelevant.
Fair enough. It's an OS at the end of the day, it's not that important in the grand scheme of things.
With respect to GPL...
If you are shipping an embedded system, sometimes it carries an EXTRA COST to make it possible for end-users to modify and load the modified version of the software (in this case the OS and userland applications) as required by GPL. Even though FreeBSD is _ALREADY_ open source, and you haven't really modified nor customized anything, shipping a binary-only end product can be a LOT simpler and less of a hassle than having to deal with boot loaders, un-bricking, and build environments.
That being said, if most of that is done FOR you [such as using an RPi and Raspbian/Raspberry OS] then you don't have to concern yourself too much with that OTHER than being forced to update to a moving target to fix problems. Having something shipped as a binary makes certain aspects of updates easier and possibly MORE RELIABLE, as long as you take responsibilty for it.
It's really a matter of cost benefit. FreeBSD on an appliance can greatly improve that. Good examples are router/firewalls, and NAS devices (based on FreeNAS, which I understand is a derivative of FreeBSD). You don't have to deal with a ZFS licensing as you would under Linux, and driver BLOB libraries that would create other licensing issues with Linux, etc.. Even a closed source proprietary driver is possible to ship with the OS, if intellectual property or government regulations demand it. Linux is NOT perfect at dealing with these real-world problems, particularly with its DEMAND for GPL compliance and "non-tainted" kernels.
Additionally, with FreeBSD, there is _NO_ _SYSTEMD_ - and also no /sys nor /proc by default (/proc can be mounted, not sure about /sys, but it's a bit different than Linux). So when POSIX applications are written that ASSUME LINUX (aka 'Linux-isms') they have to be ported to run on FreeBSD to compensate for the poor assumptions made by the authors.
And then, of course, there are FreeBSD-only features like jails and the built-in [text only unfortunately] hypervisor bhyve, plus Linux userland binary compatbility [32-bit AND 64-bit Linux on 64-bit FreeBSD] and a few other things not mentioned in the article. Jails are superior to merely using chroot since you get a DIFFERENT security context (i.e. different root password, or any other user/password for that matter) and you can limit the /dev entries that show up in the jail [and there are a few other things that can't be done from within a jail].
Anyway, probably enough for one post.
I have no doubts about the quality of the work, but I'm never going to contribute to anything with the BSD license because I see Apple using it every day to rip off programmers, customers, and society at large.
Also: systemd is not required for Linux and my main machine at home does not use it.
Sorry, Bob, but I'll have to pour some cold water on your argument.
So, you're trying to convince us that beyond shipping software in binary form, offering a link to download the source code you've just compiled and allowing user the same level freedom you benefited when using the FOSS code adds to the cost ? How about adding license compliance and forced activation mechanisms, SecureBoot and DRM extensions all for the end-user experience of course, are they all at no extra cost ?
By the way, nobody is forcing FreeBSD to add Linux compatibility into their OS.
One thing we both seem to agree is that making money out of software you don't have to pay for is a major cost benefit.
I have to admit there's a point there. Not that it is anyone else's problem, but there are times where allowing a user access to something may make it harder to produce a good product. Here's an example. I was looking at a product (made by others, I don't get any blame or credit for this just so you know) which used a proprietary library to interpret images. I know of an open source library that is useful for the same purpose and, in fact, has a few features theirs didn't have. What would be really nice is to include both libraries so the users can use features from each. However, the open-source library is GPL3, so if they used it, they would have to make it possible to replace that library without breaking the system.
If they did that, I as a user wouldn't object. The provider of that proprietary library, however, probably would as they extracted license fees from the manufacturer. Allowing user-provided code access to the system means the users would have access to the binary of the proprietary code and may also have been able to extract the license information. So the company didn't include the open source library. Before you ask, the open source library, while having some nice features, didn't have some of the core ones so a device using only that would not have been fit for purpose.
This is not a problem anyone else has to care about, but there are reasons companies might avoid GPL3 other than "I want to extract money and give nothing back". They may have to where open source lacks the features of proprietary and their users value a good product over access to the code.
However, the open-source library is GPL3, so if they used it, they would have to make it possible to replace that library without breaking the system
Rubbish, utter tosh.
All the GPL does in this case is mean that as well as shipping with the binary installed, you have to provide on request the source code to it - but only to people you shipped the binary to. You are under no obligation to allow the user access to the other bits of the system, or to any bit of the system. You are under no obligation to allow them to replace that binary without breaking the system.
Your only obligation is, if asked by someone you've shipped the binary to, to provide the source that can be used to build that binary. You don't have to provide source to anything else (assuming you are simply calling the library in the normal manner rather than embedding it's code in your own code). You don't have to help them if they want to do anything with it. You don't even need to do anything if replacing that binary somehow makes the system stop working - but under GPLv3 there are restrictions on actively stopping things working, (the Tivo clause). So if you use code signing, then under GPLv3 you would need to allow another binary to run - either by providing a signing key or supporting other keys - but just "replacing X with Y breaks the system" does not mean you breach the GPLv3.
I'm not following your disagreement. If you use a GPL3 library somewhere, they have to be able to replace it somehow. If you make the system such that, if they put a file in that is not identical, it breaks, then you have not complied with that requirement. Therefore, you must accept a version of the library which does not break the system. If they supply a modified version which crashes itself, that's not your problem, but if the one they provide runs, then you must accept it.
Which means that the library could be replaced by one giving the user effective access to the system with the privileges of the original library. This is one reason I'm all in favor of people using GPL3 libraries, because I can write a replacement and use it to gain relatively unrestricted access to the underlying system. I like doing that. I got a library to open a network port and run a telnet server to a root shell, for example. The manufacturer I described above is not as keen on my doing that for reasons I've explained.
Now theoretically, the manufacturer could take steps to prevent a replaced library doing anything by isolating it in an environment without privileges. So if a company really wanted to, they could do that. However, that takes a lot of work and slows down the program as it sends data in and out of a sandbox for the GPL3 stuff. That's why few companies ever do it. They either just don't use the GPL3 libraries at all or they use them without giving access and thumb their nose at those of us who know they're violating the license.
If you use a GPL3 library somewhere, they have to be able to replace it somehow
Err, where does it say that ?
Yes, if they replace it then you can't make the system break because they replaced it - but you don't have to engineer the system such that they can actually replace it. You can build a unit with the board embedded in epoxy and no diagnostics/ICP port - but as long as you provide the source code on request and don't do something like apply code signing, then you are not breaching GPL.
Which means that the library could be replaced by one giving the user effective access to the system with the privileges of the original library
Now thats' a different argument which was not obvious (to me) from your previous posting.
But of course, no-one is forcing anyone to use GPL code. If you don't like the terms for using (for free) someone else's work, then you are free to do it some other way. Similarly, no-one if forced to release their work under GPL - they can use whatever licence (or not release it at all) for their own work.
And of course, you've given one very good reason that some people do like GPL code. The manufacturer of the equipment obviously took a decision that using the GPL library saved them enough cost/effort to justify the downsides for them. They were absolutely not in any way forced to use that library - it was a choice (presumably commercial) to accept the downsides in return for getting to use someone else's work for nothing.
As I've said in previous comments, this is not a reason we have to care about. I'm merely illustrating that there can be a reason for a company to avoid GPLed code that is not purely profit-seeking anti-user stuff. This is not my problem, nor should it be yours. Companies can make whatever decisions they want to just as we who write the source can. I just think it's worth it to keep in mind the actual results of a license decision like this one so that decisions can be made with real-world effects in mind.
I said: "If you use a GPL3 library somewhere, they have to be able to replace it somehow"
You said: "Err, where does it say that ?"
From section 6 of the GPL version 3:
"If you convey an object code work under this section in, or with, or specifically for use in, a User Product [...] the Corresponding Source conveyed under this section must be accompanied by the Installation Information."
And above that is the definition of that:
"'Installation Information' for a User Product means any methods, procedures, authorization keys, or other information required to install and execute modified versions of a covered work in that User Product from a modified version of its Corresponding Source. The information must suffice to ensure that the continued functioning of the modified object code is in no case prevented or interfered with solely because modification has been made."
Which means that, if the software can be modified, the user must have the ability to modify it. Which, except for a few rare cases, is all products. There is an exception for a product where it's impossible, like ROM, but pretty much every product uses software which theoretically can be updated and in that case, they have to make it possible for a user to update it themselves. Again, I like this because I quite enjoy hacking my stuff, but companies have reasons not to want to give that access out other than wanting to lock out the users.
the extra cost of a "GPL compliance web page" has little to do with my point.
The extra cost is typically in hardware. You sometimes have to add extra things to hardware to enable GPL compliance with respect to boot loaders [mentioned] and the OS itself [mentioned].
If you design a piece of hardware with, let's say, an ARM processor from a well known vendor [read: Microchip] you may not want to include additional JTAG hardware on the circuit board that is needed for end-users to program it. You may ALSO not want to expose a serial port that would make it possible to recover an attempt to re-build and re-install the OS, that fails [or to boot into single-user mode from a console so you can complete an installation of a kernel and userland]. Sure, your internal test systems would have these capabilities, but NOT the ones shipping out the door. "Extra cost".
You would have to consider the amount of engineering effort that goes into lowering the BOM cost by just a nickel... and it's JUSTIFIABLE when shipping "that many units".
From a pure software consideration you can make your claim, sure, and maybe even be smug about it. When you consider "the big picture", not so much.
I have done designs using Atmel CPUs that deliberately avoid GPL so that you don't have to support programming them by end-users. And I've done GPL versions as well, and had to cleverly jump through hoops to make it possible to program a necessarily GPL bootloader without access to a PDI header [it was potted in epoxy and operated under water]. So yeah, I have a pretty good perspective on what it might take from the hardware design as well as the software. There's a cost.
"FreeBSD on an appliance can greatly improve that. Good examples are router/firewalls, and NAS devices (based on FreeNAS, which I understand is a derivative of FreeBSD). You don't have to deal with a ZFS licensing as you would under Linux, and driver BLOB libraries that would create other licensing issues with Linux, etc.. Even a closed source proprietary driver is possible to ship with the OS, if intellectual property or government regulations demand it. Linux is NOT perfect at dealing with these real-world problems, particularly with its DEMAND for GPL compliance and "non-tainted" kernels."
And on top of that, you still have plenty of companies shipping Linux-based appliances, along with proprietary software without disclosing any sources for them !
So, the GPL bigotery is just pointless in terms of benefits vs. issues.
This post has been deleted by its author
*Raises hand*
I've been using FreeBSD for my Internet facing servers (e.g. mail/Web) since 2005 for its fantastic stability, uptimes and security. Looking forward to the improving support for the latest RPis in the next release so I can retire the Intel Atom nettops from 2008.
> UFS was dog slow the last time I tried it –
With or without "softdeps"? This is a mount option that makes disk updates more intelligent, but at least in old BSD systems it was not on by default, and the difference was very noticeable. UFS really was "dog slow" without softdeps. I don't know if it is enabled by default these days - should be.
No issues here; I switched off access time updates (noatime) in the mount options to reduce write wear, but haven't had any issues with SD cards; setup is such that the internal SSD was effectively read-only, and all /var partitions for logging, spool etc, are on a replaceable SD card. But aside from one upgrade to increase the size, haven't needed to change it.
Soft-updates is switched on for the actively written partitions. It probably wasn't a default due to the power-off FS corruption risk. However, these units have survived a couple of UPS failures with no unfsckable damage.
What's the package management story like these days? I know there's a binary package manager, pkg, but the last time I looked there were hardly any packages available: ports were recommended instead (which I generally found a pretty miserable way to install software).
I've been using Debian for so long that I rely heavily on the Debian package repositories, and find other distributions just too much work to use. Having nearly every piece of Linux software a few keypresses away is great. A while back I got really excited by Debian/kFreeBSD, which provided a Debian userland on top of the FreeBSD kernel, but the project eventually collapsed.
David - the pkg system is very good right now. Everything that is in ports is available with a simple "pkg install" command. The only issue I would say is finding the packages available, but freshports is a great help for that. There are a few programs you may want to install from ports instead of packages based on the options, but unless you need something other than the defaults, you can get by pretty much without ever downloading the ports tree.
As Jardows writes, it's pretty good; admittedly, I only run a BSD desktop install in a VM for server dev purposes, so the actual port set of interest is quite small for me. However, I'll probably be looking to shift more to the BSD desktop as my Mac desktop/laptop hardware ages out and I've reached the end of possible OS upgrades with Mojave.
Wi-Fi's never been a big part of my desktop experience since it's too slow (and crowded) around here, so the driver support issues there haven't been an issue. Even then, virtualisation has taken care of some of that anyway.
Packages for release/architecture have been great for a good few years. I used to get confused because the installer would offer only the stuff from the release and it took a while for BSD to settle on a package management system but pkg has been solid.
But, of course, just dropping into the relevant ports directory and running make && make install will still always work.
You can now run a Linux diatribution in a FreeBSD jail - using the linux emulation, so like Debian/KFreeBSD it's a linux distro running using the FreeBSD kernel, but unlike Debian/KFreeBSD the userland binaries are native linux.
The amount of shared code between macOS and BSD is often greatly exaggerated. It's mainly chunks of userland, and probably originally the network stack, that have a background in BSD.
As someone who uses exclusively macOS on the desktop and almost exclusively FreeBSD on the server I wish there was more shared codebase. If FreeBSD could easily repurpose drivers for macOS for instance then that would help many of the BSD-on-the-desktop initiatives. Alas, the hardware layer of macOS doesn't look anything like that of BSD. It's also considerably easier to run Linux applications on FreeBSD than macOS applications.
Considering the driver system of FreeBSD is wildly different from that of macOS (you might as well ask Microsoft to work on FreeBSD drivers) I don't think Apple could be of much help there.
They have effectively given the wider *nix community the continued use of the printer system CUPS, though. When Michael Sweet, the maintainer of CUPS, wanted to close the project (as he couldn't find the spare time to work on it anymore) Apple put him on their payroll so he could turn maintaining CUPS into a well paid day-job for the next 12 years.
Apple have also donated to the world the iCal standard everyone now uses to store and share calender data, the MPEG4 container format standard, large chunks of Clang/LLVM and most recently Swift (the language).
Granted, it pales in comparison to what Red Hat or Canonical have given.
IIRC, the MSFT network stack (once there even was such a thing, not just Clarkson packet drivers and a bunch of TSRs) also had "a background in BSD"
I am a little surprised that FreeBSD can easily port Linux drivers to their kernel. back when I was maintaining a few drivers (10+ years ago), it seemed like the kernel cabal delighted in "stirring the ant-hill" with frequent API changes.
Much like how the structure of gcc (mentioned in before) was a real PITA for anybody trying to re-target to a new processor. Or, of course, to anyone wanting to do a front-end for a new language.
Yes, the BSD network stack used to be the gold standard of TCP/IP network stacks. It probably still is. It was also the first major network stack to become fully dual stack IPv4+IPv6 back in the day (15 years ago?). That means that it made a lot of sense for OS developers to just use the BSD stack instead of reinventing the wheel.
If I recall correctly you could see in the acknowledgements for Windows that they used BSD code.
To the day you can see that networking (thanks to this network stack) and storage (thanks to in-kernel ZFS support) are the strong points of FreeBSD and why you see it being used in areas where one or both is extremely important. Hence Netflix using FreeBSD for their content distribution network or so many storage companies building their products around FreeBSD.
The two things I'm really looking forward to in FreeBSD 13 are:
1) the considerably increased performance, largely due to better support for some of the newer CPU shenanigans, improvements to TCP handling and probably partially because they could drop some legacy stuff now they've made i686 the default CPU type instead of i486.
2) replacing the existing ZFS implementation with the new OpenZFS 2.0. Apart from a technical feat (the most comprehensive ZFS implementation ever) it's also a human feat.
Where open source projects tend to split up and fork like no man's business, OpenZFS 2.0 is a rare example of different Open Source communities actually coming together. Practically every voluntary and commercial group that has ever done anything with ZFS (except Oracle but they are rumoured to have stopped their work on ZFS altogether) has come together to work on one codebase. So many ZFS features that have been donated by commercial storage vendors that are now available for free to Joe Bloggs thanks to this. Soon we'll have dRAID (distributed spare) to play with too. You're basically getting features usually only found in >50K storage devices to use on your 4-bay drive at home.
I think you're confusing ZFS (a file system) with OpenZFS (an implementation of the ZFS file system).
Until last year there were probably five or six different implementations of ZFS. Most notably probably a closed shop developed Oracle implementation, the Illumos implementation (maintained by former SUN engineers), the FreeBSD implementation (largely based on the Illumos implementation but with many tweaks by storage corporates), and the ZFS-on-Linux implementation (maintained by Linux enthusiasts with some corporate support). All with varying degrees of compatibility. You couldn't just take out a ZFS formatted drive from an Ubuntu server and fully use it on macOS for instance.
Rumour has it that Oracle lost interest in ZFS (they probably couldn't make enough money out of it) and has closed the entire department that was working on it. All the other implementations joined forces and donated their code to the OpenZFS project. That resulted in OpenZFS 2.0 which contains code from Illumos, FreeBSD, ZFS on Linux, iXsystems, Nexanta, Delphix and quite a few others, from enthusiasts to scientific institutions and large corporates.
The result is OpenZFS 2.0 which has FreeBSD and Linux as its Tier 1 platforms (with macOS expected to join them in Tier 1 this year, Windows potentially later). So, yes, OpenZFS can be used on Linux and is used on Linux. Most commonly Ubuntu and Debian but OpenZFS 2.0.4 is compatible with 3.10 - 5.11 Linux kernels and with a bit of tinkering should be quite straightforward to use on most Linux distro's. Oh, and you can now read and write to your OpenZFS formatted drive you took out of a FreeBSD13 server on your Debian desktop.
I would argue that that is a level of cooperation we sadly don't see often enough in the open source world.
Canonical lawyers found that the CDDL was compatible with Linux licensing from an end-user perspective, provided the module is distributed separately from the kernel as a self-contained module. FreeBSD was always in the clear anyway, Illumos is CDDL itself and the macOS kernel (XNU) is licensed as open source software which permits even proprietary linking.
Therefore, we can say Oracle donated the code since the genie can’t be put back in the bottle now!
This is donating, it may have involved relicensing but that is a separate matter.
Let me give an example. When SUN open sourced their ZFS implementation in 2005 it was at that point the only ZFS implementation around. All other versions, the open source Illumos implementation, the closed source Oracle implementation, the macOS version that Apple briefly shipped on their install DVDs, the Nexenta implementation, the ZFS-on-Linux implementation etc. were all forked from the original code dating back to 2005 and therefore did not include support for TRIM. SSDs were not really a thing in the early 2000’s.
This meant that every implementation had to develop their own TRIM implementation (Illumos, Nexenta, perhaps Oracle too) or simply not support TRIM (ZFS-on-Linux).
Out of the various implementations of TRIM for ZFS, the one from Nexenta was by far the superior as it supported queueing. This means that the Queued TRIM command can be queued to run after all scheduled (arguably more important) read and write operations have been completed. Especially on high concurrent use storage systems that is a big deal.
Nexenta has donated their implementation to the OpenZFS project and queued TRIM is now part of OpenZFS 2.0. The code was probably previously closed source and has been relicensed under the open source CDDL license so it could be included in OpenZFS. It is referred to as a “donation” so I assume that the OpenZFS team did not have to pay Nexenta for their code. What I don’t know is if the copyright still rests with Nexenta or whether that has been transferred to OpenZFS too.
That is queued TRIM, just one example, but the development of Sequential Resilvering, dRAID, Zstd compression, Persistent L2ARC, Dataset Encryption, Fusion Pools and Allocation Classes has largely followed a similar path. Either developed straight under an open source CDDL license (so no relicensing required) or donated by companies and relicensed under the CDDL so it could be included in OpenZFS 2.0.
None of this has anything to do with Oracle, they didn’t own the copyright to the specific Nexenta, Delphix, Intel, Datto, iXsystems or Illumos code or were involved in setting the license for the code. The only copyright they bought eleven years was on the original SUN code. As that was forked fifteen years ago, before Oracle even considered buying SUN, the majority of the current code in OpenZFS is no longer based on the old code produced by SUN as development moves on. None of the features I mentioned above existed in 2005.
This is only related to the 32bit i386 architecture, and then only to the default shipped binaries (Building from source with i686 defined worked perfectly well)
Until v13, the binaries targetted the 486 instruction set. (A recent 12.X release switched to i686, but I think that was done in error) From v13 onwards, they target i686 (As someone on the lists has already mentioned, switching this back to i486 and compiling from source worked fine on his 486-based device)
I guess it's been targetting i486 for so long to maximize compatibility - if you were after peak performance, for a long time, you wouldn't have been running 32bit i386 hardware.. Or if forced to, you could have installed an i686 compiled version.
Things like the old navigation computers on the 757/767 were known to carry 386 based hardware donkeys after they went out of production. Choice of underlying op system - BSD by any chance?!
In embedded world, long lifetime is often much more important than shiny whizz bang, and with good reason.
My exposure to FreeBSD is pfSense. I had to buy about 6 miniPCI WiFi cards before I found one that actually worked. Kernel panics were frequent, and my final choice was still flakey. Now I've given up and used a WAP, only now will the box actually shut down properly. So, great and all, but still some work to do.
I used to be a GPL purist, which is funny because I actually started out as a UNIX (Ultrix) guy, more interested in UNIX engineering principles than political idealism.
Over the years, I found it harder and harder to consolidate these two increasingly opposing principles. Not that there's anything intrinsically about the GPL that compels such licensed software to violate UNIX principles, that's just the pit that Linux fell into, or more accurately was pushed into, mainly by Red Hat and the Poettering cabal.
Systemd pretty much single-handedly cured me of whatever little GPL idealism I had. When it comes down to a choice between "enforced freedom" or proper engineering principles, I know what's more important.
I'm afraid you're right. There comes a time when principles no longer suit us and we must get rid of them. I can see in your quest for proper engineering the same motivation that inspires the development of autonomous weapon platforms or the Chinese style state surveillance. The heck with freedoms, look how beautifully engineered our system is.
Where our opinions diverge is the necessity of freedom to be enforced. To me freedom must have well deifned boundaries and has to be enforced. It's the same kind of conundrum seen when asking if a democratic majority vote to suppress a minority can be valid.
"The heck with freedoms, look how beautifully engineered our system is."
Pretty much, yes.
I'm far more interested in the craftsmanship of a tool than what people may choose to use it for. Whereas I can exercise control over the design of the tool, I can have no reasonable expectation of control over the people who use it, much less how they choose to use it. Nor should I aspire to such control in principle.
Personally, I find the general question of "freedumb" to be more than just misguided, it's actually sinister. The people whining loudest about it tend to have the most sinister motives.
I don't see what proper engineering has to do with FOSS. Personally I find a lot of proper engineering in Microsoft solutions but I resent the fact that sometimes they tread on my end-user digital freedoms (you know the "I'm sorry, Dave. I'm afraid I can't do that." syndrom). Android is even worse.
Totally. Linux people used to bang on about MS software incompatibility, but became silent when talking about stuff hardwired to linux for. no real reason.
Breaking API's, deprecating broken subsystems rather than fix them, and instead introducing a new shiny-shiny.
Spaffing files and directories all over the place, and as you highlighted, systemd.
Linux being based on a unix lookalike is of no relevance these days.
The old phrase "Freebsd is for those that like Unix. Linux is for those that hate Microsoft" is still true today.
Not that I'm saying "the unix way" should be followed religiously if it impedes progress (there are those who say ZFS isn't "the unix way" because it combines a filesystem with volume management - 2 things the purists claim should be separate.)
But Linux distros often go there own way to the detriment - not advantage. *cough*systemd*cough*
I'm not sure about the marketing claims made in the article. Most that have bothered to learn Linux probably also know of BSD even if they don't use it. And BSD is even name dropped in Die Hard.
I am rather partial to the ideas in DragonflyBSD, though ultimately the driver and software support beyond stuff you can compile yourself is the main barrier to adoption, not at all unlike Linux. Adapting Linux binary blobs to permit running in BSD is a clever bodge. God forbid manufacturers release enough to public to permit writing native code though. I was hoping to get FreeBSD up on my G5 however it doesn't boot with more than 4GB ram installed, and the PSU packed up. The latter being a bit of a problem to solve.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
