Hacker News Reader

Comment by stingraycharles | Hacker News Reader

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.

View on HN

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.

> It's a lot to maintain, yes, but it would help secure a lot more users like me,

What an understatement. The modern Linux syscalls are tightly coupled to the implementation of Linux. Special fds, io_uring, robust lists, etc etc …

There’s a reason why Microsoft said fuck it and run Linux in a VM for WSL2.

If you want Linux, just run Linux.

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.

Thanks for not calling me an idiot, at least.

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.

[1]: https://www.mnxsolutions.com/triton-faq

Awesome! Joyent had some really neat tech, I was sad to see them gobbled by Samsung.

>abandoning the Linux syscall table layer

Assuming you mean linux(4), http://man.freebsd.org/linux, it's absolutely not abandoned: https://wiki.freebsd.org/Linuxulator; it recently got a proper ARM64 support for example.

>"Linux jails" or something like that

https://wiki.freebsd.org/LinuxJails

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.

I mean, it does work… I use it to run stuff like istioctl and rke on my fbsd workstation no problems…

Is cuda support decent on BSD?

Drivers for niche stuff seem like they would be an issue as well.

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.

I'm still holding out hope that Intel will put out a decent dGPU with a strong ML story within a few gens, with gloriously open source drivers.

Recent news coming out of Intel the last week or so haven't been encouraging though. But I will remain a dreamer.

AMD is probably a better bet with ROCm although it's still pretty spotty right now in regards to support.

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.

Perhaps VHS vs Betamax is a suitable equivalent to FreeBSD vs Linux.

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.

and because jails has such low adoption, there will be fewer identified issues. Unlike docker, so many people use it, they will find many issues.

Reply on news.ycombinator.com