5 ms·

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,

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.

fuckstick 4y ago
> 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.
- mtlmtlmtlmtl 4y ago
  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.
  - fuckstick 4y ago
    - mtlmtlmtlmtl 4y ago
      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"?
  - jeremyjh 4y ago
    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.
    - mtlmtlmtlmtl 4y ago
      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.
      - nwilkens 4y ago
        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 https://www.mnxsolutions.com/triton-faq
galangalalgol 4y ago
Is cuda support decent on BSD? Drivers for niche stuff seem like they would be an issue as well.
- mtlmtlmtlmtl 4y ago
  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.
  - galangalalgol 4y ago
    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.
    - mtlmtlmtlmtl 4y ago
      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.
      - scheme271 4y ago
        AMD is probably a better bet with ROCm although it's still pretty spotty right now in regards to support.
    - mtlmtlmtlmtl 4y ago
      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?
      - galangalalgol 4y ago
cyberpunk 4y ago
I mean, it does work… I use it to run stuff like istioctl and rke on my fbsd workstation no problems…
trasz 4y ago
>abandoning the Linux syscall table layer Assuming you mean linux(4), http://man.freebsd.org/linux http://man.freebsd.org/linux, it's absolutely not abandoned: https://wiki.freebsd.org/Linuxulator 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 https://wiki.freebsd.org/LinuxJails
- mtlmtlmtlmtl 4y ago
  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!
  - trasz 4y ago
    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.

fuckstick 4y ago

> 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.

mtlmtlmtlmtl 4y ago
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.
- fuckstick 4y ago
  - mtlmtlmtlmtl 4y ago
    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"?
- jeremyjh 4y ago
  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.
  - mtlmtlmtlmtl 4y ago
    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.
    - nwilkens 4y ago
      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 https://www.mnxsolutions.com/triton-faq

galangalalgol 4y ago

Is cuda support decent on BSD? Drivers for niche stuff seem like they would be an issue as well.

mtlmtlmtlmtl 4y ago
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.
- galangalalgol 4y ago
  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.
  - mtlmtlmtlmtl 4y ago
    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.
    - scheme271 4y ago
      AMD is probably a better bet with ROCm although it's still pretty spotty right now in regards to support.
  - mtlmtlmtlmtl 4y ago
    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?
    - galangalalgol 4y ago

cyberpunk 4y ago

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

trasz 4y ago

>abandoning the Linux syscall table layer Assuming you mean linux(4), http://man.freebsd.org/linux http://man.freebsd.org/linux, it's absolutely not abandoned: https://wiki.freebsd.org/Linuxulator 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 https://wiki.freebsd.org/LinuxJails

mtlmtlmtlmtl 4y ago
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!
- trasz 4y ago
  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.