Live data from Hacker News

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

unixsheikh.com

151–160 of 376 posts

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

#151
post #116
post #106

Earlier quoted context omitted.

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.

If that's true then there's been substantial improvements on that front recently (which is good). As I recall, that was a tricky problem since your laptop screen likely runs another resolution, different DPI, etc so connecting to an additional screen makes things go haywire.

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

#152

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…

DragonflyBSD absolutely does not use the same kernel. It literally split off FreeBSD over kernel architecture differences.

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

#153
post #112

Earlier quoted context omitted.

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

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

So for a while GNU tar didn't support automatic compression detection, and you had to manually specify 'z' or 'j' every time. Quite annoying when you are used to bsdtar, which does this for you.

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

#154

One application where FreeBSD especially shines is as a fileserver to Windows clients: Unlike on Linux, NFSv4 ACLs are supported natively! The NT ACLs used in Windows and SMB are much more expressive than Linux's POSIX draft ACLs. When a Windows client writes a file to a Linux Samba server, it cannot necessarily express the file's ACL as a POSIX ACL losslessly. To work around this, Samba's vfs_acl_xattr saves the "re…

[deleted]

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

#155
Heterogeneous infrastructure was my main motivator to learn FreeBSD.

Without this diversity, in face of a security issue, you can only shut-down or take the risk.

On the other hand, when there’s a bug or suspicious activity on FreeBSD servers, you can turn off only those servers, while the problem is patched, and viceversa.

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

#156
post #53
post #41

Earlier quoted context omitted.

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

Who said anything about z/OS? There are other mainframes to chose from. In any case, in what concerns "modern" Web development, z/OS has you covered, https://www.ibm.com/products/open-enterprise-sdk-go-zos https://www.ibm.com/support/pages/java-sdk-products-zos https://www.ibm.com/products/sdk-nodejs-compiler-zos

What mainframes are still alive, apart from z/Architecture?

As for "modern Web development" - not really; it's a bit like running Apache and MySQL on Windows 98 - yes, you technically could, but you probably don't want to. Have you heard of anyone wilfully choosing to use mainframes instead of some Unix over the past two decades?

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

#157
post #139

Earlier quoted context omitted.

> jails... docker? Really? Jails are 15+ years old implementation, kernel supported, that stood test of time, actually being a security feature. It runs circles around the docker in everything except how much it was adapted by community. I never understood why people rather used an inferior solution like docker. Docker has Dockerfiles, layers, and trivial push/pull of images. Compared to those workflow improvements,…

I've had a decent time writing little "jailfiles" and a create/destroy script. It's certainly nowhere near as ergonomic as docker though. But it seems like a very solvable problem.

But, someone has to care enough to do so, and it has to catch on.

FreeBSD lacks the network effect.

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

#158
post #138

Earlier quoted context omitted.

> Keep in mind that Oracle is the copyright holder of ZFS. So you (and Ubuntu) are violating Oracle's license terms. If anything IS a problem here it is violating the terms of the GPL, not the CDDL. So no, no one is violating Oracles licensing terms - and if they were, they’d have been sued in 2016 when this shipped. Do you really think ORACLE of all people is just holding back out the goodness of their hearts? Compl…

> If anything IS a problem here it is violating the terms of the GPL, not the CDDL. How so? Aren't the GPL and CDDL both copyleft? > So no, no one is violating Oracles licensing terms - and if they were, they’d have been sued in 2016 when this shipped. Do you really think ORACLE of all people is just holding back out the goodness of their hearts? No, Oracle is holding back because they want more money. If they sue a…

>How so? Aren't the GPL and CDDL both copyleft?

They are, but GPL is (tl;dr) incompatible with anything that's not a subset of GPL. That's because GPL is viral, and CDDL isn't. And that's why in the Open Source world you can't get license incompatibility without throwing GPL in the mix.

So, yeah, it's GPL that's possibly being violated; CDDL is fine with whatever license there is. Oracle could sue you if they relicensed ZFS under GPL, but can't with CDDL because of implicit protection CDDL contains.

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

#159
post #158

Earlier quoted context omitted.

> If anything IS a problem here it is violating the terms of the GPL, not the CDDL. How so? Aren't the GPL and CDDL both copyleft? > So no, no one is violating Oracles licensing terms - and if they were, they’d have been sued in 2016 when this shipped. Do you really think ORACLE of all people is just holding back out the goodness of their hearts? No, Oracle is holding back because they want more money. If they sue a…

>How so? Aren't the GPL and CDDL both copyleft? They are, but GPL is (tl;dr) incompatible with anything that's not a subset of GPL. That's because GPL is viral, and CDDL isn't. And that's why in the Open Source world you can't get license incompatibility without throwing GPL in the mix. So, yeah, it's GPL that's possibly being violated; CDDL is fine with whatever license there is. Oracle could sue you if they relicen…

Isn't the whole reason that the CDDL is a problem that it is viral too? Otherwise you could just distribute the whole bundle of ZFS+Linux as GPL and be fine.

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

#160
post #88

This post is not very robust in its arguments: 1. vulnerability list is not very relevant as a measure if you don't relate to SLOC, features available or something ; 2. having a lot of configuration options for security is far from being good, security should be easy and by default; if the tradeoffs are unclear you enter FUD and avoid enabling them; is randomizing PIDs good? what are the downsides? :shrug: 3. I stopp…

About point 1, and not exactly SLOC, but the comparison is between Linux (a kernel) and FreeBSD (a full OS).

Now, it’s possible that the number of vulnerabilities are much higher in the Linux Kernel because there is more research interest due to its larger usage.

Post reply on HN