Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

unixsheikh.com

Post reply on HN
Print view View original

41–50 of 376 posts

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

#41

Post by trasz »

pjmlp wrote: post #12
jagged-chisel wrote: post #2

How well does FreeBSD support a “modern” web backend? Does Java run here? Mono (C#)? Node.js? PostgreSQL? Any noSQL databases?

I guess calling POSIX modern is a point of view, unless a language runtime is bound to Linux specific syscalls, any UNIX like OS will run "modern" web backends. From that point of view, you can even do "modern" web backends on IBM and Unisys mainframes, using their POSIX environments. And yes, they do actually support everything on that list, by the way, mainframes invented noSQL databases before SQL was a thing, hav…

Very, very few things depend on Linux-specific syscalls. There are two reasons for this: first, they are unportable, so you need another code path for everything !Linux anyway, and even when you only care about Linux you can't assume those syscalls are available, because you first need to get them into the kernel, then into glibc, which is a separate project, and then you need to ship them in the distro, which in some cases (RHEL) means either waiting half a decade or porting it to a kernel half a decade old.

And no, there aren't many things you can run on z/OS POSIX environment, because it fails to support absolutely basic things, like fork(2).

>mainframes invented noSQL databases before SQL was a thing

I'm not sure about this; structured storage was popular before Unix made flat files common, but there was a fundamental flaw in how it was implemented: it was all in the kernel, not on top of it.

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

#42

Post by 1-6 »

deano wrote: post #17
alberth wrote: 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

You can find a Linux distro for everything these days though.

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

#43

Post by trasz »

ArrayBoundCheck wrote: post #3

AFAIK I and most people can't run it due to freebsd not supporting our hardware. Does it support intel wifi and GPUs? (I'm using an amd GPU). Can I run netflix or prime and get 1080 resolution? (note on linux I need to use a addon to achieve this)

Yes, it does support Intel WiFi and GPUs, and in some cases (all GPUs, more and more WiFi) it uses code borrowed from Linux. For Netflix you'll need to run Linux Chromium or Firefox using linux(4) (https://docs.freebsd.org/en/books/handbook/linuxemu/), because of widevine.

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

#44

Post by shaw00000 »

bxparks wrote: post #20

