Debian developer revisits FreeBSD after 20 years (2015)(changelog.complete.org)
changelog.complete.org
Debian developer revisits FreeBSD after 20 years (2015)
http://changelog.complete.org/archives/9317-has-linux-lost-its-way-comments-prompt-a-debian-developer-to-revisit-freebsd-after-20-years
128 comments
> At work, we are pretty much a Windows shop, and I am often frustrated by the state of Microsoft's documentation
I have to agree. Every job I had after college was a windows stack shop while my college/personal experience was purely linux/bsd. Microsoft's documentation has always been terrible. My assumption also was that they did this to sell training, books, etc to customers.
But as you noted, they have improved in recent years. Their .Net and SQL Server documentation is very good. Still wish that microsoft didn't have such a stranglehold on corporate america and we could live in a unix-based world.
I have to agree. Every job I had after college was a windows stack shop while my college/personal experience was purely linux/bsd. Microsoft's documentation has always been terrible. My assumption also was that they did this to sell training, books, etc to customers.
But as you noted, they have improved in recent years. Their .Net and SQL Server documentation is very good. Still wish that microsoft didn't have such a stranglehold on corporate america and we could live in a unix-based world.
> But in other parts, documentation is crappy or non-existant (I am looking at you, SharePoint!) to such a degree that sometimes I wonder if they do this on purpose to generate business for the hordes of consultants and authors to write books
Very likely. See: Oracle.
Very likely. See: Oracle.
I would say "See: IBM" but sometimes their documentation is brokered by their sales division, so there isn't anything to see for many.
> I wonder if they do this on purpose to generate business
It's ironic that money can make a product worse.
It's ironic that money can make a product worse.
It's why planned obsolescence features so prominently in the modern world.
As a FreeBSD user, I agree with this article.
Virtualization, which is one of my main use cases, works but is far from perfect. FreeBSD 11 improved things - in particular, UEFI graphics exposed over VNC makes installing Windows less painful (however, I couldn’t get networking working in the guest so it wasn’t terribly useful). One huge miss is that UEFI variables aren’t persisted across guest reboots, so it’s entirely possible to install a system and not be able to boot it without issuing UEFI commands.
I really like the clean split between base system and 3rd-party software. However, I whole heartedly agree that managing 3rd-party software is a mess. Plus, thanks to the ABI issues, doing major version upgrades is kind of scary. I’ve never had an issue with a major version upgrade, but doing it scares me every time.
Finally, there’s one huge issue that FreeBSD finally fixed in 11.1. The kernel was not compiled with IPSEC in 10.x, and in 11.0 they compiled it with IPSEC but not IPSEC_NAT_T. It took until 11.1 for IPSec VPNs to finally be usable out of the box.
Virtualization, which is one of my main use cases, works but is far from perfect. FreeBSD 11 improved things - in particular, UEFI graphics exposed over VNC makes installing Windows less painful (however, I couldn’t get networking working in the guest so it wasn’t terribly useful). One huge miss is that UEFI variables aren’t persisted across guest reboots, so it’s entirely possible to install a system and not be able to boot it without issuing UEFI commands.
I really like the clean split between base system and 3rd-party software. However, I whole heartedly agree that managing 3rd-party software is a mess. Plus, thanks to the ABI issues, doing major version upgrades is kind of scary. I’ve never had an issue with a major version upgrade, but doing it scares me every time.
Finally, there’s one huge issue that FreeBSD finally fixed in 11.1. The kernel was not compiled with IPSEC in 10.x, and in 11.0 they compiled it with IPSEC but not IPSEC_NAT_T. It took until 11.1 for IPSec VPNs to finally be usable out of the box.
>Finally, there’s one huge issue that FreeBSD finally fixed in 11.1. The kernel was not compiled with IPSEC in 10.x, and in 11.0 they compiled it with IPSEC but not IPSEC_NAT_T. It took until 11.1 for IPSec VPNs to finally be usable out of the box.
Thank you! I wouldn't have known about this without your comment. I need to revisit my VPN configuration, getting it to work on FreeNAS 10.1 was a huge hack.
Thank you! I wouldn't have known about this without your comment. I need to revisit my VPN configuration, getting it to work on FreeNAS 10.1 was a huge hack.
"Virtualization, which is one of my main use cases, works but is far from perfect."
There was a brief period of time when the current, linux release of vmware workstation (v3.0, IIRC) was fully supported under the linux binary compat functionality of FreeBSD.
What this meant was that circa 2002/2003 you could run vmware workstation on FreeBSD and it worked perfectly. I ran all manner of Windows and Linux VMs under it.
I currently use vmware fusion on OSX so I haven't given it a try lately, but my impression is that spinning up a windows VM on a FreeBSD workstation is still not as painless as it was back then ...
There was a brief period of time when the current, linux release of vmware workstation (v3.0, IIRC) was fully supported under the linux binary compat functionality of FreeBSD.
What this meant was that circa 2002/2003 you could run vmware workstation on FreeBSD and it worked perfectly. I ran all manner of Windows and Linux VMs under it.
I currently use vmware fusion on OSX so I haven't given it a try lately, but my impression is that spinning up a windows VM on a FreeBSD workstation is still not as painless as it was back then ...
> I couldn’t get networking working
Try using the e1000 network adapter emulation - Win10/Server 2016 work fine with this.
Try using the e1000 network adapter emulation - Win10/Server 2016 work fine with this.
"There are only two FreeBSD filesystems that are really useable: UFS2 and ZFS."
Keep in mind that the intense proliferation of different filesystems on Linux is the rare exception. On Windows, you get FAT, NTFS and ReFS, but nobody uses ReFS, and FAT is mostly for USB drives, SD cards and such.
On macOS, the situation is not that much different: They have HFS+, more recently APFS, and they support FAT so you can use USB drives and such.
In practice is not much of a problem. Especially when one of your two options is ZFS. ;-)
Keep in mind that the intense proliferation of different filesystems on Linux is the rare exception. On Windows, you get FAT, NTFS and ReFS, but nobody uses ReFS, and FAT is mostly for USB drives, SD cards and such.
On macOS, the situation is not that much different: They have HFS+, more recently APFS, and they support FAT so you can use USB drives and such.
In practice is not much of a problem. Especially when one of your two options is ZFS. ;-)
You're also forgetting about exFAT which is also supported with full r/w on Windows, macOS, and Linux.
Personally, I've got a partition with exFAT so I can transfer data between everything on my drives...
Personally, I've got a partition with exFAT so I can transfer data between everything on my drives...
Exfat is also painful to use in OpenBSD. There is something called exfatfuse but it is quite buggy.
The only way I could make USB drives that were usable on other machines was to use fat32 with mkfs.msdos.
OTOH NTFS read support is excellent on both FreeBSD and OpenBSD. But overall I admit that it is painful if you need to work with USB drives.
The only way I could make USB drives that were usable on other machines was to use fat32 with mkfs.msdos.
OTOH NTFS read support is excellent on both FreeBSD and OpenBSD. But overall I admit that it is painful if you need to work with USB drives.
Read support is fine, write support varies from nonexistent to merely crippled. One implementation allows you to write to NTFS only in the case where you were overwriting existing bits in a file, and even that was buggy.
I keep all my external drives ExFAT so I can use them easily everywhere.
ExFAT can be problematic due to corruption. I used to have an external HDD formatted to ExFAT plugged in on my raspberry pi. When crashes occured whilst having torrent open, the disk never fully recovered. I had to constantly run repairs.
For small drives e.g. USB sticks ExFAT is great but for larger drives I'd stay away from ExFAT.
For small drives e.g. USB sticks ExFAT is great but for larger drives I'd stay away from ExFAT.
My own anecdota: I haven't experienced this ever with exFat on 20+ USB Flash/HDD drives and I regularly experience crashing Raspberry Pi's (Raspbian OS) and various flavors of Windows.
Microsoft's own OneDrive refuses to use ExFat volumes, as of last year.
"but nobody uses ReFS" - citation needed. It seems to come up on the Veeam forums quite a lot which implies to me that an awful lot of data is stored on ReFS.
I wont disagree with you that I do have access to a lot of file systems but I should point out that Linux has a lot of developers and some of those filesystems picked Linux for that exact reason. I like choice and I have lots.
A variety of FAT is also used for UEFI partitions (cheers MS) and you seem to have missed out exFAT which is quite handy.
ZFS is great on physical hardware in some cases and deserves its name but for me: ext4 does the trick. It's just complicated enough, and no more.
I wont disagree with you that I do have access to a lot of file systems but I should point out that Linux has a lot of developers and some of those filesystems picked Linux for that exact reason. I like choice and I have lots.
A variety of FAT is also used for UEFI partitions (cheers MS) and you seem to have missed out exFAT which is quite handy.
ZFS is great on physical hardware in some cases and deserves its name but for me: ext4 does the trick. It's just complicated enough, and no more.
Could summarize to Linux is more commercial marketing checkbox oriented now, whereas FreeBSD is the good old days of itch scratching.
For example, RAID5 hasn't been interesting to me as sysadmin for decade or more now for a variety of reasons. I did use it back in the days of single digit gig hard drives to create something useful sized, but its not the "right" way to do almost everything now except for the weirdest corner cases, that can be worked around in much better ways. Its something marketing can checkbox so commercialized Linux will NEVER remove it. I remember the good old days of having qty six two gig hard drives and software RAID5 on top of them. Those days aren't coming back, but they were good old days.
On the opposite side, the handbook is useful on a regular basis, so people often use it, and maintain the heck out of it, making it even more more useful, repeat.
For example, RAID5 hasn't been interesting to me as sysadmin for decade or more now for a variety of reasons. I did use it back in the days of single digit gig hard drives to create something useful sized, but its not the "right" way to do almost everything now except for the weirdest corner cases, that can be worked around in much better ways. Its something marketing can checkbox so commercialized Linux will NEVER remove it. I remember the good old days of having qty six two gig hard drives and software RAID5 on top of them. Those days aren't coming back, but they were good old days.
On the opposite side, the handbook is useful on a regular basis, so people often use it, and maintain the heck out of it, making it even more more useful, repeat.
"doesn't have raid5 in geom but has raidz1 in zfs" got me. Geom is useful as a layer abstraction without raid5 and zfs has raid5 equivalent (and better) so.. why does it matter?
I like FreeBSD’s sane layouts, awesome documentation, and simple administration. But seriously the handbook is documentation gold.
> But seriously the handbook is documentation gold.
Amen to that!
Amen to that!
Gold if you compared it with what? I think that Arch wiki is superb and have a lot of more information for the experience user than the FreeBSD manual which is excellent only for the first approach.
Gold compared to what Microsoft and many commercial ISVs dump on their customers as "documentation".
The Arch Wiki is superb, indeed. Let's call it platinum. ;-)
My issue is that if volunteer driven projects like FreeBSD, Arch Linux or OpenBSD can provide very high quality documentation, I expect commercial ISVs to provide documentation that is at the very least that good. Instead, documentation is often either missing entirely or very bad. Or they have the audacity to charge you extra for a manual.
The Arch Wiki is superb, indeed. Let's call it platinum. ;-)
My issue is that if volunteer driven projects like FreeBSD, Arch Linux or OpenBSD can provide very high quality documentation, I expect commercial ISVs to provide documentation that is at the very least that good. Instead, documentation is often either missing entirely or very bad. Or they have the audacity to charge you extra for a manual.
Arch wiki is different, imo, than the manual in that it focuses more on individual applications that run on the system whereas the handbook focuses on the system itself. I have used both on freebsd, FWIW.
There only better wiki I have seen is the Gentoo wiki.
Site appears down for the moment, but I thought the title sounded familiar.
No qualms with the repost, but for anyone interested there was a very healthy discussion about this article three years or so ago: https://news.ycombinator.com/item?id=9025437
No qualms with the repost, but for anyone interested there was a very healthy discussion about this article three years or so ago: https://news.ycombinator.com/item?id=9025437
I started as a user of FreeBSD, I run Linux at work and on my personal computers, As for my personal servers, I'm all in with SmartOS hypervisor.
SmartOS is so simple to use.
SmartOS is so simple to use.
If I was going to build a private home server, I would choose SmartOS as well. It has all the parts needed and most importantly, virtual networking OOTB via CrossBow. I have not found any feature complete virtual networking in Linux or *BSD. Have to use XEN or VMWare.
With that said, I use Linux for my desktop as it gives the best user experience on a laptop. IMO, FreeBSD and variants still don't cut it at this time for dekstop.
With that said, I use Linux for my desktop as it gives the best user experience on a laptop. IMO, FreeBSD and variants still don't cut it at this time for dekstop.
> IMO, FreeBSD and variants still don't cut it at this time for desktop.
Sadly, I agree. My experience running FreeBSD on a laptop has been terrible. I do have one ancient laptop running OpenBSD that works perfectly. But due to the smaller number of developers and less enthusiastic support by hardware companies, hardware support is far behind Linux.
On the server, this is less of an issue, because there is less hardware to support, and virtualization, it becomes even easier.
Sadly, I agree. My experience running FreeBSD on a laptop has been terrible. I do have one ancient laptop running OpenBSD that works perfectly. But due to the smaller number of developers and less enthusiastic support by hardware companies, hardware support is far behind Linux.
On the server, this is less of an issue, because there is less hardware to support, and virtualization, it becomes even easier.
Too late to EDIT: What I meant to say was: and WITH Virtualization
Have you tried SmartOS as a desktop by chance? I’d love to use SmartOS for my workstation but am currently using Ubuntu with ZoL because I doubted the level of GPU support on SmartOS.
I have not tried it yet but the OpenIndiana project is designated as a desktop distribution of Illumos. SmartOS is based on Illumos as well. OpenIndiana seems promising but I would not set my expectations too high for the desktop experience. However, if you virtualize Ubuntu or another *Nix distribution under OpenIndiana, it may fill some needed gaps.
Thanks, may try OpenIndiana at some point. It’s fairly low on the priority list... but running an Ubuntu/Debian container might be a good approach. Though containers and sharing GPU resources could be tricky.
+1 SmartOS
Underrated.
Underrated.
The main problem of BSD OSes (including FreeBSD and macOS) is that they include different (not 100% compatible) versions of the basic command line tools and the GNU versions usually are better.
Linux distros tend to use the GNU userspace utils (or busybox on embedded systems), while The BSD family uses their own (IIRC, a descendant from the old BSD lineage).
The main difference - as I understand it - is that the BSD variants are strictly POSIX compliant, while GNU tools decided to diverge from that behavior (see: POSIXLY_CORRECT, other compatibility flags) for better usability, more features, and so on.
So, if anything, it is GNU that is "different" and "incompatible".
(Not necessarily a bad thing, mind you)
The main difference - as I understand it - is that the BSD variants are strictly POSIX compliant, while GNU tools decided to diverge from that behavior (see: POSIXLY_CORRECT, other compatibility flags) for better usability, more features, and so on.
So, if anything, it is GNU that is "different" and "incompatible".
(Not necessarily a bad thing, mind you)
> So, if anything, it is GNU that is "different" and "incompatible". (Not necessarily a bad thing, mind you)
What I mean under "incompatible" is not-supporting everything that the other does. Just couple of trivial examples: `sed -i 's/require/include/' Rakefile` throws `invalid command code R` Mac (you must use `sed -i "" 's/require/include/' Rakefile` instead) and `dd` does not support `status=progress` on Mac so you have to pipe it through `pv` and this is not free in terms of performance.
What I mean under "incompatible" is not-supporting everything that the other does. Just couple of trivial examples: `sed -i 's/require/include/' Rakefile` throws `invalid command code R` Mac (you must use `sed -i "" 's/require/include/' Rakefile` instead) and `dd` does not support `status=progress` on Mac so you have to pipe it through `pv` and this is not free in terms of performance.
On BSD (including Mac OS X), you can also type ^t at dd, and it will print status information.
If that doesn't work, do stty status ^t first.
This is SIGINFO; it's been in BSD for a long time, but isn't in Linux and is relatively unknown nowadays. Quite a few BSD command line programs will respond to it.
If that doesn't work, do stty status ^t first.
This is SIGINFO; it's been in BSD for a long time, but isn't in Linux and is relatively unknown nowadays. Quite a few BSD command line programs will respond to it.
Cool! Thanks! This is a thing I wish every program on every OS would support.
Historical note: Some of us remember POSIXLY_CORRECT as POSIX_ME_HARDER.
>not 100% compatible
I would argue it’s the GNU tools that are not 100% compatible. The BSD tools are very much the same as they always have been in Unix of old.
GNU was in fact doing what we generally refer to as „embrace and extend“. And now look at how well it has worked: people refer to the original as „not compatible“
Of course it’s not so relevant as the gnu tools are widely available, but it’s in my opinion still an observation of note.
I would argue it’s the GNU tools that are not 100% compatible. The BSD tools are very much the same as they always have been in Unix of old.
GNU was in fact doing what we generally refer to as „embrace and extend“. And now look at how well it has worked: people refer to the original as „not compatible“
Of course it’s not so relevant as the gnu tools are widely available, but it’s in my opinion still an observation of note.
> I would argue it’s the GNU tools that are not 100% compatible. The BSD tools are very much the same as they always have been in Unix of old.
Of course, that's the point: the GNU tools undergo relatively active development and grow better while the BSD tools don't.
Of course, that's the point: the GNU tools undergo relatively active development and grow better while the BSD tools don't.
Or rather: BSD tools are more backwards- and standards-compatible that GNU ones.
Because they are closer to actual UNIX lineage and POSIX than what GNU tools offer.
In some GNU tools we are even required to explicitly enable POSIX compatible behavior.
However I do agree that GNU tools are easier to use.
Back in the .com days, when I did SunOS administration, they would be one of the first external packages I would install.
In some GNU tools we are even required to explicitly enable POSIX compatible behavior.
However I do agree that GNU tools are easier to use.
Back in the .com days, when I did SunOS administration, they would be one of the first external packages I would install.
And the main solution for that is just install the GNU tools you prefer from ports or packages. Super simple.
Or read the man pages. Which are better in the BSDs as their target audience tends to prefer proper documentation to google searches.
The gnu utilities are fairly well documented in info pages
Sure, but that undermines the part of the premise of a BSD-style OS, where you have an "omakase" base system, maintained as a monolith with known and clearly stated assumptions around compatibility and interoperability between the components of the base system.
You don’t need to honor the “premise” of the OS, nor do I think the developers of the OS care which software I prefer to run. Run whatever you’re comfortable with.
If it was such an issue for them, I’m sure they’d remove the GNU packages they pre-build and host for you. The premise of BSD is you don’t have to use the GNU tools. But they give you the choice.
If it was such an issue for them, I’m sure they’d remove the GNU packages they pre-build and host for you. The premise of BSD is you don’t have to use the GNU tools. But they give you the choice.
Expecting the same tool operation between very different OS's (even if they are all a fork from a common old ancestor) also undermines that premise.
It is pretty trivial on FreeBSD to 'pkg install coreutils.' Then use the GNU versions of these utilities by prefixing 'g'. I actually alias several utilities to the GNU variants on my FreeBSD systems because I prefer their semantics.
(The point of my argument is: this is not an insurmountable problem.)
(The point of my argument is: this is not an insurmountable problem.)
date gets me every time (hah). The date -jnu on OSX is incomplete against bad norms. Linux date is exceptionally hard to remember how to back convert date +%s strings to textual forms which bsd date does elegently.
After using FreeBSD for many years and having to move to linux for various reasons, I still miss kqueue and FreeBSD's superior networking stack.
"The bad: ABI stability
I’m used to being able to run binaries I compiled years ago on a modern system. This is generally possible in Linux, assuming you have the correct shared libraries available."
May be true for terminal stuff that rely mostly on kernel syscalls to get stuff done. But deity help you if you try to get a GUI binary you want to get going. You may well have to clone a distro from back then in terms of libs.
And things may even balk at Xorg if something happens to talk some xlib stuff that didn't come along in the xcb transition...
I’m used to being able to run binaries I compiled years ago on a modern system. This is generally possible in Linux, assuming you have the correct shared libraries available."
May be true for terminal stuff that rely mostly on kernel syscalls to get stuff done. But deity help you if you try to get a GUI binary you want to get going. You may well have to clone a distro from back then in terms of libs.
And things may even balk at Xorg if something happens to talk some xlib stuff that didn't come along in the xcb transition...
Even allowing for the age of the piece this seems pretty partisan.
Only one I'll pick out - RAID5. Who cares about RAID5 with current disk sizes? Should be using ZFS, probably under RAIDZ2 or 3, if you actually care about your data.
Home servers have been running FreeBSD since the days of 2.x. I'll not be giving up ZFS, jails, and what seems to be the best net stack anywhere, any time soon.
Only one I'll pick out - RAID5. Who cares about RAID5 with current disk sizes? Should be using ZFS, probably under RAIDZ2 or 3, if you actually care about your data.
Home servers have been running FreeBSD since the days of 2.x. I'll not be giving up ZFS, jails, and what seems to be the best net stack anywhere, any time soon.
As an ongoing FreeBSD user, a BSD user since the 1980s, and a Debian user since about 5 years ago I agree with this article in main sense. I might differ in details, but its an even handed and fair summary.
Might be something i install to a vm as a project. Not seeing any compelling reasons to switch from arch except zfs
Good news, ZFS also runs on Linux.
http://zfsonlinux.org https://wiki.archlinux.org/index.php/ZFS
http://zfsonlinux.org https://wiki.archlinux.org/index.php/ZFS
Yet it's clearly not native to the same extent and it shows. Article talks about this a fair bit.
And ironically the latest FreeBSD doesn't boot in QEMU if you're using AMD hardware, as of about a month ago. The bug has been open since 2016: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=213333
So filing a QEMU bug on FreeBSD's tracker is supposed to help how?
While we can argue about precisely where the blame lies, I'm leaning towards a FreeBSD bug here since it cannot handle the topology that QEMU supplies (yet Windows, Linux, older FreeBSD can). In any case maybe the FreeBSD community could interact with the QEMU community, since virtualization is probably the way most new FreeBSD users come on board.
I couldn't find this issue on the QEMU bug tracker.
https://bugs.launchpad.net/qemu/
Since you encountered it and I don't yet have AMD hardware to test, would you mind reporting it?
https://bugs.launchpad.net/qemu/
Since you encountered it and I don't yet have AMD hardware to test, would you mind reporting it?
No, because (as discussed above):
(1) I do not think it's a QEMU bug. Windows, Linux and older versions of FreeBSD work fine.
(2) I'm one of those people who thought, let's try to compile some software on FreeBSD .. meh can't get it to work.
It's really for FreeBSD to fix this, if they want to on-board new users (and maybe they don't, that's totally fine too).
(1) I do not think it's a QEMU bug. Windows, Linux and older versions of FreeBSD work fine.
(2) I'm one of those people who thought, let's try to compile some software on FreeBSD .. meh can't get it to work.
It's really for FreeBSD to fix this, if they want to on-board new users (and maybe they don't, that's totally fine too).
I use an older version of QEMU with the latest version of FreeBSD and it works fine.
Well, arch doesn't get used much in the server, and for good reasons.
> The bad: package management
> Roughly 20 years ago, this was one of the things that pulled me to Debian.
yep. synaptic was the thing that drew me from FreeBSD to Ubuntu 5.04. It was so clearly the Right Thing. I wanted to go back and say GUYS HAVE YOU SEEN THIS
that and that on FreeBSD, I kept finding myself running Linux binaries under compat, rather than native binaries, because they were actually more stable. sigh.
> Roughly 20 years ago, this was one of the things that pulled me to Debian.
yep. synaptic was the thing that drew me from FreeBSD to Ubuntu 5.04. It was so clearly the Right Thing. I wanted to go back and say GUYS HAVE YOU SEEN THIS
that and that on FreeBSD, I kept finding myself running Linux binaries under compat, rather than native binaries, because they were actually more stable. sigh.
I'm really surprise how many users see Debian's packing as being so great.
I've contributed to several projects upstream, and, as devs, Debian's packaging is a PITA.
We constantly get bug reports for _very old_ major versions, because Debian is way out of date. We don't support these versions, but bug reports from Debian users keep coming because it's the latest in debian.
But there's actually a worse scenario: bug reports we can't reproduce. Because Debian packagers consistently patch applications in their packages. A lot. So we get bug reports that aren't from our actual code, but rather a "Debian-forked-version".
Clearly, the end-user interests are completely different from the upstream devs'. But the issues are pretty evident from the other side.
I've contributed to several projects upstream, and, as devs, Debian's packaging is a PITA.
We constantly get bug reports for _very old_ major versions, because Debian is way out of date. We don't support these versions, but bug reports from Debian users keep coming because it's the latest in debian.
But there's actually a worse scenario: bug reports we can't reproduce. Because Debian packagers consistently patch applications in their packages. A lot. So we get bug reports that aren't from our actual code, but rather a "Debian-forked-version".
Clearly, the end-user interests are completely different from the upstream devs'. But the issues are pretty evident from the other side.
His negatives are largely overblown or not bound to only FreeBSD. Also, if you want security updates with a shorter time lag then maybe you should contribute them. It’s a much smaller community so it’s going to move slower. Also (2015)
Who here uses FreeBSD in production, and what use-cases do they find it better than Linux for?
We use it at Netflix for our Open Connect CDN.
In general, the FreeBSD performance is far better for our workload (we have served up to 100Gb/s from a single-socket CDN node). In fact, I'm sitting here reading HN while watching a single-socket E5-2697A machine ramp up past 92Gb/s for a 100% TLS workload.
In general, the FreeBSD performance is far better for our workload (we have served up to 100Gb/s from a single-socket CDN node). In fact, I'm sitting here reading HN while watching a single-socket E5-2697A machine ramp up past 92Gb/s for a 100% TLS workload.
I hate to nag you. But whats the status of TLS sendfile? That feature is a great example of what FreeBSD can do, unfortunately it's still closed source.
Yes, sorry. We keep getting busy doing other things. I'm actually working on getting it upstream now. I was testing some "before upstreaming" cleanups to make sure I didn't break anything :)
Can I ask you what your network hardware is and how customized your kernel is (i.e., are you patching the network stack at all or running some vendor-customized drivers, or is it all in mainline)?
We use fairly standard Mellanox and Chelsio 100GbE NICs. Except for TLS sendfile and our vectorized mbufs, most of the patches that we've been running have actually been to the VM system. Thankfully, due in large part to the recent efforts to scale the VM system upstream, a lot of our hacks are going away.
We've got a blog detailing a lot of our work here: https://medium.com/netflix-techblog/serving-100-gbps-from-an...
We've got a blog detailing a lot of our work here: https://medium.com/netflix-techblog/serving-100-gbps-from-an...
"Who here uses FreeBSD in production, and what use-cases do they find it better than Linux for?"
rsync.net[1] is based solely on FreeBSD.
Our cloud storage platform is based on ZFS so it's a natural choice as ZFS is a supported and mature filesystem on FreeBSD.
[1] As always, email for details about the "HN Discount".
rsync.net[1] is based solely on FreeBSD.
Our cloud storage platform is based on ZFS so it's a natural choice as ZFS is a supported and mature filesystem on FreeBSD.
[1] As always, email for details about the "HN Discount".
I use FreeBSD on my FreeNAS in Production. Makes an awesome box to have in a Small business network for all NAS services, backups and also lightweight virtualization for backend scripting and services. I could not recommend FreeBSD via FreeNAS more for these purposes. It just plain works. Almost all configurations can be done via Web GUI and rarely needs touching the root OS via commandline.
We use FreeBSD in production (SaaS accounting/payroll app) as a load balancing proxy/web server (Nginx) and outgoing mail server (OpenSMTPD) because it's a stable, proven OS with sane defaults. Thanks to OpenBSD, we get an awesome firewall (PF) and dead simple OpenSMTPD mail server (total config is around 25 lines which gives us DKIM signing and PKI with no additional software).
At home, FreeBSD is used as a HTPC (Kodi), file server and backup box (it acts like a Time Machine for our Macs via netatalk and for Linux we use rsnapshot over NFS).
At home, FreeBSD is used as a HTPC (Kodi), file server and backup box (it acts like a Time Machine for our Macs via netatalk and for Linux we use rsnapshot over NFS).
I use it. My use case is:
1. After properly setting it up, do sporadic updates when necessary without worrying that the whole thing falls appart.
Much better than Linux ;)
1. After properly setting it up, do sporadic updates when necessary without worrying that the whole thing falls appart.
Much better than Linux ;)
> After properly setting it up, do sporadic updates when necessary without worrying that the whole thing falls appart.
Do not get me wrong, I love that about FreeBSD as well. But a good GNU/Linux distro can do that, too, say, Debian or CentOS. All of the free Unix-like systems are light years ahead of Windows in terms of not spontaneously mutating and breaking things.
I always bite my tongue when people say they like Windows because it "just works", because Windows just as often "just stops" working for no discernible reason. And troubleshooting on Windows is so much more difficult, that surprisingly often, the "solution" is to wipe the system and reinstall everything.
Do not get me wrong, I love that about FreeBSD as well. But a good GNU/Linux distro can do that, too, say, Debian or CentOS. All of the free Unix-like systems are light years ahead of Windows in terms of not spontaneously mutating and breaking things.
I always bite my tongue when people say they like Windows because it "just works", because Windows just as often "just stops" working for no discernible reason. And troubleshooting on Windows is so much more difficult, that surprisingly often, the "solution" is to wipe the system and reinstall everything.
With the latest updates to Windows 10, Win has been working stable lately.
The things I hate are:
- The anti malware service executable eating a lot of CPU
- Terrible, terrible terminal emulation even with the improved powershell window
- The crazy amount of committed memory. Even if you have 16-32 gigs of RAM, the OS still writes pagefiles to disk.
I used to hate that I couldn't customize the Desktop Environment to suit my needs. But with custom Autohotkey scripts it seems to me that sky is the limit.
The windows subsystem for linux is buggy, nevertheless it is usable and helps a great deal. Most gnu software for example Gnuapl compile and work OTB.
I've only witnessed one blue screen of death in the last month.
I should also note that I'm using an 8th gen desktop machine I've built with minimal hardware. Even with Spectre/meltdown patches I didn't experience any trouble.
The things I hate are:
- The anti malware service executable eating a lot of CPU
- Terrible, terrible terminal emulation even with the improved powershell window
- The crazy amount of committed memory. Even if you have 16-32 gigs of RAM, the OS still writes pagefiles to disk.
I used to hate that I couldn't customize the Desktop Environment to suit my needs. But with custom Autohotkey scripts it seems to me that sky is the limit.
The windows subsystem for linux is buggy, nevertheless it is usable and helps a great deal. Most gnu software for example Gnuapl compile and work OTB.
I've only witnessed one blue screen of death in the last month.
I should also note that I'm using an 8th gen desktop machine I've built with minimal hardware. Even with Spectre/meltdown patches I didn't experience any trouble.
I only use Windows at work, where I also used to be the helpdesk guy. These days I spend most of my time programming, so I am somewhat out of the loop lately.
BSOD-wise, Windows has been very stable for a very long time[1]. I am not a fan of Windows, but Windows crashing is a very rare event, and when it happens, in my experience the cause is either a) faulty hardware, b) buggy device drivers or c) crappy AV software mucking around in kernel space (over the last three years, almost all the Windows bluescreens I saw were due to crappy AV software). My work laptop has BSOD'd on me maybe once or twice in three years - and I am one of those people that rarely shutdown or reboot their systems. At the end of the (work) day, I put my laptop to sleep, and only reboot it when an update requires it or when it misbehaves very badly. So I am pushing the system pretty hard.
I did not have much contact with Windows 10, yet, though. My work laptop runs Windows 7, and between Windows 2000 and 8.1, Windows 7 is the one I like best, so I am sticking with it for as long as I can. WSL sounds nice, though. And I heard Windows 10 finally got a native, builtin ssh client.
> Even if you have 16-32 gigs of RAM, the OS still writes pagefiles to disk.
This one has always struck me as odd about Windows. Linux or *BSD, given enough memory, will not swap at all until you push them. Windows seems to do it "proactively". I suppose it gets less annoying with an SSD, but my work laptop has a slow 5400rpm HDD.
[1] I once saw a Windows NT 4.0 Server with six years of uptime. Personally, I shudder at the thought of a server that has not gotten any updates in years, but if that is not a concern, Windows is absolutely capable of accumulating that kind of uptime.
BSOD-wise, Windows has been very stable for a very long time[1]. I am not a fan of Windows, but Windows crashing is a very rare event, and when it happens, in my experience the cause is either a) faulty hardware, b) buggy device drivers or c) crappy AV software mucking around in kernel space (over the last three years, almost all the Windows bluescreens I saw were due to crappy AV software). My work laptop has BSOD'd on me maybe once or twice in three years - and I am one of those people that rarely shutdown or reboot their systems. At the end of the (work) day, I put my laptop to sleep, and only reboot it when an update requires it or when it misbehaves very badly. So I am pushing the system pretty hard.
I did not have much contact with Windows 10, yet, though. My work laptop runs Windows 7, and between Windows 2000 and 8.1, Windows 7 is the one I like best, so I am sticking with it for as long as I can. WSL sounds nice, though. And I heard Windows 10 finally got a native, builtin ssh client.
> Even if you have 16-32 gigs of RAM, the OS still writes pagefiles to disk.
This one has always struck me as odd about Windows. Linux or *BSD, given enough memory, will not swap at all until you push them. Windows seems to do it "proactively". I suppose it gets less annoying with an SSD, but my work laptop has a slow 5400rpm HDD.
[1] I once saw a Windows NT 4.0 Server with six years of uptime. Personally, I shudder at the thought of a server that has not gotten any updates in years, but if that is not a concern, Windows is absolutely capable of accumulating that kind of uptime.
You can set Windows Defender to not proactively scan.
What Linux distribution were you using – something like Gentoo?
I used a few in my past life as a bad sysadmin. Mostly Ubuntu Server's. Some Fedora's, some CentOS's, some Arch Linux. I never did try Gentoo in production servers though.
And through the years I learned to dislike their hive-mind approach to problems with half-baked crippled solutions that get approved and merged to production because some untouchable dev/guru/mastermind decided that he alone was a significant sample of all linux users:
- Forget about extending and improving ifconfig. Lets change everything and create a new command, afterall ifconfig is not that important,.
- Forget about your system dir layout. Lets change it and mix everything up into /
- Oops that kernel update completly screwed iptables...
- Oops that kernel update somehow introduced packet loops in the network
- Today I learned that I/O DoS is.
- wtf systemd ? Now i have to read up on this new sh*t that they are pushing down my throat. Oh wait there is no documentation.
- Don't get me started on filesystems...
Anyhow, I find Unix systems very hard to manage and maintain, i mean we do have all these devops tools to automatically manage configs and programatically setup machines in a coherent way. Linux just likes to show more than others that it exists, and does it in very inappropriate ways.
And through the years I learned to dislike their hive-mind approach to problems with half-baked crippled solutions that get approved and merged to production because some untouchable dev/guru/mastermind decided that he alone was a significant sample of all linux users:
- Forget about extending and improving ifconfig. Lets change everything and create a new command, afterall ifconfig is not that important,.
- Forget about your system dir layout. Lets change it and mix everything up into /
- Oops that kernel update completly screwed iptables...
- Oops that kernel update somehow introduced packet loops in the network
- Today I learned that I/O DoS is.
- wtf systemd ? Now i have to read up on this new sh*t that they are pushing down my throat. Oh wait there is no documentation.
- Don't get me started on filesystems...
Anyhow, I find Unix systems very hard to manage and maintain, i mean we do have all these devops tools to automatically manage configs and programatically setup machines in a coherent way. Linux just likes to show more than others that it exists, and does it in very inappropriate ways.
> Forget about your system dir layout. Lets change it and mix everything up into /
Actually, everything is put into /usr, in / you have just symlinks. And there's a reason for that.
> wtf systemd ? Now i have to read up on this new sh*t that they are pushing down my throat. Oh wait there is no documentation.
One would say, that after 8 years you would be able to find the documentation. It has manpages too.
Actually, everything is put into /usr, in / you have just symlinks. And there's a reason for that.
> wtf systemd ? Now i have to read up on this new sh*t that they are pushing down my throat. Oh wait there is no documentation.
One would say, that after 8 years you would be able to find the documentation. It has manpages too.
Also, while I still oppose systemd (because it's a monolith, because it reinvents logging and because... it comes from the people behind DBus :) I must admit that lately I prefer writing systemd units to making nohup workarounds. I never did grok init.d scripts and from what I've seen neither did lots of other people. So that's a big plus in my book.
I’m not in love with everything about systemd but I’ve noticed that about 90% of the attacks sound to an experienced sysadmin more like the person making the claim has never encountered/ understood the need for that particular feature. Many people will talking lovingly about SysV init without any mention of the many things people did to hack around limitations or the downtime suffered because they didn’t.
(Yeah, it’s not perfect but the rough parts can be improved and I’m looking forward to standardization meaning we never talk about daemonization, automatic restarts, or logging again)
(Yeah, it’s not perfect but the rough parts can be improved and I’m looking forward to standardization meaning we never talk about daemonization, automatic restarts, or logging again)
You have constructed the classic fallacious dichotomy between van Smoorenburg init and systemd.
* http://uselessd.darknedgy.net/ProSystemdAntiSystemd/
* http://uselessd.darknedgy.net/ProSystemdAntiSystemd/
While I note this article is from 2015, Synthing is a very good, open source, file synchronization tool that should work on both FreeBSD and Linux. Nice replacement for Dropbox :)
[deleted]
We really need to support more kernels on NixOS. Different distros duplicating work is unfortunate, and muddles the experiment.
An even less accurate representation now than it was back then.
"btrfs isn’t there yet, but will be awesome when it is."
So awesome that Red Hat Linux even deprecated it.
"Its laptop support leaves something to be desired. I installed it on a few-years-old Thinkpad — basically the best possible platform for working suspend in a Free OS. It has worked perfectly out of the box in Debian for years."
Perfect as in "everything except certain common features and expected annoyances" like suspend/resume et al. But this year is the year you know...
Does anyone even fall for these Linux rants ?
So awesome that Red Hat Linux even deprecated it.
"Its laptop support leaves something to be desired. I installed it on a few-years-old Thinkpad — basically the best possible platform for working suspend in a Free OS. It has worked perfectly out of the box in Debian for years."
Perfect as in "everything except certain common features and expected annoyances" like suspend/resume et al. But this year is the year you know...
Does anyone even fall for these Linux rants ?
I use Debian on desktop and laptop all day every day and have not had a problem with suspend and resume in at least the last 5 years. At this point, it seems to work at least as well as Windows and Mac (perhaps better - I've seen a few Windows users having suspend problems).
I recommend every person who buy a hardware for GNU/Linux to buy one that runs well out of the box with Debian main.
It is a hard requirement I suggest to my friends. May be they run Ubuntu/Fedora, but if it runs well with Debian or linux-libre, rest assured, it should work with any Distribution.
I haven't yet seen much Laptops of notebooks to recommend though. https://h-node.org/ seems to be the only good reference.
It is a hard requirement I suggest to my friends. May be they run Ubuntu/Fedora, but if it runs well with Debian or linux-libre, rest assured, it should work with any Distribution.
I haven't yet seen much Laptops of notebooks to recommend though. https://h-node.org/ seems to be the only good reference.
I have Debian Stretch running on a 3rd gen Thinkpad X1, and had some problems. It took about a year for suspend/resume to work reliably, before I had random lock-ups on resume. It turned out to be a bug in the early MMU code, and once it was fixed I had a very stable experience. This bug was hard to reproduce: on other Thinkpads in my company nobody had the issue, but with a slightly different environment (TP models, Ubuntu not Debian and different kernel versions).
More recently I had a regression for a few months, until the issue was identified (and fixed).
Both experiences made me more sensitive to Linux stability issues. If you look for it, you will find many bug reports. They typically are rather frustrating: they happen for some unlucky guy, but are hard or impossible to reproduce in slightly different contexts. I guess this can't really be avoided: both Linux and a modern PC are complex systems, and there are many variants. And no ODM doing integration tests (or not with your preferred distro of PC configuration). So some glitches are bound to happen. Considering the lack of ODM support and standardization, the situation is actually quite good. But there are bound to be glitches here and there. For those who want to avoid it, it's possible to avoid all this by getting a PC with Linux pre-installed, or with some integration test done (it seems to me there's some work done by Canonical for Ubuntu on some Thinkpad models, but not sure...). Also, not jumping on brand new laptop models can help too.
As for me, I prefer to stick with Debian on my laptop of choice, and handle the rare odd glitch when it happens. It's ok. Still, when I'll buy my next laptop I'll wait for the new generation to arrive, and buy the previous one. Cheaper, more stable with Linux, and not much hardware differences anyway nowadays.
More recently I had a regression for a few months, until the issue was identified (and fixed).
Both experiences made me more sensitive to Linux stability issues. If you look for it, you will find many bug reports. They typically are rather frustrating: they happen for some unlucky guy, but are hard or impossible to reproduce in slightly different contexts. I guess this can't really be avoided: both Linux and a modern PC are complex systems, and there are many variants. And no ODM doing integration tests (or not with your preferred distro of PC configuration). So some glitches are bound to happen. Considering the lack of ODM support and standardization, the situation is actually quite good. But there are bound to be glitches here and there. For those who want to avoid it, it's possible to avoid all this by getting a PC with Linux pre-installed, or with some integration test done (it seems to me there's some work done by Canonical for Ubuntu on some Thinkpad models, but not sure...). Also, not jumping on brand new laptop models can help too.
As for me, I prefer to stick with Debian on my laptop of choice, and handle the rare odd glitch when it happens. It's ok. Still, when I'll buy my next laptop I'll wait for the new generation to arrive, and buy the previous one. Cheaper, more stable with Linux, and not much hardware differences anyway nowadays.
Dell officially supports Ubuntu and sells laptops with it on their store.
I've not had any issues with my XPS 13 on it.
I've not had any issues with my XPS 13 on it.
> Dell officially supports Ubuntu...
Meh. I'm writing this from an Asus EeePC which was once officially supported by Ubuntu, but now with broken graphics and wifi.
The non-free graphics driver is not included in Ubuntu anymore and the wifi works only with non-free binary blob.
Also, I recently found that wifi doesn't support channel 13 and 14 (found it accidentally when my laptop wasn't seeing the nearby hotspot) with the non-free blob. Now I run Debian testing.
Don't trust in those "Officially supported" things, unless it's Debian GNU/Linux. Otherwise, it's eventually going to be broken.
Meh. I'm writing this from an Asus EeePC which was once officially supported by Ubuntu, but now with broken graphics and wifi.
The non-free graphics driver is not included in Ubuntu anymore and the wifi works only with non-free binary blob.
Also, I recently found that wifi doesn't support channel 13 and 14 (found it accidentally when my laptop wasn't seeing the nearby hotspot) with the non-free blob. Now I run Debian testing.
Don't trust in those "Officially supported" things, unless it's Debian GNU/Linux. Otherwise, it's eventually going to be broken.
All the current wifi chipsets require binary blobs. They are considered part of the hardware, they are running on the hardware, not on your cpu, they just aren't shipped on an EPROM, but the driver is loading it at init time.
The channel visibility is regulatory thing; if you see only channels 1-12 you have set it for North America, most of the world can use 1-13, and Japan also 14 (for 802.11b only).
The channel visibility is regulatory thing; if you see only channels 1-12 you have set it for North America, most of the world can use 1-13, and Japan also 14 (for 802.11b only).
[deleted]
Well the GPU is Intel who only make an open source driver.
And the Wifi driver works out of the box.
The world has changed from the times of the EeePC.
The world has changed from the times of the EeePC.
Wifi comes up ?
VPN reconnects ?
USB's and Card readers stay mounted ?
Audio mixer volume stays the same ?
Youtube videos and music player resumes ?
uptime shows the correct information ?
All of this out of the box in 2015 ? That must have been the year of linux on the desktop.
VPN reconnects ?
USB's and Card readers stay mounted ?
Audio mixer volume stays the same ?
Youtube videos and music player resumes ?
uptime shows the correct information ?
All of this out of the box in 2015 ? That must have been the year of linux on the desktop.
Yes all of it. I'm on a thinkpad T450, running Debian oldstable (jessie) which was frozen for release in late 2014.
Suspend-to-disk too?
I don't really do that much so I don't know. It only really happens in laptops when battery is running low while suspended and then something seems to wake the laptop and then hibernate it. Cool trick. No idea how it works though.
Does anyone really use suspend-to-disk? It takes awfully long to write 8-16 GB of data, then awfully long to read it back. It is much faster to just boot, than to restore from suspend to disk.
Yes, that is my experience too on Linux. However, most times it isn’t actually necessary to write the full RAM out and IIRC Windows and macOS actually don’t. There are a few approaches that work, e.g. you can do memory ballooning and drop caches to reduce memory usage before suspending. In addition, you can write unused RAM pages to disk during normal operation, so that when the user wants to suspend, most of the pages are already on disk.
Hybrid-suspend should help avoid read it back from disk if AC or battery power is uninterrupted. Also I find caches dropping benefitting to reduce the suspend time.
If the battery level is at the end the OS should suspend to disk in order to avoid losing work.
> So awesome that Red Hat Linux even deprecated it.
They never "supported" it in the strict meaning of the word, it was only a technical preview and they dropped it from technical preview. That's different from "deprecated" (let alone that Red Hat doesn't have the power to deprecate things in upstream Linux). Not to mention that most/all of Red Hat's btrfs engineers moved to other companies (like Facebook) so nobody was there to maintain it.
The more forward-thinking reason for dropping it is that Red Hat is putting all their eggs into devicemapper+XFS (in the form of "Stratis"[1]), so why would they expend engineering resources on more projects than necessary -- especially when they'll probably want customers to switch to Stratis rather than keep them on a never-actually-supported-by-them filesystem.
[1]: https://github.com/stratis-storage
They never "supported" it in the strict meaning of the word, it was only a technical preview and they dropped it from technical preview. That's different from "deprecated" (let alone that Red Hat doesn't have the power to deprecate things in upstream Linux). Not to mention that most/all of Red Hat's btrfs engineers moved to other companies (like Facebook) so nobody was there to maintain it.
The more forward-thinking reason for dropping it is that Red Hat is putting all their eggs into devicemapper+XFS (in the form of "Stratis"[1]), so why would they expend engineering resources on more projects than necessary -- especially when they'll probably want customers to switch to Stratis rather than keep them on a never-actually-supported-by-them filesystem.
[1]: https://github.com/stratis-storage
Of course Redhat deprecated btrfs support, they are betting on XFS and Stratis. No need to throw resources on competing project, the others in Linux community will carry on.
> Perfect as in "everything except certain common features and expected annoyances" like suspend/resume et al.
I don't think you read that part carefully with proper understanding. The author said, that these annoyances were when running FreeBSD, and that in Debian it doesn't have them.
> Perfect as in "everything except certain common features and expected annoyances" like suspend/resume et al.
I don't think you read that part carefully with proper understanding. The author said, that these annoyances were when running FreeBSD, and that in Debian it doesn't have them.
This is a bsd rant not linux
Is it ?
"There is nothing like Dropbox for FreeBSD. Apparently this is because FreeBSD has nothing like Linux’s inotify. "
Kind of gave it away for me.
"There is nothing like Dropbox for FreeBSD. Apparently this is because FreeBSD has nothing like Linux’s inotify. "
Kind of gave it away for me.
Facebook's watchman uses inotify and I made it build and run on FreeBSD 11 2 days ago. Still need to fix some scripts and I will try to submit it to the ports tree
> Even then, I still used some of the FreeBSD Handbook to learn Linux, because Debian didn’t have the great Reference that it does now.
At work, we are pretty much a Windows shop, and I am often frustrated by the state of Microsoft's documentation. Some parts, say, .Net API reference, are pretty good. Reference material for SQL Server is quite good, too (and I will am very grateful for that, because I have to deal with SQL Server a lot).
But in other parts, documentation is crappy or non-existant (I am looking at you, SharePoint!) to such a degree that sometimes I wonder if they do this on purpose to generate business for the hordes of consultants and authors to write books (although all the SharePoint books I have looked at, sucked, too - the only helpful search results tend to be the blogs of SharePoint consultants, those poor souls).
And when people tell me to stop ranting because that is just the way things are, I tell them to look at the FreeBSD Handbook. Or the OpenBSD documentation. If these projects that are largely volunteer-driven are able to supply such excellent documentation, why can't Microsoft?
Okay, enough with the ranting, let me close on a more positive note: I run my home server on FreeBSD, mostly because of ZFS, but I have come to appreciate jails and bhyve, too. I love it, because it has not given me any trouble. It was straightforward to install and set up, and once it was working the way I wanted it to, it just kept going. (I check for updates regularly, of course, but that does not take much time, and I would have to do that on any other OS, too.)