Live data from Hacker News

Technical reasons to choose FreeBSD over GNU/Linux (2020)

unixsheikh.com

231–240 of 376 posts

Re: Technical reasons to choose FreeBSD over GNU/Linux (2020)

#231

Earlier quoted context omitted.

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?

Re: Technical reasons to choose FreeBSD over GNU/Linux (2020)

#232

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.

Yeah, hypothetically, you can have FreeBSD userspace on top of Linux kernel, and GNU userspace on top of FreeBSD.

Re: Technical reasons to choose FreeBSD over GNU/Linux (2020)

#233
post #184

Earlier quoted context omitted.

> Didn't Torvalds himself reject GPL-3? 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?

Some googling around the issue suggests Linus pretty clearly rejects the principles of GPLv3. https://www.linux.com/news/why-torvalds-sitting-out-gplv3-pr...

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.

Re: Technical reasons to choose FreeBSD over GNU/Linux (2020)

#234
post #62

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…

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.

Re: Technical reasons to choose FreeBSD over GNU/Linux (2020)

#235
post #112

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…

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 so…

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?

Re: Technical reasons to choose FreeBSD over GNU/Linux (2020)

#236

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 bet…

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.

Re: Technical reasons to choose FreeBSD over GNU/Linux (2020)

#237

Earlier quoted context omitted.

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.

Re: Technical reasons to choose FreeBSD over GNU/Linux (2020)

#238
post #62

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…

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

Re: Technical reasons to choose FreeBSD over GNU/Linux (2020)

#239
post #17
post #7

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. https://vez.mrsk.me/freebsd-defaults.html

After reading all that I feel like the main danger in my house is a IDE drive with an old install of FreeBSD on it.

Re: Technical reasons to choose FreeBSD over GNU/Linux (2020)

#240

Earlier quoted context omitted.

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 F…

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

Post reply on HN