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.
Technical reasons to choose FreeBSD over GNU/Linux (2020)
111–120 of 376 posts
Re: Technical reasons to choose FreeBSD over GNU/Linux (2020)
#112Not 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 something on HP-UX CC lol). MacOS' tools are also different.
If you expect things to be GNU, use GNU/Linux. Or Hurd :) Or install GNU coreutils.
Re: Technical reasons to choose FreeBSD over GNU/Linux (2020)
#113Not 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…
> 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 coreutils, and either alias them or move PATH priority so they get called first.
Re: Technical reasons to choose FreeBSD over GNU/Linux (2020)
#114Earlier quoted context omitted.
> 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…
I love FreeBSD and i love Jails, but you're right. Docker won because of simplicity. Dockerfiles make it super simple. There is similar stuff for jails but you need a jails frontend that use it. A few years ago i wanted to build the Jailfile equivalent, call it Warden, and have Warden manage the jails. But honestly i doubt it would get traction outside a small community.
CBSDfiles, reggae and bastillebsd can all build jails from a file based method
Re: Technical reasons to choose FreeBSD over GNU/Linux (2020)
#115despite all the Linux users defending their operating system (they should, Linux is great) based on past experiences, I still prefer FreeBSD when possible. it just feels ... like a complete thing, rather than an assembly of different things. it makes sense to me.
the article mentions this, and when I started typing I thought I could do a better job of explaining, but as I typed I realize that I could not.
it just feels better to me. it may not feel better, or even good, to any of you, and that's (of course) fine with me. I just like FreeBSD.
I think FreeBSD deserves far more attention than it gets, and I am therefore quite happy to see this article on HN, even if others can't see why it's a valid option for anything they need.
Re: Technical reasons to choose FreeBSD over GNU/Linux (2020)
#116Earlier 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?
Anecdotally, as a user of a different distribution and desktop environment, yes. Just Works.
Re: Technical reasons to choose FreeBSD over GNU/Linux (2020)
#117I have a server running FreeBSD 13.1-RELEASE and the experience is kind of mixed. Things from the top of my head in no particular order:
- I like the idea of "kern_securelevel", but I can only use it on the low setting (1 out of 3) because the machine (VM) is sometimes powered off and its time gets de-synced. The server is running ntpd but on this security level you're not allowed to change time by more than a second.
- ntpd doesn't support running with ASLR enabled. Fortunately, you can disable ASLR for a particular process with "proccontrol".
- ASLR is not enabled by default. Not that it cannot be defeated but it's a basic security measure, isn't it?
- User installed packages put their configuration into "/usr/local/etc/". Or more generally user level stuff goes to "/usr/local". I like that, keeps things more tidy.
- Upgrading between major versions requires several reboots. You also have to reinstall / recompile all of your installed packages / ports because ABI can change between versions.
- IPv6 didn't work out of the box because the standard DHCP client doesn't support DHCPv6. Getting it to work took me a while but works now with the use of rtsold.
- pf is nice. Enabling pflog and then inspecting the logged traffic via standard tools such as tcpdump is handy.
- In line with UNIX philosophy, each utility does one thing and one thing only. I find it quite annoying though when dealing with long running services. There doesn't seem to be a standardized way of monitoring once a particular service is started via rc. Some packages use daemontools, some use something else (I forget the name), and some don't do any monitoring at all. Similarly with logging. I very much prefer systemd in this regard.
- Jails are cool but annoying sometimes. Jails are created from a particular version of FreeBSD and you have to keep them up to date with "freebsd-update" like a regular host (including the reboot dance). There's a way to share most of the files between jails using mount_nullfs but I haven't tried that.
- I miss "journalctl --since=-5hours" every time I ssh into the machine. Not sure how I could do it with just plain log files without parsing their specific format.
Re: Technical reasons to choose FreeBSD over GNU/Linux (2020)
#118Earlier quoted context omitted.
This is the same for me. ZFS native boot environments and such is a killer feature that I am envious of. Also proton gaming seems to be best supported on Linux from what I can tell.
ZFSBootMenu provides boot environments for Linux. The now defunct Project Trident, formerly PC-BSD and then TrueOS, had a gui installer that sets you up with - ZFS on root install of essentially void Linux - rEFInd with a kernel sufficient just to boot into - ZFSBootMenu which lets you boot into a prior boot environment - ZFS native encryption of /home per user directory set up to unlock when you log in via PAM and z…
this i did not know thank you for sharing!
I've not got zfs on root on my fedora 36 install but if i did this is something i'd seriously look into
Re: Technical reasons to choose FreeBSD over GNU/Linux (2020)
#119I 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…
From a technological perspective, everything you say is true, and FreeBSD is better in so many regards. But, compatibility and community support is just a deal breaker. The jails vs docker argument is a good example: while technically better, Docker (or rather, cgroups and image distribution) have been standardised and have tremendous community adoption. FreeBSD cannot tap into any of this at all. Yes, jails might be…
Perhaps VHS vs Betamax is a suitable equivalent to FreeBSD vs Linux.
Re: Technical reasons to choose FreeBSD over GNU/Linux (2020)
#120how 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…
> 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 Linux, like Linux users are known for crapping on everything that is not Linux.