I am using freebsd since version 8 for all my server needs (was using linux, but got repelled by its chaos which I dont care about on my laptop, but it pisses me off on server).
Some more points:
- bhyve, developed by netapp, they ditched all old technologies support and it works faster on my i5 server than kvm on my i7 laptop. Snapshoting using ZFS is not a feature to discard either.
- FIBs, absolute miracle routing tables that you can apply to whatever software, define the routes as fib 1 (lets say it is openvpn) and then use them as simply as `setfib 1 bash` to use them in all child processes
- backward compatibility, this is where linux is really horrible, there was an article about compiling binary on freebsd 2 and running it on freebsd 10. Try this on linux, binaries are not compatible even on minor versions.
- jails... docker? Really? Jails are 15+ years old implementation, kernel supported, that stood test of time, actually being a security feature. It runs circles around the docker in everything except how much it was adapted by community. I never understood why people rather used an inferior solution like docker.
- not to mention all the chaos in linux ecosystem, in next sub-version, the commands can have completely different switches,...
I will never understand on what technical merits people are using linux for servers except the support-ability of hardware. Due to the whole show that linux is getting we would prosper as a humanity by ditching the linux. Unfortunately, marketing is worth more than anything.
(I do understand that people will not agree due to their preference, but try to use it. I doubt you will prefer linux ever again.)
From a technological perspective, everything you say is true, and FreeBSD is better in so many regards. But, compatibility and community support is just a deal breaker.
The jails vs docker argument is a good example: while technically better, Docker (or rather, cgroups and image distribution) have been standardised and have tremendous community adoption. FreeBSD cannot tap into any of this at all. Yes, jails might be better, but because they lack widespread adoption, they’re far less useful.
It’s a sad state of affairs, I wish things went otherwise, but I feel Linux is sometimes a good example of the “worse is better” approach at work.
I think one of the biggest mistakes the FreeBSD team made(in terms of more widestream adoption) was abandoning the Linux syscall table layer. It's still there, but it's stuck on 2.6.x last time I looked. It's a lot to maintain, yes, but it would help secure a lot more users like me, who are highly technical, potential contributors, who like a lot of the features(jails, better ZFS integration, easy to set up dtrace support etc), but also like to play around with bleeding edge software that tends to support Linux/OS X first, and maybe BSDs by accident, if you're lucky.
I think keeping this layer in development, maybe having a similar setup to SmartOS, letting you set up "Linux jails" or something like that, would significantly help adoption in the desktop/workstation space. This would of course lead to recruiting more developers, and so on.
Drivers are trickier, but I actually never had driver issues the last time I used FreeBSD as a daily driver(for about 6 months a few years ago, until I ran back to Linux with my tail between my legs).
It would be nice if at some point many decades ago, the Unix world had agreed on a standardised kernel API for modular drivers, so that drivers could more easily be ported between kernels, but it's way too late for that at this point I guess.
And maybe not even technically feasible, but I'm not qualified to comment on that.
This is exactly the kind of gatekeeping that holds FreeBSD back. Users asking about missing features being snarkily put down with things like "go use Linux then, we're doing just fine without feature X". This kind of toxic attitude is what pushed me away from FreeBSD in the end. They're so childish about constructive criticism sometimes, it's downright embarassing considering these are supposedly adults.
Edit: It's come to my attention that this particular instance of gatekeeping came from the Linux camp, not FreeBSD. Though you can find it in the FreeBSD community too, to be sure.
It isn't gatekeeping to point out that maintaining Linux syscall compatibility is impractical, especially citing the fact that Microsoft tried and gave up after sinking tons of resources into it; and FreeBSD has also already tried and gave up as you pointed out yourself.
I'm not sure how relevant Microsoft is here given how much more different from Linux NT should be compared to FreeBSD. It's also kind of a different calculus for Microsoft in terms of it being worth the effort for what they wanted to do with it. Microsoft already has its own thriving ecosystem, the Linux support is just a bonus to attract people from a niche market. For FreeBSD the situation is more or less the exact opposite. The SmartOS people did it too, and even ported over KVM. But Joyent was acquired by Samsung and I'm not sure what happened to SmartOS after that.
MNX acquired[1] SmartOS (and Triton DataCenter) earlier this year from Samsung. We're continuing development and have continued with a bi-weekly release cycle.
You didn't really explain anything. You waved your hands a bunch. You didn't address the fact that FreeBSD already accomplished this, then stopped maintaining it, you conveniently ignored the fact that Illumos had it even later than FreeBSD, mostly from scratch. Your tone was overly dismissive. Now you start calling me names. Grow up. I'm sorry I misunderstood your point of view, but you did sound exactly like certain FreeBSD community gatekeepers, and you're responding to a post about FreeBSD project decisions, so is it really so strange or "idiotic"?
Awesome! Looks like they've picked up speed with it, that's great to see. Not sure if the abandonment was originally a misperception on my part or whether they picked it up again, maybe pulling code in from SmartOS? Either way the wiki says compatibility is up to 4.4 on CURRENT and 3.2 on STABLE. Still a ways to go, but that's sounding like I might have to give FreeBSD a go again!
Yeah, thanks to Dmitry returning to work on it, and FreeBSD Foundation sponsoring me, and other developers stepping in to fix something that annoyed them, and Alex tracking down Steam situation and doing epic work on tracking FreeBSD bugs and Linux idiosyncrasies.
Note that the reported kernel version doesn’t mean much, and we could probably bump it to 5. What matters is individual syscalls, and a nice thing about the state of Linux is that because it’s so fragmented, almost every non-portable syscall has a portable fallback.
NVIDIA is the only GPU vendor who makes device drivers for FreeBSD, not only for Linux, so their GPUs work better than the others on FreeBSD.
Unfortunately the FreeBSD NVIDIA driver does not include CUDA.
It might be possible to use CUDA in a Linux VM with GPU pass-through, but I have not tried this.
FreeBSD has good driver support for many server-oriented devices, e.g. for many network cards, especially for those from Intel, and for many SCSI controllers. The support for magnetic tapes is also better than in Linux.
There are various random devices that may have good support, e.g. recording from a Logitech video camera worked much better for me on FreeBSD than on Linux, but in general the chances of not finding a device driver for some piece of hardware are much greater than on Linux, especially when that hardware is new.
No idea, never needed it. At some point I decided I had no use for dedicated GPUs that justified dicking around with atrocious driver blobs. That might change in the future if I get more into ML though.
I get that, mostly I use them for dsp for software defined radios. The drivers for those are probably hard to compile as well. Depedencies on libusb often. Or dpdk for the nice ones.
Btw, dunno much about software defined radios and such but I'm curious. Isn't this the kind of niche FPGAs are perfect for? Or do they not justify their cost in your use case?
Purchase price yes, development costs less so. Maybe I'm just bad at verilog but it takes me a lot longer to do the same thing compared to cuda or c++. Also the devtools are a big pain, and nothing is performance portable across device brands. Or even device classes. But yes, for high rate simple-ish dsp, fpga is awesome for performance and performance per watt.
Nobody ever adopts it because nobody wants to support it, ergo nobody ever adopts it and nothing ever improves. Gotta love this little cycle of mediocrity the software world has going on.
This type of circular argument sometimes hit a nerve when it about a thing cares about, but lets remember that the literal sense of "mediocre" is "middle" or "average", so its kind of a tautology to say that in general, software is average.
It takes true nerds (or "geek" in the sense it had around 2000, when it was still a bit derogatory and not yet a fashionable identity marker) to go off the beaten path.
Guess I mispoke, if everyone adopted it, then that quality of software would become the new average. this software is just inferior, which in software usually means that its harmful.
Adj. 1. mediocre - moderate to inferior in quality; "they improved the quality from mediocre to above average"
> Docker (or rather, cgroups and image distribution) have been standardised
Cgroups, namespaces have been implemented once, in Linux, by Google for their own needs. Not standardized in any meaningful interpretation of that word, just like "web standards" aren't. With now a generation of developers raised by big media and fake grassroots and staged march of progress stories, I'm wondering if that generation will be able to tell the difference, or are invested too much already.
Yeah, you’re right of course; my point was more that somehow we ended up with a “standard” format to store and distribute images, have plethora of tools that are able to run it, but they’re all using the same kernel fundamentals (cgroups).
But all that would be a distraction from the point I was trying to make, so I simplified it a bit.
What you're meaning is that "we" have converged on tech dominated by big cloud vendors. A standard, OTOH, is something implemented by more than a single party. Unix (POSIX) used to be standardized in that way. Portability, sustainability, and avoiding dominance by a single party was always the point of Unix; as on OS, Unix wasn't particularly innovative but merely good enough and compact, even when it was new.
Then what are foundations like CNCF (https://www.cncf.io/) doing? I'm asking honestly, if there's any difference between CNCF and any other standards governing body.
Your comment implies the old trop that Beta was much better quality than VHS, but Betamax's reputation for better quality was marketing spin and conflation with Betacam, Sony's pro version.
In reality, Betamax was nearly indistinguishable from VHS.
Obviously it’s been quite a long time, but as someone whose first VCR was beta, this rings true. If nothing else, I definitely don’t remember a noticeable quality difference when we later switched to VHS.
> backward compatibility, this is where linux is really horrible, there was an article about compiling binary on freebsd 2 and running it on freebsd 10. Try this on linux, binaries are not compatible even on minor versions.
Linux userspace is considered unstable. It's not a cohesive system like the BSDs but lots of independent projects all doing their own thing.
The Linux kernel is capable of running binaries compiled in the 90s. Breaking changes in the kernel-userspace binary interface makes Linus Torvalds scream at people on the mailing list.
I even say that instability of the Linux desktop was a considerable contributor to the decline of Linux powered workstations.
People were getting used to the old reliable Gnome2 and the Windows-esque KDE desktop.
But there's always some team of developers thinking they are Apple and completely throw years of progress out the window by breaking compatibility because of some usability "feature" their own selfish conception of usability thinks is a good decision.
Some of then even go to the point of rejecting Merge requests to their supposed open source software because of that kind of Whim
But why does the world always go along with it? In an alternate universe, the community just said "yeah, no thanks, I'll keep using Gnome 2", which they continued maintaining under the name Elf or whatever.
They did! MATE is fairly popular, but as to why it happens I think it's about people.
There are only so many people willing (and able) to do the often difficult and unglamorous programming work that goes into maintaining something like Gnome.
If you're working on a major distro you have a certain level of trust in Gnome 3 because the same people delivered and supported Gnome 2. I'm sure when Gnome 3's direction became clear dozens or hundreds said "no way! I'm going to start my own fork which will never change!"
The sad part is that Gnome 2 had a whole ecosystem of third party software that integrated with it. Just a few of that got ported over to Mate (usually just s/GNOME/MATE/g) but it never gained the same traction.
I think that's where the fracturing comes in. For whatever reason, distros will ship with the new thing. The past 2 or 3 places I've worked adopted MATE (a continuation of GNOME 2). And, of course, there was instability at these places in figuring out which direction to go.
For many years I was using gnome shell. Every update meant broken extentions. The system would also crash occasionally after few days on a multi-head setup. Then I switched to a hybrid of Sway and KDE and have been never so happy.
I wouldn't say "instability" as much as lack of focus
Especially as with some evolution it seems it's always a mix of people complaining new change means some X program made in the 70s will break and people who wants to redo something made in the last 6mo because it is "old" already and meet the newfangled thing which is 50% breaking changes 50% barely new things
I would say instability. Linux kernel will straight up revert improvements if it turns out they broke user space. Meanwhile in user space even glibc has broken binary compatibility before, GNOME breaks compatibility with user extensions...
> It runs circles around the docker in everything except how much it was adapted by community.
...except?
Meh. People who want to engage in this argument are generally trying to argue about jails vs. the collection of linux container technologies. That's not Docker. Docker won because of Dockerfiles. Docker isn't, at its core, an interesting container technology. Docker is a simple metaphor and programming environment to leverage container technology to solve practical[1] problems.
And as it happened, it was done on Linux and not jails, owing in large part to the more configurable/toolkit-style/policy-free tools available there. Jails were indeed more mature, but they were solving the wrong problem.
[1] Also thorny, boring problems like configuration management of large apps developed piecewise from components and by large teams. The kind of thing that is historically not well served by the operating system, BSD included.
> Dockerfiles make it super simple. There is similar stuff for jails but you need a jails frontend that use it.
But docker is just a frontend for linux containers :) You're not comparing the right things here: Linux containers with a popular frontend and all the trimmings, to barebones FreeBSD jails.
> If you want containers, [...] is all you really need.
And that is the attitude embraced by jails (to be clear: rather more cleanly and attractively than the expression of the same ideas in linux), and precisely why it lost.
No one wants "containers". They want docker. They want to be handed something that looks no more threatening than a mid-80's build script and have it magically be it's own little world with all its own software and versions and stuff, but still talk to the rest of the world on the same networks from the same piece of hardware (yes, via some weird voodoo to glue all that together).
It's like arguing that no one needs word processing because nroff or LaTeX is all you need. It's not wrong. It's just a failure in the market.
The voodoo is what bothers me. As the person responsible for the server, when things go wrong I will get blamed. In that situation, I at least want it to be my fault.
Stock docker puts entries in your iptables which usually fully bypasses your firewall. try installing docker on stock Ubuntu, run a container with an exposed port, put ifw up blocking all traffic, and the container is still going to be reachable.
> Have you ever looked at what Docker puts in your iptables?
Some forwarding rules.
> I challenge you to understand what's happening with your networking after that.
They're incredibly simple forwarding rules, to make sure that only the containers that you specify can connect to the Internet, and all the others in a particular group can only connect to each other.
> If you want containers, lxc command line and a bit of configuration for a bridge interface is all you really need.
Yes, assuming you never need to maintain it, or run more than one project per server.
Remember, you're comparing Linux and FreeBSD in 2022 but BSD lost to Linux much earlier, many years ago. Back when I was looking into them (long time ago, excuse me for not remembering the details), BSD felt more pleasant and coherent. But at the same time it had limitations on scalability, performance and compatibility with hardware and also with userland software. In every benchmark, especially on multi-core, multi-socket systems, Linux was ahead.
My theory at the time was this: GNOME won on developers' desktops, so most software was developed on Linux natively, with BSD compatibility (and performance) as an afterthought. IIRC Linus made a similar point on the mailing list that developers love servers that resemble their programming environments. TDLR: BSDs got stuck in CLI-only mode for too long.
The more common explanation was that Linux got a head start by a few years by being a clean-sheet implementation, while the BSD had to spend its early years purging itself off the AT&T copyrighted code, so it was untouchable from a commercial use perspective.
I remember why I chose linux in 1998 for my desktop, and would choose for my server.
Hardware compatibility. I could install Linux on my shabby work desktop, and it just worked. Actually it worked more stably than NT 4.
Binary distros. I could apt-get install stuff onto my box in minutes. I rarely had to build things from source.
Speed of change. Linux was acquiring features at a breakneck speed. Large companies started contributing. SMP, interesting networking stuff, better disk I/O, new filesystems, stuff like that. Hell, Windows emulation good enough to run StarCraft! It felt alive and cared for. It was apparent that many serious businesses want to bet big on Linux. Some say marketing; I say GPL and project guidance.
I also had a lovely server box with FreeBSD. It had select compatible hardware. It had really nice documentation. It ran Apache and Squid pretty well. I had to build the latter from source IIRC. I had to build a lot from source (slow in 1998). If that was not available as a buildable package, I often had to tweak header files to make it build. For many amenities which I took for granted on my linux box, I decided that it's too much hassle to make them built on BSD.
Features like SMP or journaling file systems were a bit late in FreeBSD. Maybe they were more solid, and achieved performance parity with Linux with time. Sadly, the industry largely made the choice.
I also find modern Linux a mess, and run a minimalist distro (Void) on my laptop. I could consider running BSD on a server, but most servers now have to run VMs and containers within them, most tooling just assumes Linux.
> I remember why I chose linux in 1998 for my desktop, and would choose for my server.
>
> Features like SMP or journaling file systems were a bit late in FreeBSD
Yep, it was timing for me - the Asus BP6 allowed dual Celerons but only Windows 2000 and Linux 2.6 supported SMP. I was using FreeBSD at the time, but had to move because of hardware support.
But I wouldn't say it was hardware support alone - I think GNU/Linux won because of the licensing - FreeBSD not having a viral license would have turned people off contributing only to have their code distributed closed source by companies... that's my take anyway.
We're far from the days of getting a free Redhat CD in a book, just popping it in a drive and restarting to have it start a Linux install. You're lucky now if you don't have to enable USB booting, register a hash/key, turn on a 3rd party cert or just turn turn off secure boot to get a USB drive to boot.
"With Linux, I just booted from a Linux boot floppy with my Linux install CD in the CD-ROM drive, and ran the installation. With BSD...it could not find the drive because I had an IDE CD-ROM and it only supported SCSI."
"It insisted on being given a disk upon which it could completely repartition. [...] Linux, on the other hand, was happy to come second after my existing DOS/Windows."
"By the time the BSD people realized they really should be supporting IDE CD-ROM and get along with prior DOS/Windows on the same disk, Linux was way ahead."
IDE was one of many hardware issues that just took too long to be solved. For a long time, BSDs didn't seriously try to support consumer-grade hardware - be it because of lack of manpower, conservative attitudes, or "commercial" choices. OpenBSD still doesn't support Bluetooth...
On the other side, the Linux community fought hard to get everything to work, creating positive loops: the more hardware it supported, the more people could get it to work on their hobby hardware, the more they'd become familiar with it and push for adoption at work.
Exactly, "commercial" choice. Any OS that wants to support consumer-grade hardware, in 2022, must provide Bluetooth; OpenBSD just doesn't care enough about the consumer market to do that.
I have to get an outlet for my masochism tendencies somehow, at least this doesn't leave scars - physical ones, that is.
I have to say though, my insistent trolling of the project on forums like these occasionally contributes to the push to progress - like the long-requested syspatch. I'm not sure what yours achieves.
Not sure what you could mean by “lost”, when BSD family operating systems are so widely adopted. I have more devices at home running such than I do Linux, not even counting Apple’s Mach hybrid. My internet traffic passes through more BSD-based than Linux-based devices as it crosses the globe, and my data resides on a variety of platforms that include both (and more besides).
These systems aren’t busy trumpeting their presence. Maybe the originators just don’t have fragile egos.
> My theory at the time was this: GNOME won on developers' desktops, so most software was developed on Linux natively, with BSD compatibility (and performance) as an afterthought.
when i tried FreeBSD a couple years ago i was actually surprised that gnome worked OOTB. i remember some of the settings were gated off (Bluetooth? can’t remember the specifics), but the base desktop worked exactly as before.
maybe different in the early days though: dunno, wasn’t there.
> jails... docker? Really? Jails are 15+ years old implementation, kernel supported, that stood test of time, actually being a security feature. It runs circles around the docker in everything except how much it was adapted by community. I never understood why people rather used an inferior solution like docker.
Docker has Dockerfiles, layers, and trivial push/pull of images. Compared to those workflow improvements, nobody cares if the guts suck.
> Compared to those workflow improvements, nobody cares if the guts suck.
Some people care, this is why FreeBSD is still around :)
And it's not really relevant if you build your own images anyway. And in fact within the scope of FreeBSD jails offer very similar features, one of the things that's very common to do is make a base image with ZFS and then base all your jails off it. This means you just have to update your base and all your jails are updated. It's similar to pulling the latest alpine with docker. If you embrace the full ecosystem with Bastille you will have very similar capabilities.
The big missing point is that you can't use images from docker hub. This is a big negative but if you already don't plan on using those it's not really a bad thing. And there is increasing resistance to pulling things made by unknown people into production (I'm sure many vulnerabilities will happen in the future as attackers start to take advantage of this).
But anyway it doesn't have to be for everyone. It doesn't have to be the biggest thing around.
I would like to be on the jails train, but the build/deployment story always felt inferior.
I have never seen anyone build jail-images from CI and deploying them to fleets of FreeBSD hosts. This may be technically feasible with zfs send/recieve but in practice people I know distributed packages (not images) to 10s of FreeBSD jails/hosts.
I want to deploy container images to a cluster - not install a package in a zone/jail. Is anyone doing this with FreeBSD/Solaris? (Outside of Joyent)
- I can see the Dockerfile equivalent (Bastillefile).
- Not sure about the image distribution (Docker repositories) and Cluster management parts (Mesos, K8S)
Having used BSD many years ago on desktop, I completely disagree. What are you using your computer for using BSD? I really don't spend 99% of my time just compiling lol
The chaos thing is something I hear from BSD users quite a lot. I'm still not sure what it is means, maybe that's some sort of personal issue..? I suppose you don't like forking and variation, which is understandable coming from a user of an OS with a fantastically small userbase that somehow still manages to be proportionally more fragmented than any other community I can think of, but the "chaos" of Linux is grossly overstated. Most everything that is relevant today runs Debian, unless you're a poweruser running Arch or even Gentoo, but even then, who's out there being a distro purist? I'm willing to bet that most people running Arch or Gentoo are still using quite a bit of 'Debian resources'/assets.
Sure, there's RedHat too and all the others that fill some corporate niche, but there really isn't this whole divide within the Linux community like people sometimes imply. I think a lot of people are stuck in a mindset that hasn't been relevant for somewhere between 10 and 20 years.
I can’t speak for everyone, but one of the reasons I use Arch is precisely because Debian doesn’t have as many resources/assets as Arch.
AUR may not be perfect but there is very little software out there that someone hasn’t already packaged in it and it’s a great deal more convenient to use than faffing with custom repos.
The Arch Wiki is second to none too. I’ve even occasionally found myself using it when debugging other Linuxes.
I definitely wouldn’t use Arch on a server though. I mean, I have done, multiple times in fact, but they’ve always been personal systems. I much prefer FreeBSD for servers. Professionally it has usually been Debian, CentOS, or, much more recently, Ubuntu Server (but I really don’t like Ubuntu Server. Or Desktop for that matter).
Disclaimer: this is all my own opinion and I’m not trying to pass any of it off as fact.
Interesting. I suppose I also just use very mainstream software as well. I find that basically everything I need is either made for dpkg or exists within Ubuntu repositories (they've got literally everything there, haven't they!).
I agree in your overall assessment though, I can concede to the fact that I might be underselling the value of Arch within the broader Linux community. I've often seen Arch as the detrimental opposite however, which is quite ironic. Personally I just find Debian distros superior to most others (except Linux Mint.I hate Mint, more than anything). I do quite fancy Ubuntu as dekstop, but you truly are right that it is at the very least, not a very good server distro. It might be the worst, imo, Debian server distro.
My go-to choice for a Debian alternative is Fedora, however, so our different experiences might also be a testament to a fundamentally different view on Linux and how you do your computing.
> I'm willing to bet that most people running Arch or Gentoo are still using quite a bit of 'Debian resources'/assets.
More like the reverse, the Arch Wiki is the best so everyone uses it. Although for some topics it makes sense to take a look at Debian or Gentoo wikis, too.
Not sure what other kind of 'Debian resources'/assets you had in mind.
Whilst I don't at all doubt your testimonies, I am still sitting here wondering what programs everyone here is using, if not programs usually tailored for Debian. I feel like I've seen more software that runs natively on Debian (Ubuntu, really) and made specifically for dpkg.
But I suppose a lot of applications also come with "snap" these days, but I avoid "software stores" like the plague.
I personally have had very little contact with Arch, but I realise that is me that is strange, I personally dislike Arch very much and can recognise that, that might be the reason I don't see it around as much; a negative confirmation bias of sorts, if you will.
99% of the time when I have an issue and I just google it, I'll end up on the Ubuntu forum, that's no lie. But I do seem to remember using the Arch wiki years ago. I'll admit, I'm probably just a diehard fan of Debian.
You do know about package managers and software packages, right? Debian has its own packagers, and so does Arch, there's nothing in common between Debian and Arch packaging (except for certain elements of the philosophy, etc).
What do you mean by "programs usually tailored for Debian", in general Linux programs for sure won't be tailored for Debian, except for Debian-internal developer tools perhaps.
I use Arch almost exclusively on the desktop but I gave up on running it on servers that I don't want to actively maintain (think of small, non-critical web servers). Ubuntu works fine there.
Some of this may be true, though I have some disagreements about the accuracy of some (and also the issue that "Linux" is a broad target and some of these apply more or less to different distributions or os'), but freebsd definitely had its share if chaos in its history. The fbsd4-6 era was a difficult one to navigate and it's basically where I feel off the freebsd bandwagon.
ZFS wasn’t just new when FreeBSD 6 was released, ZFS wasn’t even released itself. :P
FreeBSD 7 was the first release to support ZFS and even in that it was marked as experimental support.
So if you were using ZFS before FreeBSD 8, and especially somehow on 6 and below, then you’re very much using ZFS at your own risk and can’t really complain if things go sideways.
> backward compatibility, this is where linux is really horrible, there was an article about compiling binary on freebsd 2 and running it on freebsd 10. Try this on linux, binaries are not compatible even on minor versions.
What a completely bizarre claim. I have commercial linux/x86 binaries from the 90s that work perfectly well on my current PC running Linux 5.15.
I’m guessing the OP meant “where glibc is really horrible”, since bsd libc is rather more abi stable, largely because that’s where FreeBSD provides compatibility instead of the syscall layer. This is not to say you can’t use an old libc and fix up the loader paths or use a container and make it work, but it’s a different set of challenges.
I am not sure about other BSDs, but at least OpenBSDs is all but abi-stable; when they wanted to introduce 64-bit time_t to fix Y2038, they just changed the typedef and declared a flag day.
I had trouble trying to run libc5 era software a few years ago. This wasn't the kernel but the distro did not make it easy. I wouldn't expect them to keep maintaining libc5 packages 20+ years later either.
I think if you do anything GUI-ish over the last 20 years there's been many shared library breaking changes. But that'd be true of FreeBSD too since those dependencies are just the same when they live in ports.
I use Linux all day long and none of this is an issue for me, so I guess that's the counterpoint. I'm just a desktop/server user/developer though and not a guru by any stretch.
That is true[^1]. Doesn't say much the two TCP stacks in 2022 though.
Netflix has built expertise around FreeBSD for years. Not just TCP stack optimisations. There's deployment, management, maintenance, etc. I don't expect them to jump ship easily, especially if the tool is good for the job - which obviously is.
However, even they reckon that FreeBSD _might_ be faster for _a specific_ workflow. Fifteen years ago there would be no comparison between the two in terms of top speed achieved on same hardware or latency, FreeBSD was far superior.
The trend is what's important here. Netflix choose FreeBSD in 2012, in 2022 it is certain that they would have gone with Linux and by 2032 my guess is that they'll be serving using Linux. I hope I'm wrong, the more the merrier.
agreed !
Also i think throughput might be moving/dynamic values ?
i.e this year Lamborghini might be faster than a Ferrari... Next year they might swap. But no one will say Lamborghini or Ferrari are slow.
My humble point,unless absolute throughput (Then you looking at userland tcp-stack anyway) is your absolute goal. Things like tools,skillset, environment, community might play a bigger role. Yea i still love Freebsd but uses Linux on Desktop daily. Freebsd just kinda 'fits-in-your-head'
Linux: I miss the simple days when you could edit files like /etc/resolv.conf for nameservers :)
These days i see quite a few "don't edit this file manually it is auto-generated messages" :/
> ...don't edit this file manually it is auto-generated ...
I have been trying not to comment on any of this discussion, but You just hit a nerve for me (in a good way!).
resolv.conf: near and dear to my heart
Don't edit manually...: if it is cattle (most servers and IoT) - ok, I move on. If it is a pet (any of my main laptops), whoa. Stop what I'm doing and track down the software that did this. Purge it or re-write the offending code to not mess with stuff. Track down what was relying on this behaviour and purge. Rinse, repeat.
FWIW, I am running Slackware, OpenBSD, and sometimes FreeBSD on my pets (they are all installed it's just that I mostly live in the first two). Also, I find it hard to not have all the different man pages always available (no, I don't have a constant Internet connection - Security policies).
Your point about Jails vs Containers (popularized by Docker) is a naive rose-tinted glasses view. Jails is aimed at security and stops at that. To create something like docker-compose or Kubernetes with Jails is nigh impossible.
This "complete software stack" deliverables is what makes the difference today. You deliver software with greater ease.
Jails isn't meant for that. Ignoring this point and claiming the same existed for 15 years is wrong.
> in next sub-version, the commands can have completely different switches
That claim seems crazy and doesn't match my experience at all. Please name a widely used program that changed its switches completely in a sub-version.
Do you mean displaying quotes in the output? That has been around for years (by default on many distributions) and doesn't answer my question at all. Please name a widely used program that changed its switches completely in a sub-version.
Honest question here about jails. I like docker because the tooling makes it super easy to get anything running in no time. How is jails tooling? Let’s say I need to get an app running, a database and a redis for the app. Is that as easy as docker compose?
I've run into fun issues like FreeBSDs slab allocator not playing nicely with the ZFS/NFS workload on one specific server and having to drop down to having ZFS allocate memory in a different way that used about twices as much CPU to avoid random multi-second pauses on the whole system. Also had issues where kerberized NFS would get confused and something would crash so had to have random cron jobs to restart dying components, since FreeBSDs init system is so simple. Also arbitrary and short name length limits, I think in both bhyve in the past (couldn't use fqdns for VM names since that would have exceeded the limit) and something about zfs mountpoints ages ago (I think we ended up changing our naming and nested conventions to work around)
Thanks. I still see multi-second pauses moving data over Samba to an encrypted ZFS pool. I’m using a 10Gbps network card, so the drives are the bottleneck (or so I thought, until seeing these delays).
I use Linux as my main OS. I’d love to switch to FreeBSD but I can’t.
Most software that run on Linux may or may not run on FreeBSD. And when it doesn’t, it’s typically hard or impossible to get instructions or community support.
Looking at the download page, Firefox doesn’t even seem to have a FreeBSD version or instructions.
I can understand for servers although you lose community support for most software and can’t use ready to deploy docker images, as much as I loathe docker.
FreeBSD is vastly superior to Linux IMHO (the handbook is a great read), but it’s unfortunately not practical for most usages.
You can do FIBs with Linux network namespaces, can't you? `setfib` would be `ip netns exec`
Aside: the thing that annoys me the most about FreeBSD is how bitter its proponents are that Linux "won". The tone of your comment a great example. It seriously turns me off. Some humility in finding out the shortcomings of BSD and ironing them out would be more beneficial in creating more competition in the OS space than complaining that all Linux users are idiots that haven't seen the light.
> I will never understand on what technical merits people are using linux for servers except the support-ability of hardware.
System upgrades are cleaner in Linux. Debian has had pkgbase ever since I can remember and it’s still underway in the BSDs. Live kernel patching is nice, too. Just two examples.
With Linux today I can mostly use the terminal just for what is best done on the command line. With FreeBSD I always feel like I'm digging through the filesystem and terminal to get basic OS stuff done.
Don’t forget the docs are actual documentation. Like it is an actual coherent operating system with actual documentation. No “refer to info docs” here. Actual docs. Real ones.
As someone who has just been tearing my hair out over v1 and v2 cgroups and containers for testing systemd services, I think I need to spend some time in FreeBSD land.
bhyve (a lightweight virtualization tech) vs kvm (really kvm/qemu) isn't really a like for like fight. If your looking for something lightweight on the linux side you would go with Firecracker (AWS developed for Lambda and Fargate).
Not necessarily; if a VM is properly configured userspace is out of the way as much as possible and performance is dictated almost entirely by the processor and the hypervisor, not by QEMU vs. Firecracker.
Jails was actually committed to the source tree in 1999… so almost 25 years. You should read phk’s article - Jails: Confining the omnipotent root. It’s very good.
jails and lxc are great but Docker won out because they made those features significantly more user friendly and spent serious (VC-supported) coin on marketing that.
I have tried learning FreeBSD occasionally, mostly for nostalgia because I learned Unix on BSD 4.3 (or 4.4?) on MicroVaxes many years ago. But I get stuck on some very basic things:
- My wifi card doesn't work. The installer recognizes it, but the driver doesn't work.
- The console terminal defaults to 80x25, I don't know how to resize it.
- I can't figure out how to start X Windows.
- If I run it in a VM (e.g. VirtualBox), the network bridging doesn't work so my FreeBSD instance has no internet access.
It's probably my fault, I'm sure it's in the docs somewhere. But it probably means that I'm not the target audience for FreeBSD, since I don't have the time and patience to figure out the most basic things.
> - My wifi card doesn't work. The installer recognizes it, but the driver doesn't work.
It really depends on your Wi-fi card. If you're installing FreeBSD on bare metal with an Intel card, iwx now supports Wifi 6 and 6E cards. Although, since I haven't tested it myself, I can't say it will work as expected if it works at all.
> - The console terminal defaults to 80x25, I don't know how to resize it.
Select console terminal at the boot screen and type the following:
gop list
gop set {mode number}
and then reboot the VM
> - I can't figure out how to start X Windows.
Assuming you've installed the appropriate graphics driver from the pkg or ports repo:
pkg install xorg
startx
If you don't have the appropriate graphics driver, proceed to step 8 in the webpage below.
> - If I run it in a VM (e.g. VirtualBox), the network bridging doesn't work so my FreeBSD instance has no internet access.
If you're interested in trying out BSD on the desktop vs in a server or through some other BSD-based appliance distro (projects like OPNsense or TrueNAS Core which build on BSD but are mostly intended to be used from a Web GUI) you could take a look at GhostBSD [0]. It's a vastly more polished and desktop focused project that takes off many of the sharp edges of a plain vanilla FreeBSD install. Of course, "more polished" for BSD is still going to be a ways behind Linux these days. There just isn't the same level of hardware support, eyeballs and companies working on it. But it's not 00s era either, it's a pleasant functional experience. If one wants to test the waters a bit in an easier way it's an option worth considering. Ars did a decent little initial experience run through [1] a few years back (though since it is under active development a lot has changed since then) you could check out if interested. As demoed there it's very viable in a light VM so one doesn't even need to dedicate any hardware for a first try. That review also lists some of the other more GUI focused BSD distributions left out there.
Anyway, there are some options to ease into it more. I find some of the ancient FreeBSD-isms a bit grating on occasion but overall I'm glad it's part of the mix.
FreeBSD, OpenBSD and NetBSD are for servers, appliance servers and embedded devices mostly. You can use them as a desktop, but that's not where their strengths are. If you want to learn or use FreeBSD in this case I strongly suggest setting up a home server and learn as much as possible.
I've used OpenBSD as my desktop OS for the last 10 years or so. I agree it's probably not the ideal desktop OS for everyone, but I think your dismissal may be a bit too strong.
You do need to be sure your desktop machine is well-suited for OpenBSD. This means supported Intel or AMD graphics (Nvidia won't work well if at all, and not all AMD will either) and network/wifi card.
If the user has run of the mill hardware, that only is true in the sense that FreeBSD does not offer to install a desktop environment at time of initial install/setup. Nothing precludes you from installing Gnome, KDE, or any of the many others. IE pkg install gnome.
The only place FreeBSD (or any of the other BSDs) is less robust is driver support, though most common stuff is available. In any event, those needing support for the latest greatest of hardware are probably better of with Windows.
Yet… “On FreeBSD you'll notice right away that you're dealing with a "complete operating system", a system that has been put together very well.” It’s a complete operating system. /s
This is why FreeBSD loses in my view. The arrogance of claiming to be a complete system when basic stuff like wifi doesn’t work.
Having written a wifi driver, that’s something I’m comfortable stating unequivocally.
The hardware is almost always proprietary and undocumented, and in many cases (looking at you, Broadcom), a poorly-designed shitshow of complex errata, proprietary magic numbers required for initialization, and in general, an absolute dogshit technology stack.
The only reason Linux has working Wi-Fi at all tends to be because it was used to power a lot of cheap consumer access points, and Wi-Fi chipset manufacturers released binary and open-source Linux drivers — generally of horrific quality, but drivers nonetheless.
No, it "works" in that it's 2.4ghz. That is not what most people would expect from speed at this point.
It will "work" correctly when it supports general consumer expectations e.g 5ghz networks, which has been a common complaint about FreeBSD for years now.
i recently spent 4 hours installing random driver versions to get wifi working on a windows pc, i'm of the opinion wifi is just for phones at this point
RTW8852 based wifi, sure. You can get Linux preinstalled, and with full support from some places. I highly recommend doing that if you're going to run Linux. They'll not have that chip though. They'll have one that works.
One application where FreeBSD especially shines is as a fileserver to Windows clients: Unlike on Linux, NFSv4 ACLs are supported natively!
The NT ACLs used in Windows and SMB are much more expressive than Linux's POSIX draft ACLs. When a Windows client writes a file to a Linux Samba server, it cannot necessarily express the file's ACL as a POSIX ACL losslessly. To work around this, Samba's vfs_acl_xattr saves the "real" ACL as an extended attribute: https://www.samba.org/samba/docs/current/man-html/vfs_acl_xa...
This means the ACLs set by clients won't be enforced for local users on the file server, and that you need special tools to view and edit those ACLs.
In contrast, FreeBSD supports NFSv4 ACLs on ZFS, and those are a superset of NT ACLs. Samba saves the NT ACL as an NFSv4 ACL, and this can be viewed or edited using getfacl and setfacl as with any other file on the server.
Even more frustrating, Linux has been offered full NFSv4 ACL support a couple times but the kernel maintainers turn it down. This is honestly my #1 sticking point against Linux and in favor of FreeBSD.
1. vulnerability list is not very relevant as a measure if you don't relate to SLOC, features available or something;
2. having a lot of configuration options for security is far from being good, security should be easy and by default; if the tradeoffs are unclear you enter FUD and avoid enabling them; is randomizing PIDs good? what are the downsides? :shrug:
3. I stopped reading given that the most prominent arguments seemed heavily biased;
About point 1, and not exactly SLOC, but the comparison is between Linux (a kernel) and FreeBSD (a full OS).
Now, it’s possible that the number of vulnerabilities are much higher in the Linux Kernel because there is more research interest due to its larger usage.
The article hits the nail on the head about Linux' "mismatches". When distros need to be different gratuitously, you can no longer get a book on Linux that meaningfully applies across multiple distros. Heck, even an Ubuntu book would be irrelevant after a few changes (16 -> 18, 18 -> 20).
The same people who respond in the community to questions about changes often respond to defend the changes, but rarely respond with answers to the technical questions about them. It's frustrating.
I, on the other hand, tend to think of distributions as operating systems in their own right, so the difference between them is something I welcome - otherwise what’s the point?
This is the way it is. In the free market of ideas not everything is the same just because you find it on the same shelf. If what you're looking for is centralized planning and freedom from the tyranny of choice, stick with your branded stores with their marble floors and genius bars or answer desks.
A Linux distro is an OS. They have in common with your Android phone the Linux kernel. That's a very, very small part of what goes into a distro.
All Linuxes right back to the 90s are basically the same. There are more obvious differences between them and other Unix-like OSes, like SunOS/Solaris, the BSDs, and so on.
I really like this article about FreeBSD. One really nice feature that is not cover though is to set the immutable flags on some binaries with the command chflags. It's possible to boot your very secure system into securemode level 1 or higher. In this mode, it's impossible to delete those files.
rm -rf /* has very limited damage.
chmod -R 0000 /* won't touch chmod and all kind of ooops become much less destructive.
It's probably not useful in all scenarios, but definitely some systems deserve to never be touch live. Automation, scada, super important core backbone systems.
FreeBSD is the power to serve. It deserves more credits.
Just wanted to say that in linux you have extended attributes on files, check the man page on chattr. I believe the -i option makes files immutable.
I picked this little trick up watching a red team discuss how they set themselves persistence on the target system by making /etc/shadow immutable this way.. Fun bit is, root can't even remove the file until the flag is removed, and you can't see the immutable flag on the file unless you know what you are looking for via lsattr.
FreeBSD has the concept of a 'security level'. You can increase it at runtime, which disables more functionality, but you can't decrease it without a reboot.
At security level 1, the immutable and append only attributes on files can't be removed, so even chattr -i would be useless.
It goes far beyond making files immutable. I haven't really done a deep dive to see if it's on par with SELinux but the description in this thread doesn't do it justice.
What I meant is that devising a sane and useful way to make use of security levels seems easier than achieving something 'equivalent' with SELinux. Sophisticated policy systems are nice, but something that kind of bundles sane defaults together and organizes them into ordered layers like security levels sounds great.
The whole securelevel mechanism is nice. You can only increase its value at runtime, never decrease it without rebooting. At higher levels, you can’t modify firewall rules. If you configure the server to boot into a high securelevel, you can make the machine effectively read-only until you boot it with console access.
I've gotten good enough at Linux to where I don't need to constantly look stuff up after long periods of use, but not FreeBSD.
Which is why I love FreeBSD so much. It's consistent, clearly explained, thoroughly documented, powerful, and flexible. I have a home server (just upgraded to 13.1) that I go months at a time without logging in. And while I do tend to forget a lot of important details, looking them up is incredibly easy.
I don't really care about what software FreeBSD uses, just that it is consistent and well-documented.
Plus, the whole architecture of it fits comfortably in my head. It is so nice to reason about.
Not shown: the bewildering choices made for various tools.
sed
* The `-i` flag - In the absence of a file extension given, I should not have to specify with `''` that I want the original file over-written. The flag is called in-place for a reason.
* BSD sed doesn't support ANSI-C escape sequences, so you have to fall back to your shell quoting them for you.
xargs
* Why is there no `-d` flag for BSD?
There are others I've found over the years, but those come to mind as annoyances.
They're just different. It's a different OS. I agree some things don't make sense but some things on Linux don't make sense either. It's just a long heritage of things that have organically grown. Consider 'dd' for example, with its 'if=xxx' whereas other tools would use the format '-if xxx'.
But it's a different OS. Solaris tools were different from the GNU toolset. HP-UX' tools were very different (try compiling something on HP-UX CC lol). MacOS' tools are also different.
If you expect things to be GNU, use GNU/Linux. Or Hurd :) Or install GNU coreutils.
They've been different for very long and this has been causing compatibility issues for very long. A minor annoyance for sure but as a mac user I frequently run into that and indeed installing gnu core utils is usually the proper fix. It's not just that it is different but that the maintainers seem indifferent to all this. It's petty and pointlessly different at this point. Would it be so hard to implement the missing flags?
This is a fair point, and I suppose something I just have grown used to, similar to how I can type `tar xvzf` without any `-` at all, and it works.
> MacOS' tools are also different.
Tbf when I talk of using BSD tools, I'm talking about using MacOS tools - I don't have any BSD installations, I just recognize that MacOS includes mostly (?) BSD tools by default.
I do in fact install coreutils, and either alias them or move PATH priority so they get called first.
> Tbf when I talk of using BSD tools, I'm talking about using MacOS tools - I don't have any BSD installations, I just recognize that MacOS includes mostly (?) BSD tools by default.
It's not inaccurate, but somewhat unfair to use MacOS tools and call them BSD tools. They are ports of BSD tools, but Apple rarely refreshes them from the original sources, so it's kind of a time capsule to 2000. If you dropped 2000 era Linux userland on someone today, there would be a lot of complaints and concerns. On some tools, command flags added in GNU coreutils do get added to FreeBSD, although I did not check your list of specifics.
IIRC, Apple periodically merges some kernel bits from FreeBSD and user space utilities from NetBSD. (Though I can’t find a source mentioning NetBSD, atm.) I don’t know why Apple would choose NetBSD utilities instead of FreeBSD if they are also using FreeBSD kernel bits.
I understand why Apple doesn’t bother to contribute to upstream FreeBSD or NetBSD, but I’m curious why they aren’t eager to merge updates from them more frequently.
> I’m curious why they aren’t eager to merge updates from them more frequently.
I suspect it's because the merge isn't easy to do; which is partially a self-fulfilling property of how infrequent it's done, but likely also has a lot to do with the pretty large differences in system design. A lot of the kernel bits are old as heck too; last I checked, at least the Darwin open source kernel doesn't have any protection against syn floods, which FreeBSD first addressed in kernel 4.5 (released January 29, 2002)
>This is a fair point, and I suppose something I just have grown used to, similar to how I can type `tar xvzf` without any `-` at all, and it works.
So for a while GNU tar didn't support automatic compression detection, and you had to manually specify 'z' or 'j' every time. Quite annoying when you are used to bsdtar, which does this for you.
I agree that BSD coreutils are extremely feature poor (e.g. no PCRE in grep) and have some odd syntax choices as you point out, but you can always install the GNU coreutils. Of course, you then have to prefix everything with “g” (e.g. ggrep, gsed) which can get annoying.
That said, this is why I’ve always given up on BSD every time I’ve tried it—all of the low-level technical benefits touted in the article never actually make a difference in my day-to-day usage, whereas little annoyances with the userspace really add up.
There are virtualization options in FreeBSD, but I can't use FreeBSD in absence of mature OCI compatible container support, without going though hoops on bhyve.
In present day, it matters a lot with a good amount of time being spent on docker/ kubernetes.
ZFSBootMenu provides boot environments for Linux. The now defunct Project Trident, formerly PC-BSD and then TrueOS, had a gui installer that sets you up with
- ZFS on root install of essentially void Linux
- rEFInd with a kernel sufficient just to boot into
- ZFSBootMenu which lets you boot into a prior boot environment
- ZFS native encryption of /home per user directory set up to unlock when you log in via PAM and zfscrypt
- An update script that automatically creates a boot environment prior to updating
- A mediocre choice of display manager and their own customer desktop environment that was neither in my opinion terrible nor interesting. Trivially replaceable with a different DE and lightdm.
Trident is alas gone but all the pieces remain and work fine.
I have a server running FreeBSD 13.1-RELEASE and the experience is kind of mixed. Things from the top of my head in no particular order:
- I like the idea of "kern_securelevel", but I can only use it on the low setting (1 out of 3) because the machine (VM) is sometimes powered off and its time gets de-synced. The server is running ntpd but on this security level you're not allowed to change time by more than a second.
- ntpd doesn't support running with ASLR enabled. Fortunately, you can disable ASLR for a particular process with "proccontrol".
- ASLR is not enabled by default. Not that it cannot be defeated but it's a basic security measure, isn't it?
- User installed packages put their configuration into "/usr/local/etc/". Or more generally user level stuff goes to "/usr/local". I like that, keeps things more tidy.
- Upgrading between major versions requires several reboots. You also have to reinstall / recompile all of your installed packages / ports because ABI can change between versions.
- IPv6 didn't work out of the box because the standard DHCP client doesn't support DHCPv6. Getting it to work took me a while but works now with the use of rtsold.
- pf is nice. Enabling pflog and then inspecting the logged traffic via standard tools such as tcpdump is handy.
- In line with UNIX philosophy, each utility does one thing and one thing only. I find it quite annoying though when dealing with long running services. There doesn't seem to be a standardized way of monitoring once a particular service is started via rc. Some packages use daemontools, some use something else (I forget the name), and some don't do any monitoring at all. Similarly with logging. I very much prefer systemd in this regard.
- Jails are cool but annoying sometimes. Jails are created from a particular version of FreeBSD and you have to keep them up to date with "freebsd-update" like a regular host (including the reboot dance). There's a way to share most of the files between jails using mount_nullfs but I haven't tried that.
- I miss "journalctl --since=-5hours" every time I ssh into the machine. Not sure how I could do it with just plain log files without parsing their specific format.
> [...] I can only use it on the low setting (1 out of 3) because the machine (VM) is sometimes powered off and its time gets de-synced. The server is running ntpd but on this security level you're not allowed to change time by more than a second.
Have you tried configuring your NTP daemon so it would only adjust time in sub-second increments?
I'm a huge fan of FreeBSD, though I have to admit - when I was looking at the Vulnerability Statistics chart I wondered to myself "are there fewer identified FreeBSD vulnerabilities because there are way fewer FreeBSD users (than Linux)".
As a long time Linux and BSD user I agree with you. You still have to enable basic things that are not turned on by default - i.e. stack protection. A lot of this is enabled by default on OpenBSD.
I can't believe that either. At most I'd have written an angry blog post and never updated it.
Don't know what keeps him going. A desire to see FreeBSD fix those defaults? Desire for OpenBSD to be recognised as having better defaults for security than FreeBSD? What would that even look like?
> Don't know what keeps him going. A desire to see FreeBSD fix those defaults?
And when they do fix any of those things, what is his reaction going to be? So far it's been "it took them so much time to fix this, let's keep that in mind".
The point of it is clearly to convince people to use OpenBSD instead of FreeBSD.
I thought the same thing. And also there is probably more code compiled in the majoroty of Linux deployments and that widens the attack surface. So just comparing the absolute vulnerability counters is not useful IMO.
I think the mismatch thing doesn’t really make sense, as you should consider freebsd as a complete OS rather than just the kernel, and archlinux as the same. Dragonflybsd and pcbsd for example have the same freebsd kernel, do they follow the freebsd way too?
The rest is about preference with the exception of DTrace that is imho superior , but I am not going to pick freebsd over Linux only for DTrace, as Linux has better compatibility and support with software and hardware in general imho
Edit ps: I use gentoo so I see the power of ports but I can match it with the wider support of Linux
Not only that, the split was ca. 20 years ago, from FreeBSD 4.8. They're massively different now. DragonFly also uses NetBSD's pkgsrc system (having initially used a fork of the FreeBSD ports tree), so there are significant practical userland/sysadmin differences too.
Exactly, there are a lot of BSD variants out there. You might consider them BSD distributions even. And they are as different from each other as Linux distributions are from each other. They all share the same messy ancestry of different companies cloning Unix in the nineteen seventies and eighties and doing loosely the same things with loosely the same naming conventions and tool names.
That link has been posted here many times already.
I use FreeBSD as a daily driver on my desktop. Very happy with it. My reasons to choose it were more that I feel like Linux has become a toy of big tech. If you look at the kernel contributions, most of them are from people working for all the big names. Linux has become Big Business and each company is trying to safeguard their interests in it. Linus is still in charge of the kernel officially but all the steering groups are dominated by big tech. Look at the Linux Foundation for instance: https://www.linuxfoundation.org/board-of-directors/ . These are not the kind of people you'd expect to lead 'free software', these are all boardroom types. Maybe Linux has outgrown the beardy hacker culture but I have not :P
Of course, Linux is not much worse for it... Yet. I think this is for 2 reasons: Linus' benevolent dictatorship, and the fact that they won't be able to agree on much given that these guys are all competitors. But in the long term I'm sure this will take its toll. For example, would these guys ever have approved the GPL-3? Everyone in business is pretty universally against it.
And in fact it's the very BSD license that makes big business shun FreeBSD. Which I think is a good thing. FreeBSD still feels like a grassroots development and as such I feel more in control. The excellent and consistent documentation and friendly community is another plus for me. And the combination of stable OS with rolling third-party software (but this is something that was also mentioned in the article). ZFS on Root is another one (though Ubuntu is now catching up to that).
> Like hardware manufacturers? I thought getting commercial users to contribute to the kernel was desirable?
Contribute to drivers, yes. Steer development of the kernel, no, IMO. The more they contribute, the more influence they gain. And a lot of the contributions are not hardware related at all.
> Didn't Torvalds himself reject GPL-3?
I don't know, I didn't follow this as I don't follow Linux news that closely anymore. I thought it was mainly about the way that it was introduced. But I think it's a much better license than GPL-2.
> Now I'm really confused. Why would businesses not like the BSD license? And they don't like GPL-3 either? Is GPL-2 the goldilocks license for them?
Businesses hate the BSD license because any code derived does not have to be open at all. So that means anything they contribute can be taken by their competitors and used in closed-source software. That's totally OK. Because of this there's only a few companies involved in BSD. Notably Netflix, the former Skype (before it was acquired by MS), and some smaller orgs like Netapp and iX that makes freenas/truenas.
Companies hate GPL-3 because their license gets revoked if a company uses its patents to attack GPLd software. It also stipulates some other things like that devices running GPL-3 software must also be open (e.g. no locked bootloaders etc). Very good things IMO. A lot of GPL-3's stipulations were triggered by real-world exploitation of free software. Examples: By TiVo (hence the name "anti-TiVoisation clause" for the open hardware thing). And the anti-patent clause was a direct result of Microsoft's patent attacks on Linux. No wonder Steve Ballmer hated the GPL-3 so much.
This is why Microsoft and most of the others hate it so much, they love giving open source lip service, but are not really open source companies. The GPL-2 gives them enough loopholes to get away with this. Many companies avoid GPL-3 licensed software at all costs, it was the driving force for bash not being updated (and replaced by zsh) on macOS for example.
Personally I think it would be better if FreeBSD was GPL-3d but BSD is not bad for me as a use that doesn't want too much corporate influence. After all, if a company makes a closed-source fork it doesn't impact me in any way. I won't use it anyway.
> Businesses hate the BSD license because any code derived does not have to be open at all. So that means anything they contribute can be taken by their competitors and used in closed-source software.
Isn't this why businesses love the BSD license?
They can take BSD-licensed code and do what they want with it and keep the end result closed.
I think you might be 100% incorrect with your supposition on businesses and BSD licensing!
Businesses love BSD licenses, because they can use the code for any purpose they need, whether internal use or building something and distributing it.
No one can force them to share any part of their work, or even share anything.
Netflix, Juniper, Apple (and many others) all use BSD derived UNIX components, precisely for that. They contribute back what they want (and mainly what they do jot wish to maintain as a company secret).
GPL-3 is much more complex because it can /require/ you to share code. BSD licenses do not require you to share anything.
Businesses in general do not like ‘requirements’ like that even if only because they have to track them and ensure they do not break any licenses.
I work for a large financial services company, GPL-3 licensed software requires specific approval, AGPL is banned across the board (same as in Google).
BSD and GPL-2 is fully permitted (as is MIT and all the other style licenses)
> Businesses hate the BSD license because any code derived does not have to be open at all.
That's the opposite of truth.
For example, Apple ships many BSD software on macOS, explicitly shuns updates for GPL software, and endorses the LLVM project from very early time exactly to avoid the GPL license of GCC.
Or take Google. Android, Kubernetes and Tensorflow are licensed under Apache. Chromium, V8 and GoLang are licensed under BSD.
Or take Microsoft. Typescript is licensed under Apache. VSCode is licensed under MIT. .Net Core are licensed under both Apache and MIT.
Companies choose Linux despite its GPL license, not because of it.
Was the GPLv3 ever formally rejected? Isn't the problem that the Linux kernel was GPLv2 only before the GPLv3 existed, and by the time it did come out, there were too many contributors for there to be any hope of getting it changed?
To be honest that reads more like a list of complaints about how they didn't do the process the way he prefers, rather than criticism of the license itself.
The only point of actual criticism about the license that I see is that it is one way compatible with the Apache license. And the supposed ideology of wanting to absorb other licenses, though one could argue that the designers just wanted to have an easy migration path.
https://www.youtube.com/watch?v=PaKIZ7gJlRU - Linus states he hates it. He does say that it's a fine license, and that the freedom to choose a license is important. The video is worth a watch if you want to understand what people who disagree with GPLv3 dislike about it.
The main reason to use Linux is because almost everyone else is. If you're only installing it on your own servers at home, then that's okay. But in a business environment, the minor differences or improvements with FreeBSD are simply not worth the lack of familiarity for most people over Linux.
I used FreeBSD starting in 1999-ish and I still have the original Design and Implementation of the 4.4 BSD Operating System on my shelf. I used FreeBSD exclusively for years, but it has completely lost to Linux and Linux frankly is good enough.
I have to plugin Void Linux, a nice little distro that tries to mimick some of BSD philosophy (I believe w.r.t. simplicity and security). It's working very well here (it's somewhat analogous to Arch, meant for advanced users -- that said, following the docs it shouldn't be too difficult to get going).
I don't think comparing FreeBSD to GNU/Linux is a fair comparison. since FreeBSD is looked at as a whole operating, it should probably be compared to Fedora or Ubuntu or RHEL, etc. Particularly the complaints about how some follow "the Debian way" and other don't. If you're going to say that, you invite criticism about things that work on FreeBSD but not on OpenBSD.
For people (semi-rightfully) complaining about the feasibility of FreeBSD as a desktop OS (or a workstation purposed OS), the fact that it isn't easy to install through the graphical interface is both a blessing in disguise and a legitimate point for slow install + config times. To that end I say to the less keyboard/terminal focused (which should be a paradox when it comes to developers but whatever) : try some of the general-purposed graphical "flavors" of FreeBSD: MidnightBSD, GhostBSD, NomadBSD. MacOS users who want to seek the same experience but on a less closed unix(Still FreeBSD): helloSystem(from an ex-Apple if I recall correctly) & ravynOS (previously 'airyx').
Of course there is also netbsd + openbsd, but imo those are really far behind FBSD when it comes to being mainstream and usable as daily drivers. One of the main reasons I personally can't daily drive FBSD on my laptop is the lack of proper drivers (I know about 'running' the linux ones). Still a more than decent choice for any desktop unless running very obscure hardware or needing specific requirements (think cuda,cudnn,rt and similar proprietary software/libs)
Haven't tried Mono, Node, or anything NoSQL, but Java, Ruby, and Postgres all run pretty well. It is runtime-compatibile with Linux executables and you can even install a linux distro in a jail
I guess calling POSIX modern is a point of view, unless a language runtime is bound to Linux specific syscalls, any UNIX like OS will run "modern" web backends.
From that point of view, you can even do "modern" web backends on IBM and Unisys mainframes, using their POSIX environments.
And yes, they do actually support everything on that list, by the way, mainframes invented noSQL databases before SQL was a thing, have a look on ISAM.
Very, very few things depend on Linux-specific syscalls. There are two reasons for this: first, they are unportable, so you need another code path for everything !Linux anyway, and even when you only care about Linux you can't assume those syscalls are available, because you first need to get them into the kernel, then into glibc, which is a separate project, and then you need to ship them in the distro, which in some cases (RHEL) means either waiting half a decade or porting it to a kernel half a decade old.
And no, there aren't many things you can run on z/OS POSIX environment, because it fails to support absolutely basic things, like fork(2).
>mainframes invented noSQL databases before SQL was a thing
I'm not sure about this; structured storage was popular before Unix made flat files common, but there was a fundamental flaw in how it was implemented: it was all in the kernel, not on top of it.
What mainframes are still alive, apart from z/Architecture?
As for "modern Web development" - not really; it's a bit like running Apache and MySQL on Windows 98 - yes, you technically could, but you probably don't want to. Have you heard of anyone wilfully choosing to use mainframes instead of some Unix over the past two decades?
IBM i, Unisy ClearPath and OS/2200, related offerings, now you can feel pedantic and differentiate which of them are proper mainframes, which are mini, microcomputers or whatever.
We are discussing technicalities here, the whole point started about Linux isn't the only way to have access to such called "modern" Web tools.
Technically they exist in any UNIX environment, mainframes (or whatever you feel like calling them), and Windows.
Wilfully or not, they offer such capabilities in 2022, and there are people paying for their use, probably many more people than some obscure UNIX clones that still exist out there.
And again, this whole thread started with what is possible outside Linux, and apparently I touched a nerve with you, apparently related to your FreeBSD role, let it go.
FreeBSD, IBM i, Unisys ClearPath and OS/2200, or flavour of the month UNIX clone, are all miles behind Linux distributions for Web development on compute centers, if you insist in counting ammo.
So better spend your contribution time in more productive discussions.
The thread started with what's possible outside Linux, but I don't think that to majority of people that means systems that exist purely for backwards compatibility. And I'm pretty sure that's the main - or perhaps the only major - reason anybody is still paying for "i" and OS/2200.
And no, neither FreeBSD nor MacOS are "miles behind Linux"; in fact all the same pieces of ecosystem are available in all of them.
You can run Spring with Java 17 in FreeBSD without problems. Same with Node.js, Postgres and MongoDB for example.
About Mono, I don’t have experience with this environment.
But I’m using the other technologies at my work without problems.
I use FreeBSD on servers instead of Linux for one reason: ZFS. It's really that much better than anything that is currently available on Linux. BTRFS is not even close.
Yes I know it's available on Ubuntu but everything else about Ubuntu is just so messy.
I don’t have a lot of SRE/sysadmin/etc. experience, so this is probably just ignorance on my part, but I find it hard to imagine a scenario where the filesystem on my servers matters at all (as long as we’re not talking about something super ancient like FAT).
What are some workflows that ZFS enables for you on servers that you couldn’t do with ext4 or stock FreeBSD FFS ?
* data compression - say midsized 1.6TB mysql db compressed into 400Gb => allows to run replica servers on cheaper hardware (smaller drives)
* hot data set caching - depending on case can be 5-100 times better performance
* single pool but different settings per FS - say block sizes 16k for DB and 256kb for file storage
* snapshots. Instant snapshots
* coming back to db replication case, this helps to test db scheme migration on close to production env and prepare better planning/downtime window. Once tests done - rollback snapshot and enable replica back without full reclone.
Yes but it’s clunky. ZFS on FreeBSD is smooth as silk. Ubuntu is the only distro that I would say has good integration with ZFS but I don’t like anything else about Ubuntu.
what linux server distro are you using if not ubuntu lts? Im not a massive fan either but i run thousands of the bastards (k8s hosts) and cant imagine an other...
At $CURRENT_JOB we run our postgres database on a massive bare-metal dedicated server running FreeBSD, our container hosts are Alma Linux 8 and the base images are typically debian-slim, though some are alpine or even scratch.
Let me pick and choose a few points since replying to everything will necessitate a similar 40-page post.
FreeBSD has great engineering and release management practices
When someone gets an idea and develops something new, it first gets peer technical reviews
The recent WireGuard debacle left a bad taste about this. As it actually turns out, sometimes there is zero technical review for very important patches and a few blessed developers can (and sometimes do) just throw their stuff directly into trunk.
Unlike on Linux, the ZFS filesystem is a first class citizen on FreeBSD
ZFS has first-class support on Ubuntu and is compiled into the kernel.
systemd is not required (all the heavy lifting is done by the kernel using the same features employed by containers), but it's available almost everywhere and makes this easy.
security
I actually think it's worse in this regard because of the link above. Most services on my machines are heavily locked down and isolated from each other since systemd makes this very easy (add a few key-value pairs to an .ini file and it's done). On FreeBSD the developer must add capsicum support (which is not easy to say the least), or you have to setup jails for each and every application manually.
Not sure if this counts as a particular advantage.
Firewall
I find nftables to be pretty enjoyable to work with. It has a similar syntax, removes duplication of rules (supporting both ipv4 and ipv6 at the same time), etc. I actually removed firewalld from many RHEL servers and went with nft directly.
The recent WireGuard debacle left a bad taste about this. As it actually turns out, sometimes there is zero technical review for very important patches and a few blessed developers can (and sometimes do) just throw their stuff directly into trunk.
This seems like a misunderstanding of the FreeBSD development model. Yes, immature code landed in HEAD, but it was removed before the next release.
In general in FreeBSD there's no expectation that HEAD is always usable. Sometimes it won't even build! It's a place where code can land in the hope that it will be ready by the time the next release rolls around, but "remove code which isn't ready for prime time" isn't an exceptional case.
FreeBSD has a very strong history of post-commit code review, largely because every FreeBSD committer gets email when commits go into the tree -- that's a lot of eyeballs. We're moving towards increased pre-commit review thanks now that better tools are available for that, but that's a separate matter.
(Yes, Netflix runs FreeBSD HEAD. I think they're nuts.)
It was rushed because a particular vendor wanted to have it as soon as possible. If not for Jason Donenfeld's diligence it looks like we would have out there in the open, full of bugs and all.
Doesn't seem like a normal occurrence though, seeing how much noise it made.
The WG code was introduced unusually late, I agree. Usually experimental stuff like that lands soon after a .0 release so that there's a year to iron out details before the next release. But this is a quantitative difference -- how close to the next release do you push experimental code into the tree -- not a qualitative difference.
And fundamentally the system worked! The code was deemed to not be ready and was yanked before the release.
Oh, they absolutely justify it on the basis that if a CDN node is unstable they'll just fail traffic across to another node. And as a FreeBSD developer I have to say that it's great having the OS (or at least the parts Netflix uses) stress tested -- you can't reproduce "1/3 of all internet traffic" in a test lab.
The reason I think they're nuts isn't stability but rather security. I guess since they're shipping these boxes around the world there's nothing really sensitive on them; but still, if I were in their shoes I would be worried about security bugs being introduced.
> The reason I think they're nuts isn't stability but rather security. I guess since they're shipping these boxes around the world there's nothing really sensitive on them; but still, if I were in their shoes I would be worried about security bugs being introduced.
Perhaps they have some really awesome IDS, and honeypots, and good security boundaries between components, etc. A company like that surely has a good plan in place.
> ZFS has first-class support on Ubuntu and is compiled into the kernel.
And Ubuntu is also the only distribution which has ZFS. Using ZFS on any other distribution (for example RHEL, Rocky Linux, etc.) is a pain. Every update is Russian roulette in which it can break.
And everyone except Ubutunu thinks it's a violation of the CDDL. Keep in mind that Oracle is the copyright holder of ZFS. So you (and Ubuntu) are violating Oracle's license terms. Would be realy interesting to see what happens if Oracle decides to sue an Ubuntu user. Would Ubuntu step in to help?
> There's also real DTrace on Oracle Linux if you're ready to sell your soul:
I can't run Ubuntu (for ZFS) and Oracle Linux (for DTrace) at the same time. Besides, like you said; Why would anyone want to use Oracle's Unbreakable Linux?
> Well... linux has containers, and if all you need is isolation...
No that's not all I need. I need things like virtual networking between my containers.
> I actually think it's worse in this regard because of the link above.
Depends. If you put them in a FreeBSD jail they are probably better isolated then only using systemd.
It's not "only Ubuntu". I'm using ZFS (not for boot or root partition) on Gentoo for some time. It's a separate package from kernel, and has to rebuild after a kernel upgrade but it works as expected.
> Keep in mind that Oracle is the copyright holder of ZFS. So you (and Ubuntu) are violating Oracle's license terms.
If anything IS a problem here it is violating the terms of the GPL, not the CDDL.
So no, no one is violating Oracles licensing terms - and if they were, they’d have been sued in 2016 when this shipped. Do you really think ORACLE of all people is just holding back out the goodness of their hearts?
> If anything IS a problem here it is violating the terms of the GPL, not the CDDL.
How so? Aren't the GPL and CDDL both copyleft?
> So no, no one is violating Oracles licensing terms - and if they were, they’d have been sued in 2016 when this shipped. Do you really think ORACLE of all people is just holding back out the goodness of their hearts?
No, Oracle is holding back because they want more money. If they sue a little guy now, then everyone else will immediately stop using ZFS-on-Linux. They're waiting until someone with really deep pockets starts to use it before they sue.
They are, but GPL is (tl;dr) incompatible with anything that's not a subset of GPL. That's because GPL is viral, and CDDL isn't. And that's why in the Open Source world you can't get license incompatibility without throwing GPL in the mix.
So, yeah, it's GPL that's possibly being violated; CDDL is fine with whatever license there is. Oracle could sue you if they relicensed ZFS under GPL, but can't with CDDL because of implicit protection CDDL contains.
Isn't the whole reason that the CDDL is a problem that it is viral too? Otherwise you could just distribute the whole bundle of ZFS+Linux as GPL and be fine.
It's not, CDDL explicitly states it doesn't apply to non-CDDL-ed source files. The problem is, GPL is claimed to be the other way around, so this would mean applying GPL to CDDL sources, and you can't do that, because CDDL gives you additional protections ("freedoms") GPL doesn't, and that's GPL-incompatible.
If I combined ZFS and the Linux kernel and licensed the result under the CDDL, I'd be violating the GPL. If I instead licensed the result under the GPL, then I'd be violating the CDDL. I'm not seeing how the licenses' differences actually cause an asymmetry here.
You can't "license the result", it's not your decision to make. GPL parts are GPL, CDDL parts are CDDL, BSD parts are BSD and so on. There's no problem with mixing code under different licences. That is, until GPL enters the picture - because GPL is viral, so it (at least according to FSF) claims the non-GPL parts too. It's not a problem for, say, BSD, because it's a subset of GPL[1], but it can be a problem with licenses that guarantee you more freedoms than GPL, like CDDL, Mozilla license, Apache, or even GPLv3.
1. And it used to be a problem with the old BSD, with the advertising clause, precisely because it wasn't a subset.
> If anything IS a problem here it is violating the terms of the GPL, not the CDDL.
The CDDL terms are violated because you can't re-license code that is under the CDDL (in contrast to for example the BSD licenses). The GPLv2 is a strong copy-left license that puts the CDDL files under GPLv2.
Even the creators of the CDDL themselves have stated that the CDDL is probably incompatible with the GPL [1].
You cannot relicense BSD code. In general, you cannot change anything about the copyright or license for any work that you do not own the copyright to.
Perhaps you mean the BSD licensed artifacts are "compatible" with copyleft licenses?
Relicense might not the best word but compatible also doesn't cover it in this context.
Saying you can "assimilate" BSD licensed code in to a GPL project might be more appropriate. Since rights such as "Redistribution and use in source and binary forms" which the BSD gives you no longer apply after the code is in a GPL project [1].
> Most services on my machines are heavily locked down and isolated from each other since systemd makes this very easy
Do you have a guide handy? A quick Google search only showed generic nonsense. I'll appreciate a recipe-like pointer. Been curious about this for a while.
Probably the easiest way to start is to create your unit file as usual, copy the list from the comment into it, and then run:
$ systemd-analyze security unit-name
It prints a huge list of suggestions along with a short description of each one. Look up their names in here:
$ man systemd.directives
and look at the man linked there. Usually it's one of
$ man systemd.exec
$ man systemd.resource-control
I think the starter list should get you 95% there (I use it for most applications with minor variations in paths and flags like MemoryDenyWriteExecute that breaks JIT compilers).
---
If you want to keep your configuration as short as possible, the list with the most bang for your buck would look something like this:
User=non-root-username
# disable privilege escalation through SUID binaries
NoNewPrivileges=yes
CapabilityBoundingSet=
# removes access to /home
ProtectHome=yes
# makes most paths read-only
ProtectSystem=strict
# opens read-write access only to paths your application needs
ReadWritePaths=/var/lib/foo /var/lib/bar
If your application follows FHS and writes stuff to /var/whatever, prefer:
> Keep in mind that Oracle is the copyright holder of ZFS. So you (and Ubuntu) are violating Oracle's license terms. Would be realy interesting to see what happens if Oracle decides to sue an Ubuntu user. Would Ubuntu step in to help?
There is nothing in the CDDL that prevent a user to use ZFS with a kernel under GPL license and no leverage for Oracle to sue the end user for this. The end user is not distributing the software. Ubuntu or possibly an hosting provider or a company incorporating ubuntu in its product does.
On the desktop, Linux is going to be challenging anyway. Many people love that challenge and make it work, and that's cool. But my point is that if you can make it work on desktop Linux you will make it work on FreeBSD as well, given some decent skill.
> Linux on the desktop is actually quite a bit better and easier to use than FreeBSD.
As someone who actually started learning *NIX on BSDs and later switched to Linux, I think "quite a bit better and easier" is an understatement. I tried the latest FreeBSD last year on a not so recent Lenovo laptop and it was a horrible experience.
A guy I know (relatively skilled) spent a whole week setting up Linux on his laptop the other day. So I don't think it's always as predictable as to say there's never a challenge involved in 2022.
Not sure what do you want to prove with that anecdotal point. I've seen coworkers spend a month or 2 with both their new and old mac or windows laptops because they weren't seeing the end of migrating their stuff from one computer to another and setting up their dev environment.
Just install Ubuntu if you quite literally cannot grasp GNU/Linux. No, your "guy" is not "relatively skilled", that's an absurd claim when it took an entire week setting up Linux on a laptop. It has never, ever taken me more than an hour or two with mainstream distros, or more than 3 days max. for more complicated distros such as Gentoo or Arch - but the system would be minimally operational within a day, always. You would literally have to one-finger press your keyboard whilst also learning how to read for the first time simultaneously, to make the install of Linux on a LAPTOP last a week.
Installation does not just mean finishing the setup from the livecd. We have to work at copying our apps, configs, etc and it can be a lot of "long tail" work to get things exactly as before.
I just installed Fedora 36 on my Thinkpad. It went pretty smoothly. Single monitor, AMD CPU/iGPU.
There are a few gripes about the discoverability of the keyboard shortcuts. Unity was good with this, holding down the Win/Meta key showed all the DE shortcuts.
Also, there is not an easy way to change certain settings (like system font!) without installing an obscure package "Tweaks" that should be built into the system settings.
Have you not ever used a Linux distro?
I haven't had an issue with monitors since before Ubuntu 8.
Seems ridiculous you're going to claim that Linux, which dominates the phone/handheld industry, would have issues in regards to using high resolution/high DPI monitors along with lower spec ones concurrently.
I think of all OS's, my bet would probably be that this is a way bigger issue on Windows than on Linux or Mac.
What you’re saying is probably valid for a desktop (especially if it doesn’t use Nvidia), but laptops (especially Nvidia ones) are still far from perfect. Personal experience with Ubuntu on a recent Thinkpad:
* When using Wayland, until VERY recently (latest nvidia drivers), the entire system would freeze when hooking up an external monitor. Okay, no problem I’ll use X.
* Hygrid graphics just completely doesn’t work, loads of glitches, glacially slow framerates on external monitors, etc. Okay, I turn off hybrid graphics in the BIOS, but that absolutely trashes battery life.
* X does not let you run different scale factors concurrently. You can’t set your laptop screen to 2x and your external monitor to 1x. Wayland does let you, but see above.
* I have two 4K monitors hooked up to my laptop. Whenever I resume from sleep, there’s a very good chance that only one or zero of the monitors is detected. They both power on, but only one (or sometimes none) of them actually has a signal. Cycling power on the monitor usually fixes the issue. My coworker has a Thinkpad from the same line but a generation earlier, and it had the exact same problem, so this has apparently been around a while and still isn’t fixed.
> Personal experience with Ubuntu on a recent Thinkpad:
Well, that's your first problem. How does FreeBSD or OSX do on it? Maybe you should buy a Linux laptop to run Linux instead of slapping Linux on a Windows laptop and expecting it to work correctly.
Don't Nvidia make open-source Linux drivers now?
I honestly have not had graphical driver issues since... Well since a good while before SteamOS and such. I don't doubt you guys at all, but I only have "older" laptops that might have GPU issues in terms of overall Linux compatibility.
> Don't Nvidia make open-source Linux drivers now?
Yes, but only since very recently — AFAIK, most distros are not using the open-source drivers yet, as they don’t yet have feature parity with the proprietary ones.
If that's true then there's been substantial improvements on that front recently (which is good). As I recall, that was a tricky problem since your laptop screen likely runs another resolution, different DPI, etc so connecting to an additional screen makes things go haywire.
Works on my machine, anecdotally; no Wayland, and an X window manager that hasn't been updated in a decade. Automatically resizes windows when I drag them to fit each monitor's DPI settings.
Btw, does it allow you to run different scale on the different monitors? It wouldn't really be feasible to run native 4k resolution on one monitor if everything will be tiny, so it needs to have scale. One monitor might run on 1x and the other 2x.
Ubuntu is clearly better for average people on the desktop than FreeBSD. (And I’d argue that macOS is in turn clearly better for most people than Ubuntu).
But FreeBSD is great as a desktop for tinkerers — if you want something that’s simple enough that you can actually understand how it works, and whose source code you can quite easily jump into, modify, and rebuild, it blows Linux out of the water.
I have been daily driving FreeBSD as a desktop since the last time this article was posted and I love it. It is super consistent and reliable, and after I got it set up, I don't have to worry about anything breaking. I can easily use it daily for coding and web browsing, and it feels as smooth and fast as a Linux setup on the same hardware.
That said, I still have a Linux system for things like gaming, Cuda, and containers. Though, as I never have time to game anyways, I could just use the Linux system as a server.
But, I've used Linux for 10+ years and it only started annoying me recently so I may also get frustrated with freeBSD eventually.
How are things these days with graphics (well, NVIDIA and maybe intel, I don't care about amd) drivers, CUDA, ML? How's support in general for latest hardware like CPUs, mobos/wifi?
Basic usage with Nvidia drivers works ok. Nvidia disables CUDA and NVENC/NVDEC on FreeBSD. CPUs/motherboards work great, at least in x86 (arm64 probably works well, too, but I'm less familiar). Wifi is very behind the curve. If you have a supported card (including some 802.11AC cards), 802.11N probably works -- but last I heard, AC does not.
I really like the idea and would live to give it a go, but as someone who develops across web, xamarin, .netcore, docker and wants good first support for these tools so I'm not wasting time/money it looks like I would be hard pressed to swap without dedicating a lot money to the effort. Also, does freebsd run on m1/m2 hardware yet?
Happy if I'm wrong and someone can point me in the right direction. But the few times I've looked into it it doesn't seem worth the expenditure.
how does the kernel compare these days? pre-cfq i remember the scheduler was far better than linux, but what about raw performance for single and multithread/process workloads with lots of i/o going through the kernel?
raw cve counts seem meaningless without a denominator to me. those numbers should be normalized by estimated install base if they're going to be compared.
Yeah, the number of BSD CVEs just boils down to the fact that nobody cares about BSD. Since nobody cares about it, its performance is also very 20-years-ago and doesn't stand up to modern linux performance. You could expect database performance (e.g. postgresql) to be 2-4x higher on linux under a highly concurrent load. There are thousands of full-time professionals around the world focused on linux performance and the applications are co-evolving to work best on linux so you can't expect cutting-edge speed from freebsd.
There's probably a niche for freebsd but unless you know exactly what it is and how to exploit that niche, you're not going to find it by accident.
I am quite certain that you would be shocked if you learned how many people use it. I've worked at two companies where more than 95% of servers ran FreeBSD, and these are absolutely companies that you have heard of. 10s of thousands of servers at each when I worked at them, and likely 5x that amount, now.
lots of people care about FreeBSD. they just aren't known for crapping on Linux, like Linux users are known for crapping on everything that is not Linux.
Well to be fair, most people using FreeBSD are also Linux users, save people indirectly using/'benefiting' from BSD, i.e in a work environment as you mentioned.
Of course discounting Mac users (I honestly think that's a hilarious joke).
It also strikes me that many companies use BSD simply to save money in an area where time =/= money, as BSD is very secure and very stable, there are some licensing issues with many big Linux distros, etc.
I very much doubt that anyone in the year 2022 are using BSD servers or workstations to improve their performance yield unless you're working retail or construction or something and are looking to implement a RTOS platform based on BSD because your boss severely capped your department's budget lol
there was a time when freebsd's networking stack was pretty trendy for use in high performance networking settings.
it was frequently used to implement things like software load balancers. quite possibly because of its (pre-linux-cfq) superior resource scheduling.
there was also a time before it was trendy to complain about the GIL in python where SMP in freebsd suffered from the BKL. only one processor could be in the kernel at a time.
So who are these companies? I hear references to them constantly, but pretty much the only ones willing to stick their head above the parapet are Netflix (in a single use case) and a few storage/network vendors using proprietary forks.
I would scream if I ever saw a dude in a suit give some 70's looking NEET permission to base their company's entire IT platform on FreeBSD specifically. It'd be like switching all your office workstations from MacOS to Ubuntu or Linux Mint.
Because it's not worth the hours when it inevitably breaks, which corpo server setups always do. At least in my view, that is.
If it's running GNU/Linux or, God forbid, Windows, honestly as the head of a larger company I can just make a guy or another company fix it asap, whereas with BSD you'll be reliant on a handful of people at the very most, and no one is going to help you. They'll help you to help yourself, but 2 hours spent on something where I could've just called up another big company and have them do it, is a waste of money.
Also whilst Linux can update without reboot (I believe you even do kernel updates now?), as far as I know BSD is a lot more fond of rebooting.
BSD as a whole is more turbulent and uncoordinated than GNU/Linux, honestly. It's the individual distros up against each other that makes BSD the more stable party, i.e BSD vs Debian. But sometimes, being coordinated and calm just means "not innovative". BSD is probably the furthest you can get from progress and innovation imo.
Heterogeneous infrastructure was my main motivator to learn FreeBSD.
Without this diversity, in face of a security issue, you can only shut-down or take the risk.
On the other hand, when there’s a bug or suspicious activity on FreeBSD servers, you can turn off only those servers, while the problem is patched, and viceversa.
For me, it comes down to what's usable to do my work.
Today, I can pick a regular Windows laptop and have a decent experience with it on Linux, whereas with FreeBSD it is likely that WiFi/BT won't work, GPU acceleration might not work, software is likely to be out of date compared to rolling release Linux distros, then there's the whole WireGuard fiasco[1] and an apparent disregard for code quality, no Docker, no k8s, slow boot times, no ability to play AAA games, non-declarative init etc. etc.
If I were to run a BSD on a server or a router, it would most likely be OpenBSD as that at least has the security aspect going for it.
despite all the Linux users defending their operating system (they should, Linux is great) based on past experiences, I still prefer FreeBSD when possible. it just feels ... like a complete thing, rather than an assembly of different things. it makes sense to me.
the article mentions this, and when I started typing I thought I could do a better job of explaining, but as I typed I realize that I could not.
it just feels better to me. it may not feel better, or even good, to any of you, and that's (of course) fine with me. I just like FreeBSD.
I think FreeBSD deserves far more attention than it gets, and I am therefore quite happy to see this article on HN, even if others can't see why it's a valid option for anything they need.
AFAIK I and most people can't run it due to freebsd not supporting our hardware. Does it support intel wifi and GPUs? (I'm using an amd GPU). Can I run netflix or prime and get 1080 resolution? (note on linux I need to use a addon to achieve this)
Yes, it does support Intel WiFi and GPUs, and in some cases (all GPUs, more and more WiFi) it uses code borrowed from Linux. For Netflix you'll need to run Linux Chromium or Firefox using linux(4) (https://docs.freebsd.org/en/books/handbook/linuxemu/), because of widevine.
As a long time FreeBSD user it makes me sad to see so many GNU/Linux users dismiss FreeBSD and it’s way of doing things. Jails? Pfft. We have docker. Since everyone else is using Docker, surely it must be the superior technology? And so on.
Does HDMI audio work out of the box on FreeBSD? I am using Linux on my laptop and HDMI audio sounds crackly. I googled this and apparently this is a common problem. (https://www.google.com/search?q=linux+hdmi+audio+crackling). I tried to fix it (following this research) but gave up after a while.
When I had Windows on this laptop, the audio over HDMI worked beautifully.
>On FreeBSD you'll notice right away that you're dealing with a "complete operating system", a system that has been put together very well.
Ugh, this argument is long in the tooth. It’s not a complete operating system. It never will be, and neither will GNU/Linux. To be “complete” you need to support all the hardware. You can’t.
Also, a base install of FreeBSD is missing the port tree sources… so complete…
> To be “complete” you need to support all the hardware. You can’t.
You redefined a crucial word from the author’s thesis, in a way that’s obviously not remotely close to what was originally meant, and then concluded that the argument was “wrong”. Well, of course…
Too bad BSD has such obscure hardware support, anyone running BSD over GNU/Linux is going to lose performance and responsiveness having to run everything through layers of code and emulation.
Also, due to squalid support, it's only really usable without GUI - bad scaling and graphical acceleration, or the lack hereof, as well as poor support just means that most GUI solutions for BSD look worse than Windows 3.0.I've yet to see anyone make BSD look agreeable, the only viable solutions being KDE and XFCE, both of which suck. Surely that'll take away from productivity as well, but that's just me.
The poor support is the worst offender, also because it seems to me that a lot of the lacking hardware support stems not from a lack of users, but a general apathy towards doing anything on your computer that isn't just using emacs or compiling. The lack of wifi support is most baffling and contributes to the fact that doing anything with BSD on a laptop that isn't owned by one of the developers themselves, will result in sluggish or subpar performance.
I have the same opinion on desktop BSD users as I do with GNU/Hurd users. You do you. But as soon as you start talking about the perceived sufficiency and/or supremacy of your deprecated, wet 80's FOSS fever dream of an OS, it becomes impossible to communicate.
I've considered migrating my NAS to openbsd few times, but one thing I was not sure about is with that to replace the filesystem with. I'm currently running btrfs and I like it. Few things I would like to have in a replacement:
1. copy-on-write and snapshots
2. checksums that are automatically verified on reads
3. btrfs' version of RAID1 (meaning I don't have to buy identical HDDs only)
I'm pretty sure OpenBSD doesn't have the feature set to be good as a NAS. You lose most filesystem support in exchange for a bunch of stuff that probably doesn't matter all that much for a NAS.
I've run a mirror with non-identical disks on ZFS, worked just like any other mirror. I bought two pairs of disks from different vendors and ran them as mixed pairs in case the disks from one vendor would fail simultaneously.
Disk space is, as expected, limited to the smaller disk in each pair. However, if you replace the smaller disk with a larger one, ZFS will automatically grow to the new minimum. You fault one disk in a pair, swap it with a larger and bring it online, ZFS will repair (fill the new disk) and once finished the pool will be larger just like that.
I've used this approach to increase the size of my pool, which again meant having a pair of different disks in the mirror as I did the the swap process.
Hmm I think you can mirror different sizes just fine but it'll predictably use the smaller size, no? Is btrfs different in that regard? I have only used it when it was released many years ago so my memory is rusty.
Btrfs' RAID1 works bit differently. It ensures every block (1GB by default I believe) is present on two devices. So, if for example, you have 2x 1TB and 1x 2TB drive, you get 2 TB of usable space.
It is arguably not the most useful property in enterprise setting, but helps to stay on budget on home projects, since I can just use random drives laying around without any further requirements on the matching of the sizes.
Btrfs' RAID1 works bit differently. It ensures every block (1GB by default I believe) is present on two devices. So, if for example, you have 2x 1TB and 1x 2TB drive, you get 2 TB of usable space.
It is arguably not the most useful property in enterprise setting, but helps to stay on budget on home projects, since I can just use random drives laying around without any further requirements on the matching of the sizes.
I used to run FreeBSD in the '90s and beginning '00s. However, back then java wasn't supported properly and the overall tech world geared towards linux, and I switched to Debian.
Has anyone switched back to FreeBSD lately? And why?
Tried freebsd for a router because if into like this. Hardware support was lacking for my setup. It ended up being unstable and horrible. Replaced with Linux and it's been running smoothly since.
It is not early days anymore and we have given it a quarter of a century for these 'alternatives' OSes to do something on the desktop and it is still plagued with issues for just simple desktop usage.
This list of reasons here makes it easy for me and others to choose neither and tell users to just stick with either Windows or macOS (which macOS is a BSD Unix, but the users don't care and they should not).
Both FreeBSD and the trillions of GNU/Linux distros are still not ready for a simple desktop usage.
This is even before mentioning the in-fighting on swapping out system components like desktop environments, windowing systems, init systems, service, etc.
Neither Linux nor (especially) FreeBSD is primarily used on desktops. That’s a nice-to-have side feature (and one I’m personally grateful for, since I run Linux on my laptop now and have used FreeBSD desktop in the past), but the fact remains that it’s not the core value proposition of those OSes.
It’s no surprise that they’re not as nice on the desktop as OSes produced by corporations that pour billions into making them polished. I’m not sure why so many people expect them to be and get indignant when they’re not.
I'm 50 years old, now, so in college I had hands-on experience with a 3B2 running real live SVR3. There was also an academic VAX running 4.3BSD. And being closely tied to the UC system myself, I gradually became a BSD fanboy.
I started by putting Minix on my 286 at home, but I longed to run 386BSD. I eventually realized my dream with some nice OpenBSD installs. I was a partisan, not entirely a bigot, but I'd also seen Linux grow from infancy and considered it a toy or plaything, compared to mature BSD codebases. And truly, Linux was a hobbyist's choice for ages, but many hobbyists grow up to be professionals, don't they?
In 1999 (to prove I wasn't a bigot) I installed Linux on the old 386. It was either Slackware or Debian, and the reason I chose it was to support the floppy-tape controller that was unsupported by BSD.
I continued to use OpenBSD as a daily driver, alongside Windows, until 2004. Then a trusted sysadmin friend listened to my pleas for help with audio and assorted hardware, and simply directed me to Ubuntu. Since then I've been BSD-free (including no Apple devices.)
My needs over the decades have reduced from "godlike control-freak sysadmin" to "power user" to "does ordinary consumerist stuff on a Windows laptop". BSD has great technical reasons and use cases. If you still use BSD, more power to you! BSD's dual legacy for the world, even after the OS itself has evaporated, will be MacOS X and BSD's corporate-profit-friendly licensing terms.
Some more points:
- bhyve, developed by netapp, they ditched all old technologies support and it works faster on my i5 server than kvm on my i7 laptop. Snapshoting using ZFS is not a feature to discard either.
- FIBs, absolute miracle routing tables that you can apply to whatever software, define the routes as fib 1 (lets say it is openvpn) and then use them as simply as `setfib 1 bash` to use them in all child processes
- backward compatibility, this is where linux is really horrible, there was an article about compiling binary on freebsd 2 and running it on freebsd 10. Try this on linux, binaries are not compatible even on minor versions.
- jails... docker? Really? Jails are 15+ years old implementation, kernel supported, that stood test of time, actually being a security feature. It runs circles around the docker in everything except how much it was adapted by community. I never understood why people rather used an inferior solution like docker.
- not to mention all the chaos in linux ecosystem, in next sub-version, the commands can have completely different switches,...
I will never understand on what technical merits people are using linux for servers except the support-ability of hardware. Due to the whole show that linux is getting we would prosper as a humanity by ditching the linux. Unfortunately, marketing is worth more than anything.
(I do understand that people will not agree due to their preference, but try to use it. I doubt you will prefer linux ever again.)