I have tried learning FreeBSD occasionally, mostly for nostalgia because I learned Unix on BSD 4.3 (or 4.4?) on MicroVaxes many years ago. But I get stuck on some very basic things: - My wifi card doesn't work. The installer recognizes it, but the driver doesn't work. - The console terminal defaults to 80x25, I don't know how to resize it. - I can't figure out how to start X Windows. - If I run it in a VM (e.g. Virtu…

FreeBSD, OpenBSD and NetBSD are for servers, appliance servers and embedded devices mostly. You can use them as a desktop, but that's not where their strengths are. If you want to learn or use FreeBSD in this case I strongly suggest setting up a home server and learn as much as possible.

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

#45

Post by cperciva »

5e92cb50239222b wrote: post #39
cperciva wrote: post #31

Earlier quoted context omitted.

The recent WireGuard debacle left a bad taste about this. As it actually turns out, sometimes there is zero technical review for very important patches and a few blessed developers can (and sometimes do) just throw their stuff directly into trunk. This seems like a misunderstanding of the FreeBSD development model. Yes, immature code landed in HEAD, but it was removed before the next release . In general in FreeBSD t…

Thanks for clarification. Although IIUC the "bad" WireGuard implementation was stopped from being released just barely : https://lwn.net/Articles/850098 It was rushed because a particular vendor wanted to have it as soon as possible. If not for Jason Donenfeld's diligence it looks like we would have out there in the open, full of bugs and all. Doesn't seem like a normal occurrence though, seeing how much noise it mad…

The WG code was introduced unusually late, I agree. Usually experimental stuff like that lands soon after a .0 release so that there's a year to iron out details before the next release. But this is a quantitative difference -- how close to the next release do you push experimental code into the tree -- not a qualitative difference.

And fundamentally the system worked! The code was deemed to not be ready and was yanked before the release.

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

#46

Post by RamRodification »

jester23947 wrote: post #22
bxparks wrote: post #20

I have tried learning FreeBSD occasionally, mostly for nostalgia because I learned Unix on BSD 4.3 (or 4.4?) on MicroVaxes many years ago. But I get stuck on some very basic things: - My wifi card doesn't work. The installer recognizes it, but the driver doesn't work. - The console terminal defaults to 80x25, I don't know how to resize it. - I can't figure out how to start X Windows. - If I run it in a VM (e.g. Virtu…

read the handbook... it's the second chapter in this webpage.

...or pick an operating system where you don't need to read the handbook to get working WiFi.

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

#47

Post by sgarland »

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've found over the years, but those come to mind as annoyances.

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

#48

Post by aaron_m04 »

cperciva wrote: post #31
5e92cb50239222b wrote: post #13

Let me pick and choose a few points since replying to everything will necessitate a similar 40-page post. FreeBSD has great engineering and release management practices When someone gets an idea and develops something new, it first gets peer technical reviews The recent WireGuard debacle left a bad taste about this. As it actually turns out, sometimes there is zero technical review for very important patches and a fe…

The recent WireGuard debacle left a bad taste about this. As it actually turns out, sometimes there is zero technical review for very important patches and a few blessed developers can (and sometimes do) just throw their stuff directly into trunk. This seems like a misunderstanding of the FreeBSD development model. Yes, immature code landed in HEAD, but it was removed before the next release . In general in FreeBSD t…

> (Yes, Netflix runs FreeBSD HEAD. I think they're nuts.)

Sounds like chaos engineering to me ;)

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

#49

Post by ahepp »

gray_-_wolf wrote: post #40

I've considered migrating my NAS to openbsd few times, but one thing I was not sure about is with that to replace the filesystem with. I'm currently running btrfs and I like it. Few things I would like to have in a replacement: 1. copy-on-write and snapshots 2. checksums that are automatically verified on reads 3. btrfs' version of RAID1 (meaning I don't have to buy identical HDDs only) What would be my options?

I believe zfs fulfills all those requirements.

I’m running freebsd on my NAS and it’s been great.

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

#50

Post by 5e92cb50239222b »

pdimitar wrote: post #34
5e92cb50239222b wrote: post #13

Let me pick and choose a few points since replying to everything will necessitate a similar 40-page post. FreeBSD has great engineering and release management practices When someone gets an idea and develops something new, it first gets peer technical reviews The recent WireGuard debacle left a bad taste about this. As it actually turns out, sometimes there is zero technical review for very important patches and a fe…

> Most services on my machines are heavily locked down and isolated from each other since systemd makes this very easy Do you have a guide handy? A quick Google search only showed generic nonsense. I'll appreciate a recipe-like pointer. Been curious about this for a while.

I haven't seen any decent articles on this (doesn't mean there aren't any) that mention anything besides most basic flags.

Have a gander at the comment I linked (https://news.ycombinator.com/item?id=29976096).

---

Probably the easiest way to start is to create your unit file as usual, copy the list from the comment into it, and then run:

  $ systemd-analyze security unit-name
It prints a huge list of suggestions along with a short description of each one. Look up their names in here:

  $ man systemd.directives
and look at the man linked there. Usually it's one of

  $ man systemd.exec
  $ man systemd.resource-control
I think the starter list should get you 95% there (I use it for most applications with minor variations in paths and flags like MemoryDenyWriteExecute that breaks JIT compilers).

---

If you want to keep your configuration as short as possible, the list with the most bang for your buck would look something like this:

  User=non-root-username

  # disable privilege escalation through SUID binaries
  NoNewPrivileges=yes
  CapabilityBoundingSet=

  # removes access to /home
  ProtectHome=yes

  # makes most paths read-only
  ProtectSystem=strict

  # opens read-write access only to paths your application needs
  ReadWritePaths=/var/lib/foo /var/lib/bar
If your application follows FHS and writes stuff to /var/whatever, prefer:

  RuntimeDirectory=appname
  StateDirectory=appname
  CacheDirectory=appname
  LogsDirectory=appname
  ConfigurationDirectory=appname
instead of

  RuntimeDirectory=/var/run/appname
  StateDirectory=/var/lib/appname
  CacheDirectory=/var/cache/appname
  LogsDirectory=/var/log/appname
  ConfigurationDirectory=/etc/appname
Post reply on HN