Live data from Hacker News

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

unixsheikh.com

171–180 of 376 posts

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

#171
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…

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.

Comparing Linux to FreeBSD is like comparing a Mercedes to a custom-made trackday car.

Docker, kubernetes et all was the nail in the coffin.

BSDs are amazing for universities, OS classes and some outliers in the industry here and there.

The one thing FreeBSD had was network stack performance. Linux supports higher throughput for a while now.. so even that ship sailed.

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

#172
post #58
post #30

Earlier quoted context omitted.

Desktop Linux is pretty comfortable and intuitive, actually. There's no challenge involved.

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.

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.

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

#173
post #106

Earlier quoted context omitted.

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…

Can you quickly try and connect to my 4K 60Hz monitor without the whole room breaking into laughter?

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.

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

#174
post #149
post #108

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

> If you look at the kernel contributions, most of them are from people working for all the big names Like hardware manufacturers? I thought getting commercial users to contribute to the kernel was desirable? > For example, would these guys ever have approved the GPL-3? Didn't Torvalds himself reject GPL-3? > And in fact it's the very BSD license that makes big business shun FreeBSD Now I'm really confused. Why would…

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

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

#175
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

can't believe that openbsd dude is still updating that page.

he seems to be obsessed with an os he doesn't use.

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

#176
post #135
post #79

Earlier quoted context omitted.

SELinux is way more complex than security levels sounds here.

Securelevels are not just this. FreeBSD has its own SELinux equivalent called Mandatory Access Control: https://docs.freebsd.org/en/books/handbook/mac/ 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.

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

#177

Earlier quoted context omitted.

> the fact that nobody cares about BSD 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…

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

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.

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

#178
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…

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)

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

#179
post #132

Earlier quoted context omitted.

> Consider 'dd' for example 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 coreutil…

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

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.

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

#180

Earlier quoted context omitted.

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.
Post reply on HN