* OpenSSL has been updated to version 1.1.1a (LTS).
* Unbound has been updated to version 1.8.1, and DANE-TA has been
enabled by default.
* OpenSSH has been updated to version 7.8p1.
* Additonal capsicum(4) support has been added to sshd(8).
* Clang, LLVM, LLD, LLDB, compiler-rt and libc++ has been updated to
version 6.0.1.
* The vt(4) Terminus BSD Console font has been update to version 4.46.
* The bsdinstall(8) utility now supports UEFI+GELI as an installation
option.
* The VIMAGE kernel configuration option has been enabled by default.
* The NUMA option has been enabled by default in the amd64 GENERIC and
MINIMAL kernel configurations.
* The netdump(4) driver has been added, providing a facility through
which kernel crash dumps can be transmitted to a remote host after a
system panic.
* The vt(4) driver has been updated with performance improvements,
drawing text at rates ranging from 2- to 6-times faster.
* Various improvements to graphics support for current generation
hardware.
* Support for capsicum(4) has been enabled on armv6 and armv7 by
default.
* The UFS/FFS filesystem has been updated to consolidate
TRIM/BIO_DELETE commands, reducing read/write requests due to fewer
TRIM messages being sent simultaneously.
* The NFS version 4.1 server has been updated to include pNFS server
support.
* The pf(4) packet filter is now usable within a jail(8) using vnet(9).
* The bhyve(8) utility has been updated to add NVMe device emulation.
* The bhyve(8) utility is now able to be run withing a jail(8).
* Various Lua loader(8) improvements.
* KDE has been updated to version 5.12.5.
I would be concerned about the ability to fsck a UFS2 filesystem with enough inodes in it to require 64-bit inodes... As late as 2010/2011 fsck would fail to allocate enough memory to successfully repair a filesystem with <200M inodes ...
I have it on good authority (the author of UFS) that there is no reason to use UFS instead of ZFS unless you are severely memory constrained.
Perhaps I misunderstand the new feature you are highlighting ?
No, it's a kernel ABI change such that all of the stat(2), getdirents(2), etc, ABIs take and pass a 64-bit value instead of a 32-bit one. This enables:
(1) 64-bit NFS fileservers
(2) Direct-pointer "inode" numbers for FUSE filesystems or cd9660/UDF
In particular, I'd point you at d_namlen bumping to 16 bits, MNAMELEN to 1024 bytes (from the anemic 88), and nlink_t from 16 bits to 64 bits. None of these are necessarily used in any particular filesystem, yet, but the generic ABI support is now present.
> there is no reason to use UFS instead of ZFS unless you are severely memory constrained.
Eh, that's an oversimplification. Here a few reasons:
(1) Addressing the "severely" in the above: ZFS memory usage is astronomical, and it is sort of designed to be a filer — it thinks all of the RAM is for its use. It eats all of memory for cache (which is fine, that's what any filesystem cache does) but is slow to release memory under pressure. Also, it requires significantly larger caches than most other filesystems to perform acceptably.
(2) Database and similar workload performance — ZFS is a CoW filesystem. That has all of the same problems for databases and similar workloads as any other CoW filesystem. Namely, overwritten blocks will be reallocated to a completely different part of disk and you lose any physical contiguity you might have had. This matters on spinning media and is a factor in why ZFS requires large caches to perform acceptably.
(3) Journaling. ZFS intent log essentially duplicates the number of bytes written to media. This definitely has benefits (powerfail consistency) but also is an obvious cost.
(Also, that same UFS author continues to work on adding UFS features, because Netflix pays him to. Netflix isn't a charity; they've pretty clearly determined that UFS provides better value to them than ZFS. And they have a phenomenal engineering organization, so I'd tend to trust them on that. YMMV, of course; unless you run a CDN, your workload likely isn't anything like Netflix's.)
As a long term FreeBSD user who was bitten by recent (8 up to 11) source update issues I would have loved a disclaimer upfront: "we broke it again" or "we finally got back to normal"....
Support for FreeBSD 8 ended sometime in 2015, FreeBSD 11 did not come out until mid 2016 and if it was a recent update i can see why the huge jump could cause update issues. The answer to what caused your issue was most likely in the UPDATING file in the source directory.
I have been using FreeBSD since 3.x in 1999 and have only been bitten by source updates when I failed to follow procedure and read the UPDATING file. Anyway source update from 11.2 to 12 worked for me fine.
Going from 8 to 11 you would probably be best off by backing up your data (do this anyway) and making a fresh 11 install. Reinstalling apps is super easy with pkg.
I've never seen an OS updater that is happy to jump 3 major versions at once, especially since the old one has fallen off of even legacy support.
I am not talking about 8 to 11 in one go. With 8.x I experienced the first literally broken source update and a few came after that.
I've switched from Linux to FreeBSD in 1999 because I was fed up with chunky/broken binary updates. One used to be able to compile 3 versions ahead on a running system and boot into a working, clean setup. I am lazy, of course I tried (and succeeded most of the time).
But since 8 even the standard practice of migrating one major version at a time as well as updates from latest n.x to m.0 was broken for people who did not drink the "pkg and freebsd-update!" kool-aid. My allergies to that are raid controllers not supported by GENERIC kernel and a general preference to include into software only what I need - make.conf makes that really easy and maintenance is a breeze simply because we're not hit by as many security issues.
Neat! I haven't yet found the commit that did it, but it appears that dtrace's stop(), which was broken in 11.2-RELEASE, now doesn't cause kernel panics.
Also interesting:
> The dtrace(1) utility has been updated to support if and else statements.
I believe that it's only a change in the front-end parser and that logic of this sort is still implemented via the old predicate/multiple clauses trick, but some syntactic sugar is still welcome.
> I believe that it's only a change in the front-end parser and that logic of this sort is still implemented via the old predicate/multiple clauses trick, but some syntactic sugar is still welcome.
Aawww, I just upgraded my home server from 11.1 to 11.2, now I have to do it again? Fortunately, upgrading FreeBSD is a lot more convenient these days than it used to be.
FreeBSD 11.2 continues to be a supported release. There's no need to upgrade at this point. Also, from experience, unsupported FreeBSD releases generally continue to work as well as they did while they were supported (which is to say, pretty well); they don't turn into a pumpkin when support stops.
I was half joking. When I first got to know FreeBSD, the way to upgrade was to rebuild from source and then perform all kind of magic incantations to merge the new configuration files and whatnot. freebsd-update(8) has made this whole experience much more convenient. I consider myself a competent Unix user, but I am glad these days I do not need to be a wizard to keep things working.
I guess I will upgrade my trusty home server over the holidays, and I am looking forward to it. ;-)
The problem is when the packages disappear from the mirrors. Even if you're ok with running older and possibly insecure packages, it makes it more difficult to update. Best to just keep with the supported versions and avoid the headaches.
> I just upgraded my home server from 11.1 to 11.2, now I have to do it again?
You don't have to do anything. As with other software, FreeBSD supports multiple releases. 11.2 is still a supported version, and 11.x will be supported until the year 2021.
Put the finishing touches on my NAS build on Thursday, saw 12.0 was in RC3, decided to check the release schedule, and held off getting too deep into the setup ;)
Kind of an odd use-case here but I have a NVMe SSD that I'm using as a scratch drive and it might be nice to have ports on that drive rather than my main drive. Is there a way to move just the ports and symlink it back into /usr, or do I have to move the whole /usr directory and alter fstab?
I have been trying out FreeBSD 12 as a desktop using the "TrueOS" distribution[1], as a UNIX user it has been very refreshing. I did this because the Ubuntu 18.04 experience felt to me strongly that the Linux community was focused on turning the desktop into a Windows clone.
The handbook is also part of the 'refreshing' part of using this system. Lots of documentation even for the more obscure parts (not saying that package management is obscure though)
"There is no less information about BSD than "Linux", it is simply that BSD has no advertisement or companies behind pushing it.."
Which is ironic since huge companies like netflix, sony, citrix, netapp and others make appliances based on FreeBSD and contribute a ton of code (Note, i am not at all disagreeing with your statement, i just find it ironic).
I have heard people complain because the handbook needs updating in some areas, but to be fair it is an open source handbook and people can make submissions to help make it better.
Maybe I am wrong, but as far as I remember IXsystems is pushing TrueOS and some other appliances like FreeNas.
My point was simply aiming to underline that there is no analogue of RHEL or Centos in the BSD world. If you decide to endorse BSD you know you are on your own and you have to contribute to the project. The BSD license seems a bit more appealing to this huge giants than the GNU one. Fixing bugs and contributing to the code base is the reason why I love the project.
For purely educational reasons you can learn more in 5 minutes using BSD, than in 10 years with Ubuntu (what is it that one learns with Ubuntu actually?).
The handbook is just awesome. If people complain about it, it is just because they never looked at how documentation is written in the average in computer science (is software documented at all?).
To be fair, there is very little difference between Linux and BSDs these days, and the choice between them is mostly the matter of personal preference. Yes, Linux is more popular and enjoys somewhat better support by third-party vendors (which could in some cases be limited to a small set of distributions), which is why it is usually a safe choice; otherwise there not much reason to choose one over another.
FreeBSD is an entire operating system. Linux is just a kernel used in hundreds of different distros. It is correct that they are both UNIX like derivatives. FreeBSD is based on the BSD license, Linux on the GPL (this is important if you want to make something proprietary, like the PS4).
Most major Linux distros have different package managers and you download binary updates. They supply their own kernel with backports and custom compiled to stay in sync with the rest of their userland. In FreeBSD the kernel and userland are in sync so you dont have this issue.
Linux has better driver support due to more exposure to hardware.
You can go one for quite a while about how different they are, so they are very different. But you are right it is user preference.
Well, this mantra is really getting old - because when people say "Linux" they almost never talk about Linux-the-kernel. Which is also why, for instance, nobody calls Android "Linux", but when referring to Ubuntu, Slackware, etc., they do.
You are misunderstanding. It actually makes a huge difference.
Let's compare apples to apples: Ubuntu vs. FreeBSD.
In Ubuntu there is a kernel made by one group (the Linux project), a bunch of userland tools and C compiler made by another group (the GNU project), desktop environment made by the GNOME project, etc. etc.
Whereas FreeBSD is just FreeBSD. It is one project, in one source tree, maintained by one group of people. (The biggest exception to this is the C compiler -- it is a third-party project which gets imported into the main tree. But that's a minor thing compared to Ubuntu which does this for everything.)
That's not really the best of examples because the C compiler and desktop environments are not part of FreeBSD's base system, let alone developed by FreeBSD devs. In that regard Ubuntu and FreeBSD are similar.
I'd have probably gone with init daemons, ABIs and other core systems. Maybe mention how some of the base CLI tools differ (eg GNU has slightly different flags and rules for ordering them for `cp`, `find`, `ps`, etc).
FreeBSD is a bit of a gateway drug in that it's the most like GNU of all the BSDs. Had you use OpenBSD as your point of comparison then the differences would have been easier to describe. But ultimately you're always going to get some cross-pollination across all the POSIX platforms (eg GNU/Linux uses OpenBSD's OpenSSH; FreeBSD has a bunch of GNU tools; and all of the above platforms will run most DEs, Apache projects, etc). That's a good thing though - it was the point of POSIX.
I just wish there wasn't so many differences with syscalls - but that's moan about a very specific problem I'm having on a current hobby project.
The C compiler is in fact part of the FreeBSD base system (if it weren't, you would need to install a port just to update from source. You don't.) You are right that it's one of the few pieces that is developed outside the project (and periodically imported into the tree).
It is, on the other hand, fully supported. Bugs in the C compiler are considered bugs in the OS and will be fixed.
I don't need a desktop environment or care about having one, so it not being part of the core OS doesn't bother me.
I'll copy-and-paste my thoughts on why I like FreeBSD from an earlier comment I made:
"Every one I have used installs the source code to the entire OS in /usr/src and make it very easy to change and recompile the system. On the BSDs I mentioned, if you don't understand how something works or you want to fix some bug, it's usually pretty easy to go find the source code, read it and learn how it works, and fix it. On most Linux-based OSs you would have to go figure out which random organization makes the component that has a bug (Linux project for the kernel, GNU for a lot of utilities, zillions of others for everything else), figure out how to download and build the source and install it into your distro (which is probably totally unsupported since your distro will expect to be using RPMs or DEBs rather than random stuff installed from tarballs...)
This is the most salient feature of the modern pc BSDs to me. It's impossible to describe how different it feels to be truly in control of your system and understand/change it however you want."
Preaching to the choir there; im a fully paid up FreeBSD contributor and use it on several personal systems. It’s a great platform to use :)
The reason I brought the DE into the equation was simply because it was being compared against Ubuntu. I don’t really think Ubuntu is the best case study there either to be honest but I’m just following on from the post that preceded me.
Sure, but you would never run into having the wrong version of ifconfig, because it's not distributed through ports, it's in in the same repo as the kernel, so they are distributed together.
Of course, but this is true for any OS. Some random freeware you download isn't magically going to be in sync with your release of Windows, either.
In FreeBSD at least there is a real, fully-featured, usable OS out of the box, all consistent, in one source tree at /usr/src which is quite easy to read, change, and build. Unlike most GNU/Linux distros where each random thing like "grep" is its own package developed by its own separate group of people.
Allow me to clarify: the way FreeBSD ports are built, updated, and pushed to mirrors means that ABI compatibility may sneak in accidentally and that updating subsets of your installed package base is unreliable and may introduce, e.g., applications that depend on missing SONAMEs.
Linux distros avoid this problem by separating the process of committing to an individual port/source package; building that individual package, and possibly rebuilding dependencies; and pushing out updates, which are atomic and can contain an updated library and all of its dependencies. My experience is that Linux package managers (dnf/rpm anyway) are better at catching operations that would introduce broken ABIs, as well.
In contrast, the FreeBSD ports model is to invoke poudriere periodically and rebuild all ports at once, then push the entire set out to mirrors. There is no automation that checks for ABI changes in libraries, and pkg(1) does not do a great job of confirming that a library upgrade does not break installed programs (or other libraries) via SONAME bump; much less symbol changes not reflected in SONAME.
How much have you used {Free,Open,Net}BSD? I find the experience to be completely different from that of using any of the Linux distros I've tried, and I'm wondering what you find similar about them...
Maybe the init system in the 90's was similar when Slack was compared to contemporary Linux distros. There is very little modern resemblance. I wish this perception would go away. Spend a day with both and I'd put money on an honest person never making this claim again.
Late in reply - I switched off from Slack to FreeBSD around 2006. Perhaps things have changed, but Slackware generally followed the BSD conventions of what goes where as opposed to say RedHat.
The important thing is however that even though there might be less info it is much more consistent! It is even so old fashioned that you can work without Internet how-to's - it is all there in the "man" pages.
bsd is a family of operating systems, not one. I'm going to answer based on FreeBSD, the system I have more experience with.
1) yes it does, both as source and as binaries (and the same for the base system itself)
2) not sure what you mean, but... (see next answer)
3) https://www.freebsd.org/doc/handbook/ and the man pages. Back in 2000s, the FreeBSD handbook was the best documentation for unix based systems. I could bet a fiver this is still the case.
You felt that one desktop manager of one specific Linux distribution was like Windows and decided to extrapolate it to all desktop managers of all distributions of Linux and go for a non-Linux version?
Or from the TrueOS handbook:
"TrueOS® uses several similar, but different elements to their counterparts on Windows."
I hope that you and your Windows' will be happy together.
I have run a lot of different desktops for Linux. I don't know precisely how much of the space I've covered but all of the more "mainstream" ones. Prior to loading TrueOS and its desktop I was using xfce. Prior to that my most common desktop was KDE. I've used different Gnome variants, Unity variants, bare bones variants.
And non of that is used as an argument. You just yell Ubuntu 18.04 with an unspecified desktop and conclude that you like none of the Linuxes with whatever Desktop and decide without argument that you do like FreeBSD.
My advise to you is to be more specific because it still doesn't make any sense.
The issues for Ubuntu 18.04 were several; Changing networking once again, additional encroachment of systemd on otherwise solved problems, new (and unneeded to me) cloud extensions that required research to turn off, Etc. My post here was not to 'slam' Ubuntu, it was to share that I had tried a Desktop version of FreeBSD (those are rare) and found it quite refreshing and familiar.
I am running Xubuntu 18.04 and unless one is running some cloud image one has little to adjust. I am not even defending (x)ubuntu or over TrueOS. I had been running a FreeBSD Desktop when it was called PCBSD and found it to be lacking very early on.
My opinion is that it is a nice OS for email and browsing but a developer should not have to endure the pain of the constant fight to keep up with tooling.
I don't think being "a Windows clone" is necessarily a bad thing. If anything, this could help to show people that Linux is not as "user-hostile" as they might have thought.
I don't think Linux becoming a "Windows clone" is necessarily a bad thing either, it is a user preference on my part. My background is UNIX workstations, which was the 'feel' that Linux had for a long time. But open source is by definition a function of those who can commit to the source base. As the Linux community has evolved so have the design tastes. I hate systemd, I understand the argument made by the systemd team for why they think it is a superior solution to what existed before, but it doesn't change my distaste for the architecture style. I look for alternatives and TrueOS was suggested and I tried it out, so far I like it.
Does it matter whether random people think Linux is user-hostile? Why is it important that grandma be able to use Ubuntu instead of macOS or Windows on her desktop?
Yes! How do you think you bring new people in to the Linux community? Everyone starts somewhere, and no one is teaching Linux desktop to primary school students.
Anecdotally, the first Linux experience that I was able to install and operate myself, after a handful of prior failed attempts, was Ubuntu (2005). And a big part of that was that it was friendly to absolute beginners like myself.
Now I am a FreeBSD developer and have patches in a plethora of open source projects, including Linux. Everybody starts somewhere!
I don't think being a Windows clone helps with adoption because you often end up with people getting wound up Linux looks familiar but behaves completely differently. Then all of Linux's differences are seen as problems (because it's not behaving as expected) rather than perfectly reasonable design decisions.
I'd rather Linux look different. I'm not saying it has to look alien nor hard to use either. But different enough that when people choose to use it, they come to it with a mindset that they can't just treat it like a Windows clone.
Well, MacOS behaves “completely differently,” too, so what? (By the way, Windows has been behaving completely differently from itself over the past few versions.)
I can't tell if you're disagreeing with me or not because the tone reads as if you're making a counterargument but your arguments are actually agreeing with me.
> Well, MacOS behaves “completely differently,” too, so what?
...so when people come to use OS X they don't expect it to work like Windows and thus are more tolerant to having to alter their workflow accordingly.
Which is the point I'm making about how Linux harms itself when it tried to emulate Windows too closely.
> (By the way, Windows has been behaving completely differently from itself over the past few versions.)
Yes, and people complain frequently about it. I don't see how that contradicts the point I was making.
While Linux shouldn't be purposely user-hostile if it wants to be used in a desktop computer environment, Linux has a different purpose than emulating Windows. That's why Linux can't really be compared to something like ReactOS. It's purpose (in my opinion) is libre software and configurability options (compared to operating systems such as Windows). To change both of those in the name of proprietary software and/or forced ease of use/non-configurability would alienate the original purpose and fracture the community. That's why systemd/Poetteringware is so controversial (and GRUB2 on a much smaller scale), and the near-universal hatred of systemd among UNIX veterans for its mostly-successful monopolism over init systems (and everything else nobody on a lower-end system would ever run at once) only proves my point. While Linux's reputation as a desktop Unix-like does warrant the need for ease-of-use to truly be considered as that, there is a reason that people use Linux and Windows in different situations and environments.
Yes, TrueOS is really refreshing experience, IMO Ubuntu became windows XP with release 8.10, when I just switched away and never looked back. One thing I wish TrueOS did better was desktop integration, they decided to develop their own DE - Lumia, IMO they would do much better with Plasma5 integration.
I love FreeBSD, so I don't think you made a bad choice, but if you ever want to try Ubuntu again go with Lubuntu instead of the Gnome based Ubuntu. It's a far better UX IMHO.
Not quite. The desktop-specific portion of PC-BSD and TrueOS of earlier this year can now be found at Project Trident. TrueOS is built on FreeBSD, adding in OpenRC, LibreSSL, and the rest; and Project Trident is built on TrueOS. Roughly.
I switched back to Debian/Devuan on my laptop. I also use FreeBSD and OpenSuSE on servers, along with Debian. OpenSuSE was not my choice but company policy. I've grown to like it though because it just works and zypper is quite a breeze. Not so many packages as Debian or FreeBSD though, sometimes you have to compile more exotic stuff. FreeBSD is rock solid and much more consistent than Linux, because it's a full blown OS, as opposed to a kernel with GNU software slapped over it. Linux distributions also made some questionable choices like systemd adoption.
Sorry, good point. its a modification to how TCP backs off under loss, and then re-approaches the prior rate. Traditional TCP does an exponential back-off and recovery model. This takes a long time to get back to the fastest achieved rate. Its a very jaggy sawtooth. BBR gets back to the prior rate faster.
BBR is a very fast recovery algorithm. Its not always very "fair" to other forms of TCP. BSD and Linux both have kernels which allow selection of different methods of backoff. BSD has cubic, and some other choices, at this point only Linux appears to have the BBR method integrated. It is in test in the BSD stack (I believe)
If you have sole use of a host, and want to do long-distance file transfer, with loss, BBR can sometimes get you things faster. If you're in a Data Center (DC) BBR can cope really well with dumb switch packetloss, getting you significantly faster recovery.
If you need it and have the ability to maintain your own tree shoot me a note and I will put you in contact with the right folks. Not ready for unrestricted use but it is usable and in wide use.
The RACK stack is in 12.0 and provides many wanted benefits outside of BBR's proficiency against channel loss. I can blog or something about how to build and use it if interested.
"need" is moot. I want it, but in general release. I don't want to have to maintain kernel independently unless I get a strong signal of other benefit (eg better ZFS/Memory tuning)
I run a clutch of Dells, on FB and they're moving to Debian for other reasons, where I get BBR. I would have fought harder to retain them on BSD if we'd had signs the network stack was getting the same amount of attention.
When VJ moved to coding against Linux instead of BSD, I think the writing was on the wall. When Grenvilles team in Melbourne disintegrated, and that source of TCP energy dissipated, the writing pushed the wall over. (I think they moved to netflix)
Shrug, if you are just a bystander it does make sense to go wherever the spectacle is.
There is a competent team working on TCP at Netflix, led by Randall Stewart. They collaborate regularly with VJ and his Google team and the IETF tsvwg.
We wound up on Debian for some linodes in the field and found mixed os maintenance a hassle.
We run the BSD core because we're a three person research activity run by dinosaurs who had BSD systems in the eighties and stuck to them all the time since.
Now we are exposed to things like iscsi and ceph and Hadoop and elk stack.. and it's just too bloody hard to survive in ports on freebsd for this stuff. It's become corner case.
BBR is a case in point. Data fetch to the home nodes on bsd from Asia, Europe and the USA (we're in oz) was two to three times slower than via a Debian node because of it.
I've had the chance to meet several of the developers at the BSDCan conferences; kudos people, you really deserve it.
I moved to BSD world when Debian adopted SystemD and I am happy that I did. It is often said that Linux is more stable then Windows, well BSD could be considered like Granite compared to Linux. I really love it.
OpenBSD for the edge, and FreeBSD for internals and workstations.
The driver updates are very welcome too, getting my video card to work 4k@60Hz was a bit of a task finding the correct driver, but I see this update addresses that too.
Once again, thank-you to everybody who contributes.
As someone who hasn't used BSD, but is considering it for a small server (not mission critical, so OK for me to be learning with), could you expand on the major differences to you between OpenBSD and FreeBSD (vs possibly other options)? When you say you like OpenBSD "for the edge", do you mean cutting-edge, or edge network equipment? Thanks!
OpenBSD is more conservative and security-minded, so I'd say network edge. Interestingly though, its laptop hardware support has historically been better.
OpenBSD devs actually tend to use OpenBSD on their own systems (and most of them own ThinkPads), which, weirdly, is not the case with most FreeBSD devs, who run something else on their desktop.
Maybe they pull some things sometimes but I get the sense their command-line tools in general are just unmaintained and collecting dust. Do you have a citation that they pull regularly?
They pulled at least once, historically, but don't seem to pull on a regular basis. Anyone who wants newer tools than the few they keep updated installs homebrew.
> It is often said that Linux is more stable then Windows, well BSD could be considered like Granite compared to Linux
Not your quote, but I would add: ... and think of OpenBSD to FreeBSD as diamond to granite, 'rock solid' is understatement :)
"We have fixed many simple and obvious careless programming errors in code and only months later discovered that the problems were in fact exploitable." https://www.openbsd.org/security.html
I had a completely opposite experience with freebsd. It felt like a fossil from the past, the boot time was immensely bigger than that on linux with systemd, drivers are old (drm drivers are very old and mostly backported from linux).
The init system is lacking, service maintenance is basically absent. There are also no killer features over linux, beyond zfs and (doubtfully) jails. Even if you are a systemd hater (which is imho unreasonable), you could stick to linux without systemd and have a better hardware and software support.
>drivers are old (drm drivers are very old and mostly backported from linux).
The ones in base are fairly old, but the ones in ports are equivalent to Linux 4.16, so about six months old. Yes they're ported from Linux, I don't see why that's a problem.
The rest of your post can be summed up with "I like systemd." That's fine, other people disagree.
>The ones in base are fairly old, but the ones in ports are equivalent to Linux 4.16, so about six months old. Yes they're ported from Linux, I don't see why that's a problem.
I'm sure improvements could be made to FreeBSD init, but all you're saying is you'd prefer one more like systemd. Then you're free to use something else.
>You also forget about software argument, why to use freebsd if you would use linux-layer all the way.
You aren't using a Linux layer all the way, you are for video card drivers. As for why, they're free software. Using the Linux ones makes more sense than building new ones from scratch.
> I was talking about lack of hardware and software support, so you need a compatibility layer for commercial linux software.
The linuxkpi kernel API compatibility layer is for open source software (e.g., dual-licensed BSD/GPL Linux DRM drivers), not for commercial Linux software.
The linuxemul syscall ABI layer can be used to run commercial Linux software, but is an entirely different and unrelated component. It has nothing to do with hardware support. This is like claiming that because WINE exists, Linux uses Windows for hardware support.
> the boot time was immensely bigger than that on linux with systemd
FreeBSD dev here. This is a totally valid criticism of FreeBSD. Systemd has done a lot for Linux despite the controversial nature of way it has done it, as well as the continued scope creep that draws hostility. One thing it did from the very beginning was provide first-class service management and real on-demand service launch, in parallel. We could learn some lessons from systemd.
> drm drivers are very old and mostly backported from linux
They're completely backported from Linux; that's true. You can install drm-kmod from ports and automatically get an appropriate drm depending on your installed FreeBSD version: fbsd11.2 for 11.1, fbsd12.0 for 12.0, current for CURRENT (head).
fbsd11.2 is on Linux 4.11; the rest are on Linux 4.16. That's not super old (April 2018).
There is also the drm-legacy-kmod, which contains the ancient Linux ~3.8 drm drivers backport. It isn't suggested for most users and is mostly present for very old, insecure hardware that Linux no longer supports (e.g., mach64, mga, r128, savage, sis, tdfx, via) and proprietary ARM products (mmel@ wrote an angry screed to a private mailing list his TEGRA-based product absolutely depended on these obsolete Linux drivers) that have not yet updated to newer DRM versions.
> The init system is lacking, service maintenance is basically absent.
Totally agree.
> There are also no killer features over linux,
That isn't quite true, as you point out. ZFS and jails are significant features. Capsicum is a significant security feature.
I was considering setting up a new desktop machine with either OpenBSD or DesktopBSD (which is based on FreeBSD). Does anyone have any recommendations on which to choose? Any interesting experiences using BSD as a daily driver?
Speaking for FreeBSD as my desktop, no, no interesting experiences to report. I ran my law office for almost 10 years on FreeBSD straying only to Windows to run accounting software. Please consider the lack of interesting experiences a positive from someone who views an interesting tool as a thing to study but probably not something to rely on day in day out.
I found OpenBSD in my brief stint to be too useless as a desktop. The installer is quite hostile and stupid (and I don't mean advanced or unix-like before someone tries to defend it; it's actually hostile and retarded. It wiped my gpt table without asking me). The performance was terrible out of the box. It couldn't saturate a standard gigabit Ethernet link on my w530 in iperf, scp etc. pkg management was really slow. pkg_add takes ages like a windows 95 machine. And it doesn't have a standard package update mechanism without relying on a third party like mtier. All in all, the impression I got from using OpenBSD was that it's best used either as an ingredient like OpenSSH in other better operating systems, or maybe for some other specific use cases where these flaws can be overlooked.
This is surprising. When did you last try it? A fresh install of 6.4 feels very lean and mean although a little sluggish when browsing the web for example. OpenBSD just feels really solid and simple, but powerful if you want it to be. The whole system feels very well integrated, nothing out of place. For my purposes I much prefer pledge to seccomp. It is much easier for me to use one of pledges' system call subsets, risking allowing a little bit more than necessary, than doing the equivalent in seccomp. Sure it might be more fine-grained, but I won't bother. I guess nothing stops developers from adding their own pledge syscall subsets to their kernel and recompile it, thus getting closer to seccomp control.
However my box doesn't feel as snappy as a lean Debian 9 install with xfce4. You have to decide if that's a dealbreaker :)
I've been using FreeBSD on my desktop and notebook for the past 3 years and I have nothing to complain!
Granted, I do not have the habit of playing games or using large, unsupported software (say, Photoshop and friends). My daily applications consist of Emacs and Firefox, so my feedback may be limited in scope.
I'm not sure what the status is, but last I checked Electron did not work on FreeBSD. If you use something Electron-based, you might want to take a look at it.
I also am unable to access my iPhone filesystem and to watch Netflix movies. But for both cases, I blame the vendor and not FreeBSD. A VM on bhyve quickly solves the problem.
Overhead for the host, or the guest? Host is comparable — majority of the cost will be memory allocated to the guest.
Guest overhead will vary by workload. I know for example that virtio-net performance lags Linux, because virtio-net was designed for Linux skb's and doesn't align well with FreeBSD's mbufs. Give it a shot and see how it compares, I guess.
I have had good experiences with both of them. In my fairly limited experience with both of them on the same laptop, OpenBSD worked better with the hardware. ACPI, battery, graphics, and a few other things worked much better than with FreeBSD (less tweaking for basic hardware stuff).
From a philosophy perspective, OpenBSD seems to prefer sane defaults and a complete base system. For the laptop, I needed to install no packages to get a fully functioning system (minus a web browser; that was the first and only thing I installed). I had to do more “basic” configuration on Free than on Open, but I ended up doing quite a bit on both.
OpenBSD has a somewhat strange update system, where patches to stable packages are not provided, requiring you to either build updated packages yourself, follow —current, or use a third party (M:Tier, for instance).
My recommendation is to try both and see which works better on your hardware and which philosophy makes more sense to you. They’re both great operating systems.
I'm using netbsd as my daily driver. If you got some free time to play with FOSS it can be great. I can dive into a lot of fields and it's a lot easier to edit out the sources and change out parts on the BSDs than most places. You can easily read the source code for everything you use.
While rough around the edges, it can be comfortable enough that I forget about it most of the time.
All the BSDs are better if you're not using the shiniest of hardware, they do eventually get hardware support for things, but not always at day zero.
I setup my (decade) old laptop as a server running on FreeBSD. And the elaborate documentation is a real lifesaver, especially as someone who is new to the ecosystem. Even, for the obscure hardware specific setup (yea, looking at you sony vaio), I could find relevant information on their forum which interestingly had relevant information from ages ago.
Really great job guys and thank you! Can't wait to upgrade!
Could you share what you found, by any chance? I've been having some trouble configuring GRUB for Linux on an old VAIO with UEFI (kinda works, but required weird workarounds and seems still flaky); I'm really interested in any success stories with booting OSes on their hardware.
Yea kinda a bummer that I had to buy a USB dongle for a brand new XPS-13 I wanted to install FreeBSD on. I knew I had to, and considering the rest of the hardware was supported I considered it a fair trade off, because I really wanted a FreeBSD dev laptop.
I would like to help with the lack of wifi drivers situation, I'm solid programing in C, but writing network drivers seems intimidating.
Then check out the relevant mailing lists and/or join the IRC channels; there are developers out there focusing solely on WiFi drivers for FreeBSD and they’ll welcome your effort with open arms if you’re willing to learn the ropes. :)
I got roped into writing network drivers for a research project back in undergrad.
The actual work to be done was fairly straightforward; the difficulty was collecting all the different undocumented hardware APIs and figuring out how to use them. :P
Then it might be even harder to do it right in Linux than FreeBSD. It is because Linux's ABIs change so frequently that you have to stick to some distributions to follow even if you want broader support :-)
The biggest thing I'm waiting for with FreeBSD is the TLS sendfile work that Netflix has done. They have said a few times they are open to open sourcing it, but the code needs to be cleaned up.
Also I'm interested in whats been going on with concurrencykit[1]? I saw it got imported into the kernel a couple years ago[2]. What's the progress on incorporating concurrencykit?
Netflix's TLS sendfile probably won't ever be imported. It isn't full TLS, just single-key output. It works for Netflix because they control the client software and if the client requests a re-key or other session change, they can just drop the connection and let the client reconnect. It isn't really obvious how it would be cleaned up to be general enough to import, and it would be a ton of work with little payoff.
ConcurrencyKit is imported and used for efficient read-mostly datastructures in FreeBSD 12, mostly in networking applications such as IP routing and link-level address caching (i.e., ARP in IPv4 Ethernet). It's also used in network interface drivers, HWPMC, TCP, and the linuxkpi emulation layer (to emulate RCU).
I don't think it would be desirable for the kernel to handle rekeying, the socket should get sent back to userspace for that. That would probably require some wrangling, and it's certainly easier to do it in a good enough fashion rather than try to clean it up and get it upstreamed, but it's not impossible. I'm certainly guilty of not getting enough energy around upstreaming patches too, though.
> I don't think it would be desirable for the kernel to handle rekeying, the socket should get sent back to userspace for that. That would probably require some wrangling, and it's certainly easier to do it in a good enough fashion rather than try to clean it up and get it upstreamed, but it's not impossible.
Sure; I agree. I tried to address that under "It isn't really obvious how it would be cleaned up to be general enough to import, and it would be a ton of work with little payoff."
After all, you have to integrate with OpenSSL (or whatever) on the userspace side somehow too. And OpenSSL is contrib code, so we can't just hack it willy-nilly.
OpenSSL already has integration for Linux's similar kTLS support (bulk transmit encryption only; all other alerts, renegotiation etc punted back to userspace). If you wrote it to provide the same API then the OpenSSL support side would be easy.
Very welcome suprise! I was excited about pNFS four years ago, but couldn't find any open source system to play with. Finally it is time for some mirrored pNFS testing.
Any practical advantage of using *BSD on workstation over Linux at this moment? I heard that most of BSD developers use macOS, so the hardware compatibility is terrible.
1) Your workstation is a desktop as opposed to a laptop,
2) You have an NVidia graphics card (or use your motherboard default graphics card), and
3) You do not need CUDA
then FreeBSD is pretty likely to work out of the box with your hardware.
The biggest practical advantage for me is that the source code to the entire OS is installed in /usr/src and is very easy to read, modify, learn from, and build/install. So if you need to know how some obscure OS tool works, instead of browsing weird forums all day you can just read the source.
The hardware support isn't all that bad, but FreeBSD is indeed pickier than Linux or Windows :-). Reasons why I like it include excellent documentation (light years ahead of anything in Linux land), ports & friends (things like Poudriere), and ZFS. I also like Capsicum but I don't use it much.
If that's relevant to you, it also doesn't use systemd (I don't mind it because I learned how to use it properly, but I'd certainly love a break from troubleshooting it...)
BSDs have significantly better documentation and are far more consistent because the base system is developed with the kernel as part of a complete whole. Administering FreeBSD is quite refreshing by comparison to administering GNU/Linux.
My 10 year old Dell XPS M1330 with Intel Core 2 Duo T8100 and 4 GB RAM with original HDD still running strong, had 11.2 installed on it. I just finished updating it to 12.0 release without any issues. I have only good things to say. I use Xfce. The filesystem is ZFS.
A while back, I took a snapshot of /root and installed Gnome 3. It was too big for my laptop. I rolled back. The snapshot and rollback were amazingly fast.
I find FreeBSD more cohesive. I have not tried it on modern devices, but my experience with it on my decade old laptop and VMs is extremely positive.
A similar cohesiveness is achieved only when I handcraft my Arch. Maybe, it is just the feeling.
I was so close (about a nanometer!) to adopting FreeBSD as my desktop OS due to it's plethora of software, amazing package management, great usage of RAM, and roots in true Unix, but one sad day, I installed WINE. It was working with all the applications I expected it to, except for one... Steam. The WINE version was too old. I tried and tried again, even compiling it straight from the staging git branch, but it didn't compile. Alas, FreeBSD is my server OS. It keeps my at least a bit sane knowing I have FreeBSD somewhere in my home.
153 comments
[ 1.8 ms ] story [ 121 ms ] thread(drum roll)
64-bit inodes!!
I would be concerned about the ability to fsck a UFS2 filesystem with enough inodes in it to require 64-bit inodes... As late as 2010/2011 fsck would fail to allocate enough memory to successfully repair a filesystem with <200M inodes ...
I have it on good authority (the author of UFS) that there is no reason to use UFS instead of ZFS unless you are severely memory constrained.
Perhaps I misunderstand the new feature you are highlighting ?
No, it's a kernel ABI change such that all of the stat(2), getdirents(2), etc, ABIs take and pass a 64-bit value instead of a 32-bit one. This enables:
(1) 64-bit NFS fileservers
(2) Direct-pointer "inode" numbers for FUSE filesystems or cd9660/UDF
(3) Probably other uses I'm forgetting
Additionally, other ABI enhancements were committed as part of the ino64 work: https://svnweb.freebsd.org/base?view=revision&revision=31873...
In particular, I'd point you at d_namlen bumping to 16 bits, MNAMELEN to 1024 bytes (from the anemic 88), and nlink_t from 16 bits to 64 bits. None of these are necessarily used in any particular filesystem, yet, but the generic ABI support is now present.
> there is no reason to use UFS instead of ZFS unless you are severely memory constrained.
Eh, that's an oversimplification. Here a few reasons:
(1) Addressing the "severely" in the above: ZFS memory usage is astronomical, and it is sort of designed to be a filer — it thinks all of the RAM is for its use. It eats all of memory for cache (which is fine, that's what any filesystem cache does) but is slow to release memory under pressure. Also, it requires significantly larger caches than most other filesystems to perform acceptably.
(2) Database and similar workload performance — ZFS is a CoW filesystem. That has all of the same problems for databases and similar workloads as any other CoW filesystem. Namely, overwritten blocks will be reallocated to a completely different part of disk and you lose any physical contiguity you might have had. This matters on spinning media and is a factor in why ZFS requires large caches to perform acceptably.
(3) Journaling. ZFS intent log essentially duplicates the number of bytes written to media. This definitely has benefits (powerfail consistency) but also is an obvious cost.
(Also, that same UFS author continues to work on adding UFS features, because Netflix pays him to. Netflix isn't a charity; they've pretty clearly determined that UFS provides better value to them than ZFS. And they have a phenomenal engineering organization, so I'd tend to trust them on that. YMMV, of course; unless you run a CDN, your workload likely isn't anything like Netflix's.)
I'm a BSD noob.
I have been using FreeBSD since 3.x in 1999 and have only been bitten by source updates when I failed to follow procedure and read the UPDATING file. Anyway source update from 11.2 to 12 worked for me fine.
I've never seen an OS updater that is happy to jump 3 major versions at once, especially since the old one has fallen off of even legacy support.
I've switched from Linux to FreeBSD in 1999 because I was fed up with chunky/broken binary updates. One used to be able to compile 3 versions ahead on a running system and boot into a working, clean setup. I am lazy, of course I tried (and succeeded most of the time).
But since 8 even the standard practice of migrating one major version at a time as well as updates from latest n.x to m.0 was broken for people who did not drink the "pkg and freebsd-update!" kool-aid. My allergies to that are raid controllers not supported by GENERIC kernel and a general preference to include into software only what I need - make.conf makes that really easy and maintenance is a breeze simply because we're not hit by as many security issues.
The canonical path is something like(this is documented somewhere):
8.0 > 8.4 > 9.0 > 9.3 > 10.0 > 10.4 > 11.0 > 11.2
Although I've had decent luck jumping straight from X-STABLE branches.
Yes, something like this. For 11.x I had to go to a specific patch level first (IIRC due to LLVM version bump).
Also interesting:
> The dtrace(1) utility has been updated to support if and else statements.
I believe that it's only a change in the front-end parser and that logic of this sort is still implemented via the old predicate/multiple clauses trick, but some syntactic sugar is still welcome.
Correct.
I guess I will upgrade my trusty home server over the holidays, and I am looking forward to it. ;-)
You don't have to do anything. As with other software, FreeBSD supports multiple releases. 11.2 is still a supported version, and 11.x will be supported until the year 2021.
See this page for more info: https://www.freebsd.org/security/
> Fortunately, upgrading FreeBSD is a lot more convenient these days than it used to be.
Agreed. freebsd-update has made life so much easier.
Kind of an odd use-case here but I have a NVMe SSD that I'm using as a scratch drive and it might be nice to have ports on that drive rather than my main drive. Is there a way to move just the ports and symlink it back into /usr, or do I have to move the whole /usr directory and alter fstab?
[1] https://www.trueos.org/
There's no shortage of info or places to seek help about BSDs on the net, FreeBSD has an active forum at https://forums.freebsd.org
AUR and Gentoo Portage are very closely inspired by Ports though.
https://www.freebsd.org/doc/handbook/
This is the first and only resource you have to hit when the question is: "how do I do that in FreeBSD?"
Section 4. answers your second question.
There is no less information about BSD than "Linux", it is simply that BSD has no advertisement or companies behind pushing it...
Which is ironic since huge companies like netflix, sony, citrix, netapp and others make appliances based on FreeBSD and contribute a ton of code (Note, i am not at all disagreeing with your statement, i just find it ironic).
IX Systems does push behind it a lot and does advertise it: https://www.ixsystems.com
I have heard people complain because the handbook needs updating in some areas, but to be fair it is an open source handbook and people can make submissions to help make it better.
My point was simply aiming to underline that there is no analogue of RHEL or Centos in the BSD world. If you decide to endorse BSD you know you are on your own and you have to contribute to the project. The BSD license seems a bit more appealing to this huge giants than the GNU one. Fixing bugs and contributing to the code base is the reason why I love the project.
For purely educational reasons you can learn more in 5 minutes using BSD, than in 10 years with Ubuntu (what is it that one learns with Ubuntu actually?).
The handbook is just awesome. If people complain about it, it is just because they never looked at how documentation is written in the average in computer science (is software documented at all?).
Most major Linux distros have different package managers and you download binary updates. They supply their own kernel with backports and custom compiled to stay in sync with the rest of their userland. In FreeBSD the kernel and userland are in sync so you dont have this issue.
Linux has better driver support due to more exposure to hardware.
You can go one for quite a while about how different they are, so they are very different. But you are right it is user preference.
(I excluded systemd and init to avoid a holy war)
Well, this mantra is really getting old - because when people say "Linux" they almost never talk about Linux-the-kernel. Which is also why, for instance, nobody calls Android "Linux", but when referring to Ubuntu, Slackware, etc., they do.
Let's compare apples to apples: Ubuntu vs. FreeBSD.
In Ubuntu there is a kernel made by one group (the Linux project), a bunch of userland tools and C compiler made by another group (the GNU project), desktop environment made by the GNOME project, etc. etc.
Whereas FreeBSD is just FreeBSD. It is one project, in one source tree, maintained by one group of people. (The biggest exception to this is the C compiler -- it is a third-party project which gets imported into the main tree. But that's a minor thing compared to Ubuntu which does this for everything.)
I'd have probably gone with init daemons, ABIs and other core systems. Maybe mention how some of the base CLI tools differ (eg GNU has slightly different flags and rules for ordering them for `cp`, `find`, `ps`, etc).
FreeBSD is a bit of a gateway drug in that it's the most like GNU of all the BSDs. Had you use OpenBSD as your point of comparison then the differences would have been easier to describe. But ultimately you're always going to get some cross-pollination across all the POSIX platforms (eg GNU/Linux uses OpenBSD's OpenSSH; FreeBSD has a bunch of GNU tools; and all of the above platforms will run most DEs, Apache projects, etc). That's a good thing though - it was the point of POSIX.
I just wish there wasn't so many differences with syscalls - but that's moan about a very specific problem I'm having on a current hobby project.
Or any desktop environment, for that matter, or much of everything else of any importance for the end user.
It is, on the other hand, fully supported. Bugs in the C compiler are considered bugs in the OS and will be fixed.
I don't need a desktop environment or care about having one, so it not being part of the core OS doesn't bother me.
I'll copy-and-paste my thoughts on why I like FreeBSD from an earlier comment I made:
"Every one I have used installs the source code to the entire OS in /usr/src and make it very easy to change and recompile the system. On the BSDs I mentioned, if you don't understand how something works or you want to fix some bug, it's usually pretty easy to go find the source code, read it and learn how it works, and fix it. On most Linux-based OSs you would have to go figure out which random organization makes the component that has a bug (Linux project for the kernel, GNU for a lot of utilities, zillions of others for everything else), figure out how to download and build the source and install it into your distro (which is probably totally unsupported since your distro will expect to be using RPMs or DEBs rather than random stuff installed from tarballs...)
This is the most salient feature of the modern pc BSDs to me. It's impossible to describe how different it feels to be truly in control of your system and understand/change it however you want."
The reason I brought the DE into the equation was simply because it was being compared against Ubuntu. I don’t really think Ubuntu is the best case study there either to be honest but I’m just following on from the post that preceded me.
This is true for the base system, but not necessarily true for ports / pkg. You can end up with an inconsistent pkg collection, unfortunately.
rm -Rf /var/db/pkg/* /usr/local/* /usr/ports/distfiles/*
reboot the system and all the non OS packages (installed via ports and packages) are gone and you can start over (reboot is probably optional).
In FreeBSD at least there is a real, fully-featured, usable OS out of the box, all consistent, in one source tree at /usr/src which is quite easy to read, change, and build. Unlike most GNU/Linux distros where each random thing like "grep" is its own package developed by its own separate group of people.
Linux distros avoid this problem by separating the process of committing to an individual port/source package; building that individual package, and possibly rebuilding dependencies; and pushing out updates, which are atomic and can contain an updated library and all of its dependencies. My experience is that Linux package managers (dnf/rpm anyway) are better at catching operations that would introduce broken ABIs, as well.
In contrast, the FreeBSD ports model is to invoke poudriere periodically and rebuild all ports at once, then push the entire set out to mirrors. There is no automation that checks for ABI changes in libraries, and pkg(1) does not do a great job of confirming that a library upgrade does not break installed programs (or other libraries) via SONAME bump; much less symbol changes not reflected in SONAME.
No way.
The important thing is however that even though there might be less info it is much more consistent! It is even so old fashioned that you can work without Internet how-to's - it is all there in the "man" pages.
1) yes it does, both as source and as binaries (and the same for the base system itself) 2) not sure what you mean, but... (see next answer) 3) https://www.freebsd.org/doc/handbook/ and the man pages. Back in 2000s, the FreeBSD handbook was the best documentation for unix based systems. I could bet a fiver this is still the case.
2) https://www.youtube.com/watch?v=0gfctgb1mfM
You felt that one desktop manager of one specific Linux distribution was like Windows and decided to extrapolate it to all desktop managers of all distributions of Linux and go for a non-Linux version? Or from the TrueOS handbook:
"TrueOS® uses several similar, but different elements to their counterparts on Windows."
I hope that you and your Windows' will be happy together.
My opinion is that it is a nice OS for email and browsing but a developer should not have to endure the pain of the constant fight to keep up with tooling.
A.k.a. your “customers.”
Anecdotally, the first Linux experience that I was able to install and operate myself, after a handful of prior failed attempts, was Ubuntu (2005). And a big part of that was that it was friendly to absolute beginners like myself.
Now I am a FreeBSD developer and have patches in a plethora of open source projects, including Linux. Everybody starts somewhere!
I'd rather Linux look different. I'm not saying it has to look alien nor hard to use either. But different enough that when people choose to use it, they come to it with a mindset that they can't just treat it like a Windows clone.
> Well, MacOS behaves “completely differently,” too, so what?
...so when people come to use OS X they don't expect it to work like Windows and thus are more tolerant to having to alter their workflow accordingly.
Which is the point I'm making about how Linux harms itself when it tried to emulate Windows too closely.
> (By the way, Windows has been behaving completely differently from itself over the past few versions.)
Yes, and people complain frequently about it. I don't see how that contradicts the point I was making.
It's been ~10 years since I used PC-BSD, but it was certainly a nice distro.
* http://project-trident.org./
* https://trueos.org/blog/trueosdownstream/
BBR is a very fast recovery algorithm. Its not always very "fair" to other forms of TCP. BSD and Linux both have kernels which allow selection of different methods of backoff. BSD has cubic, and some other choices, at this point only Linux appears to have the BBR method integrated. It is in test in the BSD stack (I believe)
If you have sole use of a host, and want to do long-distance file transfer, with loss, BBR can sometimes get you things faster. If you're in a Data Center (DC) BBR can cope really well with dumb switch packetloss, getting you significantly faster recovery.
The RACK stack is in 12.0 and provides many wanted benefits outside of BBR's proficiency against channel loss. I can blog or something about how to build and use it if interested.
I run a clutch of Dells, on FB and they're moving to Debian for other reasons, where I get BBR. I would have fought harder to retain them on BSD if we'd had signs the network stack was getting the same amount of attention.
When VJ moved to coding against Linux instead of BSD, I think the writing was on the wall. When Grenvilles team in Melbourne disintegrated, and that source of TCP energy dissipated, the writing pushed the wall over. (I think they moved to netflix)
There is a competent team working on TCP at Netflix, led by Randall Stewart. They collaborate regularly with VJ and his Google team and the IETF tsvwg.
We run the BSD core because we're a three person research activity run by dinosaurs who had BSD systems in the eighties and stuck to them all the time since.
Now we are exposed to things like iscsi and ceph and Hadoop and elk stack.. and it's just too bloody hard to survive in ports on freebsd for this stuff. It's become corner case.
BBR is a case in point. Data fetch to the home nodes on bsd from Asia, Europe and the USA (we're in oz) was two to three times slower than via a Debian node because of it.
I moved to BSD world when Debian adopted SystemD and I am happy that I did. It is often said that Linux is more stable then Windows, well BSD could be considered like Granite compared to Linux. I really love it. OpenBSD for the edge, and FreeBSD for internals and workstations.
The driver updates are very welcome too, getting my video card to work 4k@60Hz was a bit of a task finding the correct driver, but I see this update addresses that too.
Once again, thank-you to everybody who contributes.
FWIW:
~ man rm | tail -n1
BSD January 28, 1999 BSD
Not your quote, but I would add: ... and think of OpenBSD to FreeBSD as diamond to granite, 'rock solid' is understatement :)
"We have fixed many simple and obvious careless programming errors in code and only months later discovered that the problems were in fact exploitable." https://www.openbsd.org/security.html
The init system is lacking, service maintenance is basically absent. There are also no killer features over linux, beyond zfs and (doubtfully) jails. Even if you are a systemd hater (which is imho unreasonable), you could stick to linux without systemd and have a better hardware and software support.
{Open,net}bsd are another story, though.
The ones in base are fairly old, but the ones in ports are equivalent to Linux 4.16, so about six months old. Yes they're ported from Linux, I don't see why that's a problem.
The rest of your post can be summed up with "I like systemd." That's fine, other people disagree.
Is this matrix outdated?
https://wiki.freebsd.org/Graphics/AMD-GPU-Matrix
>The rest of your post can be summed up with "I like systemd."
It's not about systemd in particular, it's about modern service and system management in general
https://www.freebsdnews.com/2018/08/21/benno-rice-the-traged...
You also forget about software argument, why to use freebsd if you would use linux-layer all the way.
I would guess that it is reflecting the drivers in base, the page above that gives directions on using this driver in ports.
https://www.freshports.org/graphics/drm-fbsd12.0-kmod/
I'm sure improvements could be made to FreeBSD init, but all you're saying is you'd prefer one more like systemd. Then you're free to use something else.
>You also forget about software argument, why to use freebsd if you would use linux-layer all the way.
You aren't using a Linux layer all the way, you are for video card drivers. As for why, they're free software. Using the Linux ones makes more sense than building new ones from scratch.
I see. For 11.2 its 4.11, so it didn't support my vega card.
Upgrade to 12 leaded me to kernel panic on startup on my shitty laptop's cpu, this bug [1].
>You aren't using a Linux layer all the way, you are for video card drivers.
I was talking about lack of hardware and software support, so you need a compatibility layer for commercial linux software.
[1] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=233534
The linuxkpi kernel API compatibility layer is for open source software (e.g., dual-licensed BSD/GPL Linux DRM drivers), not for commercial Linux software.
The linuxemul syscall ABI layer can be used to run commercial Linux software, but is an entirely different and unrelated component. It has nothing to do with hardware support. This is like claiming that because WINE exists, Linux uses Windows for hardware support.
FreeBSD dev here. This is a totally valid criticism of FreeBSD. Systemd has done a lot for Linux despite the controversial nature of way it has done it, as well as the continued scope creep that draws hostility. One thing it did from the very beginning was provide first-class service management and real on-demand service launch, in parallel. We could learn some lessons from systemd.
> drm drivers are very old and mostly backported from linux
They're completely backported from Linux; that's true. You can install drm-kmod from ports and automatically get an appropriate drm depending on your installed FreeBSD version: fbsd11.2 for 11.1, fbsd12.0 for 12.0, current for CURRENT (head).
fbsd11.2 is on Linux 4.11; the rest are on Linux 4.16. That's not super old (April 2018).
There is also the drm-legacy-kmod, which contains the ancient Linux ~3.8 drm drivers backport. It isn't suggested for most users and is mostly present for very old, insecure hardware that Linux no longer supports (e.g., mach64, mga, r128, savage, sis, tdfx, via) and proprietary ARM products (mmel@ wrote an angry screed to a private mailing list his TEGRA-based product absolutely depended on these obsolete Linux drivers) that have not yet updated to newer DRM versions.
> The init system is lacking, service maintenance is basically absent.
Totally agree.
> There are also no killer features over linux,
That isn't quite true, as you point out. ZFS and jails are significant features. Capsicum is a significant security feature.
The installation is very quick and then it just work on my t470. Documentation is excellent. Try it.
However my box doesn't feel as snappy as a lean Debian 9 install with xfce4. You have to decide if that's a dealbreaker :)
Granted, I do not have the habit of playing games or using large, unsupported software (say, Photoshop and friends). My daily applications consist of Emacs and Firefox, so my feedback may be limited in scope.
I'm not sure what the status is, but last I checked Electron did not work on FreeBSD. If you use something Electron-based, you might want to take a look at it.
I also am unable to access my iPhone filesystem and to watch Netflix movies. But for both cases, I blame the vendor and not FreeBSD. A VM on bhyve quickly solves the problem.
Guest overhead will vary by workload. I know for example that virtio-net performance lags Linux, because virtio-net was designed for Linux skb's and doesn't align well with FreeBSD's mbufs. Give it a shot and see how it compares, I guess.
From a philosophy perspective, OpenBSD seems to prefer sane defaults and a complete base system. For the laptop, I needed to install no packages to get a fully functioning system (minus a web browser; that was the first and only thing I installed). I had to do more “basic” configuration on Free than on Open, but I ended up doing quite a bit on both.
OpenBSD has a somewhat strange update system, where patches to stable packages are not provided, requiring you to either build updated packages yourself, follow —current, or use a third party (M:Tier, for instance).
My recommendation is to try both and see which works better on your hardware and which philosophy makes more sense to you. They’re both great operating systems.
While rough around the edges, it can be comfortable enough that I forget about it most of the time.
All the BSDs are better if you're not using the shiniest of hardware, they do eventually get hardware support for things, but not always at day zero.
Really great job guys and thank you! Can't wait to upgrade!
I would like to help with the lack of wifi drivers situation, I'm solid programing in C, but writing network drivers seems intimidating.
The actual work to be done was fairly straightforward; the difficulty was collecting all the different undocumented hardware APIs and figuring out how to use them. :P
Also I'm interested in whats been going on with concurrencykit[1]? I saw it got imported into the kernel a couple years ago[2]. What's the progress on incorporating concurrencykit?
[1]: http://concurrencykit.org/
[2]: https://www.freshbsd.org/commit/freebsd/src/309260
ConcurrencyKit is imported and used for efficient read-mostly datastructures in FreeBSD 12, mostly in networking applications such as IP routing and link-level address caching (i.e., ARP in IPv4 Ethernet). It's also used in network interface drivers, HWPMC, TCP, and the linuxkpi emulation layer (to emulate RCU).
You might be interested in this blog post: http://scalebsd.org/blog/2018/06/16/UDP-and-epoch-for-livene... and https://www.freebsd.org/releases/12.0R/relnotes.html .
Sure; I agree. I tried to address that under "It isn't really obvious how it would be cleaned up to be general enough to import, and it would be a ton of work with little payoff."
After all, you have to integrate with OpenSSL (or whatever) on the userspace side somehow too. And OpenSSL is contrib code, so we can't just hack it willy-nilly.
https://github.com/openssl/openssl/blob/d6c3c1896cf3c0d69bc2...
https://www.phoronix.com/scan.php?page=news_item&px=FreeBSD-...
Very welcome suprise! I was excited about pNFS four years ago, but couldn't find any open source system to play with. Finally it is time for some mirrored pNFS testing.
1) Your workstation is a desktop as opposed to a laptop,
2) You have an NVidia graphics card (or use your motherboard default graphics card), and
3) You do not need CUDA
then FreeBSD is pretty likely to work out of the box with your hardware.
The biggest practical advantage for me is that the source code to the entire OS is installed in /usr/src and is very easy to read, modify, learn from, and build/install. So if you need to know how some obscure OS tool works, instead of browsing weird forums all day you can just read the source.
If that's relevant to you, it also doesn't use systemd (I don't mind it because I learned how to use it properly, but I'd certainly love a break from troubleshooting it...)
A while back, I took a snapshot of /root and installed Gnome 3. It was too big for my laptop. I rolled back. The snapshot and rollback were amazingly fast.
I find FreeBSD more cohesive. I have not tried it on modern devices, but my experience with it on my decade old laptop and VMs is extremely positive.
A similar cohesiveness is achieved only when I handcraft my Arch. Maybe, it is just the feeling.