You are linking to 10-STABLE release notes, and 10.0-RELEASE is something else, than STABLE branch. STABLE's are a bit ahead of RELEASE's and are considered to be less stable than RELEASE's - the wording is a bit misleading.
In short what you get from STABLE branch is what version 10.1 will have.
Here is an explanation:
- RELEASE is actual release that is forked out (it will only contain security and other critical fixes) of the STABLE branch.
- STABLE is just a development branch (currently it is anything in version 10) as opposed to CURRENT which is a bleeding edge.
- CURRENT is what will be next version (version 11), once they finish adding features it will become next STABLE branch and CURRENT will be used for version 12.
While everything that ends up at STABLE needs to go through pointyhat build system, so it should always compile and pass regression testing, there's still a possibility of things breaking up.
Since 10.0 is about to be released STABLE contains what will become 10.1.
RELEASE is an artifact. STABLE is a development branch for the current non-experimental (stable) branch and from which releases are cut. It's still a development branch, though, so things can break on it.
Since 10-RELEASE was just cut it's probably close (identical?) to 10-STABLE, but that won't last long.
It is unfortunate that FreeBSD chose those names to attract people to the pre-release versions. What's needed is a section of the website clarifying:
CURRENT = alpha, dev
STABLE = beta, rc
RELEASE = passed all tests and released
That's not to say that things never break in releases. I've seen gjournalled disks (on a gmirror) require fsck (in 8 and 9 -REL) and carp fail (in 7 -REL). Other than those FreeBSD has been the most reliable, secure and up-to-date of any Unix or Linux distribution I've used. My only request would be a policy discouraging ports with perl build-deps, most of which seem to be one-liners that could easily use awk, sed and/or grep instead of forcing a perl build on every upgrade (most not even bothering to remove the build-deps when done).
> FreeBSD-STABLE is the development branch from which major releases are made. Changes go into this branch at a different pace, and with the general assumption that they have first gone into FreeBSD-CURRENT for testing. This is still a development branch, however, and this means that at any given time, the sources for FreeBSD-STABLE may or may not be suitable for any particular purpose. It is simply another engineering development track, not a resource for end-users.
The two common reasons are that they're resubmitting something that's already been submitted the reasonable way or they're letting everyone know before the official release notes have been published. That second one is a little risky sometimes, since it's not uncommon for the linked release directory to be filled with something that turns out not to be correct.
Yes, of course. It is Mr. Barber, Mr. Percival. I really didn’t want to annoy you guys and i would like to excuse myself if i did, but to me, obviously no one declares a release “production ready” to one’s own environment the day the ISO’s are availiable or the announcement is made. I'm just a FreeBSD User who felt the urge to share his enthusiasm about this with like-minded persons. So, no offence, Ladys and Gentlemen.
Cool, i hope we will hear from him more often and again, congratulations to you guys for another great release (when it will be released:) in the past twenty years.
The iso's are there, but there was no official release announcement yet, and because of that I would hold your horses for now - until the announcement has been sent out, those can be replaced in case of any issues.
If playstation 3 and 4 are a modified FreeBSD, and on the 4th version console the graphics are AMD that means they (sony and amd) have some sort of driver for this platform. And its not a bad one, because they chose AMD for play4.
Why that has not been release to the FreeBSD audience ? When is this expected to happen ?
The PS4 runs FreeBSD on AMD hardware, but that doesn't mean it's necessarily the same AMD hardware as you or I have access to. If you're buying 50,000,000 units, AMD will design a chip for you.
Not only that, but they allow quite low level access to the hardware. One would have to build, say, libGL on top of whatever drivers Sony might have built.
If you want to know why, the only way is to ask them.
This is BSD, so the authors want companies to be able to keep the modifications and drivers proprietary if they choose to do so. So in this case, its very much possible that the when is "never" and why is "money".
I hope they add exploit mitigation techniques like ASLR (already being worked on for 11) and close the gap to OpenBSD and Windows. Even DragonflyBSD has some level of ASLR. As Theo said adding is one thing but actually enabling it in the default configuration is what counts. ASLR is just one piece of the puzzle and for 11 they should seriously consider implementing enough to match OpenBSD.
A good source of information about using FreeBSD on the Raspberry Pi is the 'Embedded Computing' section of the FreeBSD forums. If you have any questions, that's probably the best place to ask them too:
As other told you this version is intended to be used on amd64 CPUs, which means the most popular 64 bit CPUs (both Intel and AMD).
The reason they don't provide ARM version of FreeBSD is because embedded systems are not the same and have different setup. Since Raspberry Pi is quite popular I can imagine that someone might build available to other for download but I wouldn't expect FreeBSD project do it (it probably would be someone else - I see link to images here https://wiki.freebsd.org/FreeBSD/arm/Raspberry%20Pi). If you have FreeBSD machine you can compile it yourself.
I'm going to guess not as it is marked as being compatible with amd64, you will need an ARM build (arm 6, I believe) for the Raspberry Pi. I'm sure a third party will eventually post a pre-compiled version somewhere fairly soon.
If you have a torrent client that supports web seeding, you can use these magnet links to download from the official HTTP/FTP servers and simultaneously help seed the torrent, in case the servers get overwhelmed:
My Transmission is stuck in "torrent metadata needed", so it fails to download the actual torrent file from the Magnet link. Do you have some directy links to the torrent files?
This may seem dumb, but, my RAID 1 NAS, powered by various versions of SuSE for 10 years, recently died (autopsy & self-reflection indicate gross user error). So I'm coincidentally shopping around for a new set-up.
I need NFS, transmission-daemon, and mdadm. I've used FreeBSD in a vm and on an old laptop, so I'm slightly familiar, but not like Linux (and I love being able to access SuSE's YAST over SSH)
Why would you pick FreeBSD over SuSE for a home NAS?
FreeNas was acquired by IX Systems and as of version 8 is no longer m0n0wall based. IX Systems is actually a great company but I don't like this change. If you need to build a NAS with ZFS try out Nas4Free to keep going with the M0n0wall based FreeNAS that we all loved.
Remove one of the disks from the mdadm RAID1, setup a zpool on that disk, setup the OS, copy the relevant data over, and then simply attach the 2nd drive to the zpool and zfs will automatically create a mirrored vdev for you.
If the existing filesystem can be read by FreeBSD (like ext), you can just copy the data over in a single system but in the worst case, you could just copy the data over from a 2nd system over the network. You'll probably want to do that using tar with archive options, so the only difference between doing it locally vs over the network is whether you pipe the tar create directly back to tar extract, or to a tcp utility like tcputils or netcat in between.
There's no in-place migration, so you either need to copy the data somewhere else, or as the sibling comment suggests, unmirror your drives and accept the risk of having your data only on one drive while you do the copy.
Others have mentioned ZFS. I'll add that my experience is that FreeBSD changes things less often and keeps things more compatible when it does (e.g. network configuration still uses ifconfig, freebsd hasn't adopted any experimental init system and is unlikely to until one becomes proven stable) and is thus lower-maintenance.
I might play around with this actually, but I think the biggest drawback when I last tried it was I became too impatient to wait for ports to compile the packages. Does it provide some way of doing pre-compiled binaries i.e. like apt?
Guys, I was unable to install it with X and GNOME on virtualbox. Can someone share the working virtualbox snapshot of FreeBSD 10 along with X and GNOME on it so that noob linux users like me can try.
I switched a personal server over to freebsd (8 or so at the time) a while ago after battling with zfs on linux. (I was hitting some strange issues at the time which I can't really even remember at present)
After getting over the initial learning curve (files being in different places than I expect / named different things etc) I have really come to like freebsd. You get the sense that everything has been designed to fit together a bit more than the linux distros. I had been using ubutnu before and I got really tired of how much constantly changed between releases. With bsd I'm able to get very up to date software via the ports tree, but the overall 'system' design doesn't seem to change as much between releases as it did in linux land.
The freebsd handbook is great and makes it super easy to get up and running. I certainly don't think the differences for everyday use between freebsd / debian for example are enormous, but I plan on using freebsd for most of my boxes from now on, its just been really painless to work with.
It's worth trying to grind through a few months of Free-BSD after using Linux to get a feel for it. One of my favorite quotes on the differences is, "FreeBSD is what you get when a bunch of old school Unix beard brigade hackers sit down to write a port to the PC. Linux is what you get when you take a bunch of hackers raised on Windows and PCs that try to port Unix to the PC". In a lot of ways that is two sides of the same coin, but really digging in to the BSD way of things opens up a new view point on Operating Systems . . . FreeBSD old school Unix assembly versus NASM, the Kqueue vs ePoll system implementations, FreeBSD's near instantaneous embrace for ZFS while the Linux community held back for "OS theological" concerns over the FileSystem implementation.
I've jumped between Debian and FreeBSD for my development boxes for a few years now. To butcher Dijkstra, "Operating Systems shape developers as much as violins shape violinists". When I find myself on FreeBSD I make great use of D-Trace - running vagrant FreeBSD boxes, the pulling the trace output into Instruments to analyze. With the release of Trim for ZFS, ZFS pooling for logging should be obscenely fast and offer some serious performance increases for things like proper Hadoop workloads. When I find myself on Debian I'm enthralled by the ease of use around layouts and the API ( kqueue / epoll excluded ). The package management system is far superior to portsnap, though neither system really does modern package management really well imo.
Personally, I think it's worth trying to run BSD and all it's tools just to understand the system better, and to see how it influences you as a developer. The active utilization of D-Trace changed me as an engineer just as much when I first started using functional programming concepts in my regular code
I thought btrfs was going nowhere for a while because it seemed way behind zfs for a long time.
But now it looks like it's catching up, and has some nice userspace tools, and some features that I don't even think zfs has (like the option to do overwrite-in-place, but you give up checksums/compression).
The user tools seem worse than zfs, but it does look like btrfs will be a leading filesystem soon.
I wouldn't say soon. Btrfs needs much more robust userspace tools. At the moment, the tools tell you nothing, and recovery is basically impossible. I have lost data several times now. While I had backups since I was using btrfs, I didn't expect to lose data the way that I did. The drive filled up with metadata, and since it didn't have anywhere to rebalance the metadata it couldn't move it, and even if I deleted files it wouldn't make a difference. It happened to me on two occasions. The interesting thing is that btrfs filesystem df showed I only had 80gb total, with a 120gb drive. Decided to go back to xfs for that drive, and I use zfs for my raidz2 array.
They absolutely can ship it. They choose not to. There is a big difference.
It's what happens when ideology is allowed to trump technology, and it is sad.
The fact that various distros ship not-open video card drivers shows that for some things, there's a willingness to compromise. This is far "worse" than shipping an open source module, or open source code that is compiled into a module on install, either of which could be done for ZFS.
The non-free drivers are allowed to be redistributed by the copyright holders. The reason to not distribute them would be ideological.
Linux and ZFS's licenses are incompatible, which would make it illegal to distribute them together. Both ZFS and Linux copyright owners could choose to sue any entity that would distribute Linux with ZFS support.
You take quite a logical leap from "licenses are incompatible" to "illegal to distribute them together." I'd love to know what led you to that conclusion.
As I said to the other poster, you're just spreading FUD.
If the licenses are incompatible, then you cannot ship them together. Calling that FUD is a bit rich! Try going through the process at Fedora. The legal team will stop you.
Licenses allow you to distribute things despite copyright. Usually distributing software without a license is illegal, though there are exceptions in some countries for music and movies.
You can obviously nitpick about that he uses "illegal". However, the discussion was about why ZFS is not distributed. That is what the answer was about, incompatible licenses making it (somewhat) impossible for distributions to carry it.
Now various distributions do have e.g. "nonfree" repositories, but incompatible licenses are a big problem. Responding to such concerns with "just spreading FUD" seems to (hopefully) indicate you're not involved with any distribution.
Dude, that's literally what "licenses are incompatible" means.
The GPL gives you a license to distribute IF AND ONLY IF all the linked binaries have AT LEAST the same permissive rights as the GPL mandates. The CDDL gives rights SIMILAR to GPL, but in a way that is incompatible, i.e. which does not let you distribute CDDL code with all the permissions the GPL mandates. As such, you void the license to distribute the GPL code, as you're unable to comply with the GPL license (i.e. the bit that all linked binaries have at least the GPL enforced liberties).
The GPL's license to distribute is dependent on you distributing binaries with the appropriate permissions and the CDDL won't let you.
Shipping non-open graphics drivers together with the linux kernel is a violation of the GPL. Providing non-open binaries separately from the linux kernel is not. The GPL only applies to distribution, if you're not distributing GPL code (for instance, only your non-open drivers) there's no problem.
The GPL puts no restrictions on use, i.e. once you've got both linux and your non-open drivers the GPL doesn't care whether you combine the two.
Additionally, as people point out the license can only be enforced by copyright holders, so if no linux copyright owners bother to sue people distributing non-open drivers, nothing will happen.
This is however rather shaky legal ground, as at any point you could get sued for violating the license. This also why linux doesn't ship ZFS, since the CDDL is incompatible with GPL any company distributing linux with ZFS would open itself to a potential lawsuit by any linux copyright holder. You can imagine most companies are not very happy taking this risk.
With regards to Richard Yao's comments, of course he's not worried. Copyright violation (which is what breaking the GPL is) only lets you sue for monetary damages or to stop the distribution. There's zero reason for people to sue most linux distros as they're non-profits that aren't charging for distribution. Since it's nearly impossible to show monetary loss by a linux copyright holder (it's being distributed for free!) The only thing to possibly do would be to sue the distros into ceasing distribution, which seems an undesirable outcome for most linux copyright holders, so that's unlikely to be enforced.
Since GPL doesn't restrict actual usage the users of these distros have nothing to worry about anyway.
In summary, you only have to worry about being sued if you are both violating the GPL and making some sort of money while doing it. But the fact that you probably won't get sued doesn't mean that what you are doing is not illegal.
- Well, in any country that's signed the Berne Convention, anyway.
There is no issue with non-free drivers, since they are explicitly licensed by the copyright owner to be redistributable by anyone and they explicitly installed/enabled by users, so Linux's license is also satisfied.
ZFS could be shipped in a similar manner to drivers, by requiring explicit user action to enable (I believe this is what Gentoo are doing). However, it makes a lot less sense for a filesystem, since the switching costs are much higher than for a graphics driver.
While Linux copyright owners generally allow the (small) breach of GPL that is shipping GPL-incompatible modules (whereas it would be entirely fine if they were installed separately) and the driver copyright owners also explicitly allow redistribution, ZFS's copyright owners have made no such allowance.
It would at least breach ZFS's license to ship it.
Please provide reasoning why you think it's "illegal." Otherwise, you're just spreading FUD, which is the whole reason for people believing a Linux distribution can't ship ZFS on Linux in the first place.
Please provide reasoning how it is ok to distribute it. CDDL is incompatible with GPL. Distributing that would allow your distribution to be sued for copyright violation.
Apart from that, e.g. each time you update your kernel you would have to recompile the modules for that specific kernel. ZFS is also an FS and i wouldn’t want to play jeopardy every time i do an update.
You depend on people outside your distribution to keep up, otherwise it might break when you upgrade your kernel. It's also basically in a perpetual beta.
If you want cool updates stick with linux. If you want a solid system that you can update feeling confident you're not going to break anything, on the other hand...
It depends what do you mean by GUI: if you're asking if it is a desktop ready release, then no, it doesnt come with GUI, but at any point you can install XFCE/Gnome/KDE on it and turn it into a desktop system. However, you might want to look at PC-BSD which is a FreeBSD based desktop oriented release.
If you're asking if it does have graphical installator then yes, it does have ncurses based installator.
FreeBSD targets servers, so after installation you will simply get a text console.
You can install X11 though which by itself is a good experience because it makes you understand how given components interact with each other. They also have great handbook which explains standard administration. Here is section that tells you how to configure X11: http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/x1...
not sure what coreos is but iirr docker is a manager for LXC - and FreeBSD has had good Jail support for eons. There are two approaches for jails (the LXC equivalent for BSD) - ezjail which I heartily recommend and warden from PCbsd which is more GUI orientated.
I have happily runs dozens of "virtual" instances on one machine and people regularly do hundreds. it's robust secure and low cost in resources.
http://www.freebsd.org/relnotes/10-STABLE/relnotes/article.h...
Most interesting to me, this is the first stable release supporting netmap(4).. http://www.freebsd.org/cgi/man.cgi?query=netmap&sektion=4