Live data from Hacker News

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

unixsheikh.com

101–110 of 376 posts

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

#101
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 better compatibility and support with software and hardware in general imho

Edit ps: I use gentoo so I see the power of ports but I can match it with the wider support of Linux

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

#102
post #81
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…

> It runs circles around the docker in everything except how much it was adapted by community. ...except? Meh. People who want to engage in this argument are generally trying to argue about jails vs. the collection of linux container technologies. That's not Docker. Docker won because of Dockerfiles. Docker isn't, at its core, an interesting container technology. Docker is a simple metaphor and programming environmen…

More detailed comparison of Docker Vs Jails :

https://www.diva-portal.org/smash/get/diva2:1453017/FULLTEXT...

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

#103
post #70
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…

> backward compatibility, this is where linux is really horrible, there was an article about compiling binary on freebsd 2 and running it on freebsd 10. Try this on linux, binaries are not compatible even on minor versions. What a completely bizarre claim. I have commercial linux/x86 binaries from the 90s that work perfectly well on my current PC running Linux 5.15.

I had trouble trying to run libc5 era software a few years ago. This wasn't the kernel but the distro did not make it easy. I wouldn't expect them to keep maintaining libc5 packages 20+ years later either.

I think if you do anything GUI-ish over the last 20 years there's been many shared library breaking changes. But that'd be true of FreeBSD too since those dependencies are just the same when they live in ports.

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

#104

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…

> The flag is called in-place for a reason. What's the reason? Surprisingly, the file is never edited in place.

OK, I'll give you that the underlying sycscalls are in fact creating a temporary file. But the abstract result to the user is an in-place edit.

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

#105
I've gotten good enough at Linux to where I don't need to constantly look stuff up after long periods of use, but not FreeBSD.

Which is why I love FreeBSD so much. It's consistent, clearly explained, thoroughly documented, powerful, and flexible. I have a home server (just upgraded to 13.1) that I go months at a time without logging in. And while I do tend to forget a lot of important details, looking them up is incredibly easy.

I don't really care about what software FreeBSD uses, just that it is consistent and well-documented.

Plus, the whole architecture of it fits comfortably in my head. It is so nice to reason about.

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

#106
post #58

Earlier quoted context omitted.

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.

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?

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

#107

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…

I agree that BSD coreutils are extremely feature poor (e.g. no PCRE in grep) and have some odd syntax choices as you point out, but you can always install the GNU coreutils. Of course, you then have to prefix everything with “g” (e.g. ggrep, gsed) which can get annoying.

That said, this is why I’ve always given up on BSD every time I’ve tried it—all of the low-level technical benefits touted in the article never actually make a difference in my day-to-day usage, whereas little annoyances with the userspace really add up.

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

#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 charge of the kernel officially but all the steering groups are dominated by big tech. Look at the Linux Foundation for instance: https://www.linuxfoundation.org/board-of-directors/ . These are not the kind of people you'd expect to lead 'free software', these are all boardroom types. Maybe Linux has outgrown the beardy hacker culture but I have not :P

Of course, Linux is not much worse for it... Yet. I think this is for 2 reasons: Linus' benevolent dictatorship, and the fact that they won't be able to agree on much given that these guys are all competitors. But in the long term I'm sure this will take its toll. For example, would these guys ever have approved the GPL-3? Everyone in business is pretty universally against it.

And in fact it's the very BSD license that makes big business shun FreeBSD. Which I think is a good thing. FreeBSD still feels like a grassroots development and as such I feel more in control. The excellent and consistent documentation and friendly community is another plus for me. And the combination of stable OS with rolling third-party software (but this is something that was also mentioned in the article). ZFS on Root is another one (though Ubuntu is now catching up to that).

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

#109
post #57
post #37

how does the kernel compare these days? pre-cfq i remember the scheduler was far better than linux, but what about raw performance for single and multithread/process workloads with lots of i/o going through the kernel? raw cve counts seem meaningless without a denominator to me. those numbers should be normalized by estimated install base if they're going to be compared.

Yeah, the number of BSD CVEs just boils down to the fact that nobody cares about BSD. Since nobody cares about it, its performance is also very 20-years-ago and doesn't stand up to modern linux performance. You could expect database performance (e.g. postgresql) to be 2-4x higher on linux under a highly concurrent load. There are thousands of full-time professionals around the world focused on linux performance and t…

[deleted]
Post reply on HN