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)
"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...
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.
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.
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.
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.
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.
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).
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
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.
> 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.
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.
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.
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".
> 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.
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.
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.
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.
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.)
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.
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)
> 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.
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.
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.
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.
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).
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.
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.
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.
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.
> 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.
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.
SmartOS isn't really for workstations, unless your workstation doesn't need a GUI (mine does). That said, I'm about to create a blog post and youtube video on how to run SmartOS at home for real cheap (as in cheap hardware and electricity)
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.
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.
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.
"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’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...
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.
"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 ...
> 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.)
> 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
> 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.
> 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.
"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. ;-)
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.
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.
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.
"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.
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.
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 :)
It's written in Go so no httpd is needed (IIRC Nextcloud and Owncloud are in PHP so would require an httpd to run), and it has an Android (and probably an iOS) app. I do use it, it's nice, tho I'd appreciate better documentation.
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.
128 comments
[ 2.7 ms ] story [ 143 ms ] threadSo 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 ?
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.
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.
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.
I've not had any issues with my XPS 13 on it.
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.
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 world has changed from the times of the EeePC.
"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.
> 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.
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
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.
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)
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.
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.
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.
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.
Of course, that's the point: the GNU tools undergo relatively active development and grow better while the BSD tools don't.
(The point of my argument is: this is not an insurmountable problem.)
1. After properly setting it up, do sporadic updates when necessary without worrying that the whole thing falls appart.
Much better than Linux ;)
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.
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.
(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)
* http://uselessd.darknedgy.net/ProSystemdAntiSystemd/
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.
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.
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.
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.
We've got a blog detailing a lot of our work here: https://medium.com/netflix-techblog/serving-100-gbps-from-an...
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).
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".
Amen to that!
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.
https://bugs.launchpad.net/qemu/
Since you encountered it and I don't yet have AMD hardware to test, would you mind reporting it?
(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).
> open since 2016
Which is it?
http://zfsonlinux.org https://wiki.archlinux.org/index.php/ZFS
SmartOS is so simple to use.
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.
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.
Underrated.
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
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.
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.
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...
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.
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.
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 ...
Try using the e1000 network adapter emulation - Win10/Server 2016 work fine with this.
> 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.)
Very likely. See: Oracle.
It's ironic that money can make a product worse.
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.
> 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.
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. ;-)
Personally, I've got a partition with exFAT so I can transfer data between everything on my drives...
For small drives e.g. USB sticks ExFAT is great but for larger drives I'd stay away from ExFAT.
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.
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'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.