Live data from Hacker News

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

unixsheikh.com

331–340 of 376 posts

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

#331

Earlier quoted context omitted.

I've used OpenBSD as my desktop OS for the last 10 years or so. I agree it's probably not the ideal desktop OS for everyone, but I think your dismissal may be a bit too strong. You do need to be sure your desktop machine is well-suited for OpenBSD. This means supported Intel or AMD graphics (Nvidia won't work well if at all, and not all AMD will either) and network/wifi card.

Do you do a lot of customization, or use a special desktop environment, or do you stick with the base stuff?

I use awesome for a window manager. Other than that and a few color/font tweaks, it's pretty much stock.

https://awesomewm.org/

Most of what I do happens in a browser, terminal, or emacs.

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

#332

Earlier quoted context omitted.

Mate had to change all “Gnome” strings to “Mate” so both could be packaged/installed in parallel and probably also for legal reasons. This means all DBus interfaces need to use the new name, a nautilus plugin must now call caja functions instead and so on.

...huh, well that's frustrating! Could this be solved with a basic compatibility layer?

or decompile, touch strings, then recompile.

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

#333
post #306

Earlier quoted context omitted.

> basic stuff like wifi Wi-fi is not basic. Having written a wifi driver, that’s something I’m comfortable stating unequivocally. The hardware is almost always proprietary and undocumented, and in many cases (looking at you, Broadcom), a poorly-designed shitshow of complex errata, proprietary magic numbers required for initialization, and in general, an absolute dogshit technology stack. The only reason Linux has wor…

No true Scotsman OS needs WiFi so it's not a basic requirement of a complete OS.

[deleted]

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

#334
post #207

Earlier quoted context omitted.

It's not, CDDL explicitly states it doesn't apply to non-CDDL-ed source files. The problem is, GPL is claimed to be the other way around, so this would mean applying GPL to CDDL sources, and you can't do that, because CDDL gives you additional protections ("freedoms") GPL doesn't, and that's GPL-incompatible.

If I combined ZFS and the Linux kernel and licensed the result under the CDDL, I'd be violating the GPL. If I instead licensed the result under the GPL, then I'd be violating the CDDL. I'm not seeing how the licenses' differences actually cause an asymmetry here.

You can't "license the result", it's not your decision to make. GPL parts are GPL, CDDL parts are CDDL, BSD parts are BSD and so on. There's no problem with mixing code under different licences. That is, until GPL enters the picture - because GPL is viral, so it (at least according to FSF) claims the non-GPL parts too. It's not a problem for, say, BSD, because it's a subset of GPL[1], but it can be a problem with licenses that guarantee you more freedoms than GPL, like CDDL, Mozilla license, Apache, or even GPLv3.

1. And it used to be a problem with the old BSD, with the advertising clause, precisely because it wasn't a subset.

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

#335

Earlier quoted context omitted.

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…

I think one of the biggest mistakes the FreeBSD team made(in terms of more widestream adoption) was abandoning the Linux syscall table layer. It's still there, but it's stuck on 2.6.x last time I looked. It's a lot to maintain, yes, but it would help secure a lot more users like me, who are highly technical, potential contributors, who like a lot of the features(jails, better ZFS integration, easy to set up dtrace su…

>abandoning the Linux syscall table layer

Assuming you mean linux(4), http://man.freebsd.org/linux, it's absolutely not abandoned: https://wiki.freebsd.org/Linuxulator; it recently got a proper ARM64 support for example.

>"Linux jails" or something like that

https://wiki.freebsd.org/LinuxJails

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

#336

Earlier quoted context omitted.

What "voodoo"?

Stock docker puts entries in your iptables which usually fully bypasses your firewall. try installing docker on stock Ubuntu, run a container with an exposed port, put ifw up blocking all traffic, and the container is still going to be reachable.

That's not voodoo, that's perfectly reasonable behaviour.

Why are you wasting time with ipfw?

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

#337
post #134

Earlier quoted context omitted.

So who are these companies? I hear references to them constantly, but pretty much the only ones willing to stick their head above the parapet are Netflix (in a single use case) and a few storage/network vendors using proprietary forks.

I would scream if I ever saw a dude in a suit give some 70's looking NEET permission to base their company's entire IT platform on FreeBSD specifically. It'd be like switching all your office workstations from MacOS to Ubuntu or Linux Mint.

why? it's a valid decision to make.

Linux is turbulent and uncoordinated. FreeBSD is the opposite of that.

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

#338
post #292
post #262

Earlier quoted context omitted.

IBM i, Unisy ClearPath and OS/2200, related offerings, now you can feel pedantic and differentiate which of them are proper mainframes, which are mini, microcomputers or whatever. We are discussing technicalities here, the whole point started about Linux isn't the only way to have access to such called "modern" Web tools. Technically they exist in any UNIX environment, mainframes (or whatever you feel like calling th…

>IBM i, Unisys ClearPath and OS/2200 Once again, have you seen anyone technical wilfully choosing any of those for web stuff over the past two decades?

Wilfully or not, they offer such capabilities in 2022, and there are people paying for their use, probably many more people than some obscure UNIX clones that still exist out there.

And again, this whole thread started with what is possible outside Linux, and apparently I touched a nerve with you, apparently related to your FreeBSD role, let it go.

FreeBSD, IBM i, Unisys ClearPath and OS/2200, or flavour of the month UNIX clone, are all miles behind Linux distributions for Web development on compute centers, if you insist in counting ammo.

So better spend your contribution time in more productive discussions.

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

#339
post #335

Earlier quoted context omitted.

I think one of the biggest mistakes the FreeBSD team made(in terms of more widestream adoption) was abandoning the Linux syscall table layer. It's still there, but it's stuck on 2.6.x last time I looked. It's a lot to maintain, yes, but it would help secure a lot more users like me, who are highly technical, potential contributors, who like a lot of the features(jails, better ZFS integration, easy to set up dtrace su…

>abandoning the Linux syscall table layer Assuming you mean linux(4), http://man.freebsd.org/linux , it's absolutely not abandoned: https://wiki.freebsd.org/Linuxulator ; it recently got a proper ARM64 support for example. >"Linux jails" or something like that https://wiki.freebsd.org/LinuxJails

Awesome! Looks like they've picked up speed with it, that's great to see. Not sure if the abandonment was originally a misperception on my part or whether they picked it up again, maybe pulling code in from SmartOS? Either way the wiki says compatibility is up to 4.4 on CURRENT and 3.2 on STABLE. Still a ways to go, but that's sounding like I might have to give FreeBSD a go again!

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

#340
post #313
post #222

Earlier quoted context omitted.

Works on my machine, anecdotally; no Wayland, and an X window manager that hasn't been updated in a decade. Automatically resizes windows when I drag them to fit each monitor's DPI settings.

Btw, does it allow you to run different scale on the different monitors? It wouldn't really be feasible to run native 4k resolution on one monitor if everything will be tiny, so it needs to have scale. One monitor might run on 1x and the other 2x.

Yes, it does, as I said in the comment above. It resizes windows according to their DPI settings, to keep a consistent scale.
Post reply on HN