Comment by mtlmtlmtlmtl | Hacker News Reader

Comment by mtlmtlmtlmtl | Hacker News Reader

Parent Full thread

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.

Reply on news.ycombinator.com