Hacker News Reader

Comment by aaron-lebo | Hacker News Reader

It's really not just a rationalization. BSDs control the kernel and the userland, meaning that file system layout is coherent. Check any Ubuntu installation and packages are all over the place. This is perhaps unavoidable.

Also, OpenBSD, DragonflyBSD, and FreeBSD can all be used as server or desktops without much fiddling. Their installers are better than anything in the Linux world. You can have one up and running with a nice wm, browser, etc, in 15 minutes.

They are more finnicky about hardware, but when you can buy a laptop for $200, that's not so much an issue.

View on HN

+1 on the BSD installers being some of the best out there. OpenBSD's and FreeBSD's specifically are amazing, both for different reasons.

OpenBSD's is very minimal simple ASCII input and output questions with sane defaults.

FreeBSD offers a console dialog based approach similar in some ways to Debian's installer, but in other ways different (and to my mind, better).

Both of them will get you efficiently setup from nothing to installed within minutes, and since they are very simple and well documented, both of them are easily scriptable for installing servers or laptops quickly with a specific setup or your own prompts.

By contrast, linux installers are generally larger, slower, clunkier processes and I am not sure how easy it would be to integrate any random distribution's installer into a scripted workflow.

I don't think the layout is coherent at all. Ubuntu layout is much more coherent. If I need nginx configuration I look in /etc/nginx. Following the same pattern if I need mysql configuration I look in /etc/mysql. If I need to figure out the actual daemon configuration for each I look in /etc/init. It's all very nice and tidy. Actual binaries go in /usr/local/bin or /usr/bin or /bin. That's pretty much all I need to know for any binary or daemon. This is not true in FreeBSD. So where exactly is the incoherence?

It isn't actually as nice and tidy as it would seem because you do not have a direct separation between system configuration and application configuration.

It's a small, subtle detail that for many is less important today than it once was; however, if I have two FreeBSD systems of mostly equal versions and I want to migrate applications and/or users from one to the other, I know ALL I have to do is copy from /usr/local -- try that on your Ubuntu machine. Good luck separating the system-specific configurations from your user and application configurations.

I don't want that separation in a consistent and coherent system. User vs base is artificial. What I care about is the end result the overall system accomplishes and base vs non-base doesn't really factor into that. What does it matter to me if nginx is part of the base system or not? I need a web server. Arbitrarily choosing apache/httpd vs nginx to include as part of the base system is incidental complexity where I stand from.

> User vs base is artificial.

No. It's not.

If nginx releases an update, do you also need to update your OS? No, because the user dependency graph isn't shared with the base OS.

If you update your OS, do you also need to update nginx? No, because there's backwards ABI compatibility.

The split is not artificial.

You're talking about kernel vs userland. That's not base vs non-base. The BSD distributions unintentionally muddy the waters by calling what is an equivalent of a linux distribution a base system and so lose out on the distinction you are drawing.

No, I'm talking about the Operating System vs. Applications.

Drawing the line at the kernel syscall ABI is arbitrary; no other major operating system other than Linux does so.

Consider how difficult it is to ship 3rd-party applications for Linux and all its myriad of distributions; the only thing you can truly rely on is the anemic syscall ABI provided by the kernel (vs. userland).

Hmm, I've never had any problems running something on ubuntu, debian, gentoo, redhat, etc. If it works on one then it works on all the others. If push comes to shove I just install the libraries and compile from source but this is a rare occurence and I've only have had to do that when I've relied on a version of Ruby or Python that has not come pre-packaged with the distribution.

So I don't really know what you're getting at. If you're not talking about kernel vs userland and you're talking instead about ABI compatibility then the ABI is even more stable and requires even less work to port any piece of software from one distribution to another.

> If you update your OS, do you also need to update nginx? No, because there's backwards ABI compatibility.

Only for minor versions. How is that different from any other package that promises ABI compatibility?

Why are FreeBSD OS components split up at a low granularity, so you can't install the stuff you want without the stuff you don't?

Why are there two separate sets of tools to update them and other packages?

edit: Why separate non-base packages from base packages on the filesystem, but not from each other? If the advantage of separating /usr/local is the ability to copy the non-base configuration/apps without the base stuff, wouldn't it be more useful to be able to copy any given individual package or set of packages? Or if that is possible already (by asking the package manager for a list of files or whatnot), wouldn't that obviate the need to separate base from non-base?

> ... non-base packages ... base packages ...

FreeBSD does not work this way. You are projecting Linux onto it.

Florian Haas apparently disagrees.

* https://hastexo.com/blogs/florian/2016/02/21/containers-just...

* https://plus.google.com/+FlorianHaas/posts/4xjQP1q6DEN

This is an increasingly solved problem in the post-systemd world - /etc contains local configuration, system configuration is in /usr. We (CoreOS) support you doing mkfs on / in order to return to a default configuration built from the /usr config.

If that's your definition, then FreeBSD and Solaris solved this without paying the systemd tax, via ZFS-based boot environments.

https://www.freebsd.org/cgi/man.cgi?query=beadm&sektion=&man...

NeXt->Apple also avoided anything like systemd via a configuration system that supported inheritance across search domains (User, Local, Network, System):

https://developer.apple.com/library/mac/documentation/Cocoa/...

Oh, there's certainly multiple ways to do this. My point is purely that this isn't an inherent Linux/*BSD thing - there are modern Linux distributions that have precisely this property.

And isn't it actually part of the same effort (RH Stateless Linux) which spawned systemd and ostree ?

This is something I actually like about systemd and firewalld, everything in /usr/lib/systemd/ and /usr/lib/firewalld should only be handled by your package manager, anything you customize yourself belongs in /etc/systemd/ and /etc/firewalld, and they will override the corresponding entries in the 'global' folders if you give them the same filename.

FreeBSD is quite coherent. Anything not part of the base system goes into /usr/local.

If you're having trouble understanding the layout of the filesystem, you only have to man hier: http://www.freebsd.org/cgi/man.cgi?hier(7)

But I thought BSDs where more monolithic and coherent systems. How is drawing a distinction between base system and non-base system make that true? If anything Linux embodies that philosophy much better. There is no ad-hoc and arbitrary decision between what is part of the base system and what is not. The system as whole is coherently laid out without drawing any base/user distinctions. Daemons are daemons, binaries are binaries, tools are tools, configuration is configuration and they all go in predictable places to become part of the overall system.

Have you read the article? It isn't an ad-hoc distinction. You get the base system with a FreeBSD install. It includes the kernel and everything else that makes it a "FreeBSD system". This is stuff maintained by the BSD team. Everything else is an add-on.

If you blew away /usr/local, you would be left with a pristine (mostly) BSD install.

An analogy is a base windows install and all the associated tools and drivers. Anything else you install on your own is an add-on.

This distinction is hardly arbitrary.

Edit

Seems to me you have a hard time understanding what a "base system" means. This is what the article is trying to explain, and it seems to have gone completely over your head; I can't help with that.

I read the article. The distinction is indeed arbitrary. How much do you need for a base system really? Do you need more than the kernel, network drivers, and the filesystem? Last time I checked FreeBSD came with way more than those things. So someone, somewhere decided to include a whole bunch of other things as part of the base whereas they could just as easily be addon packages. I think FreeBSD includes various compilers and perl by default. Why's that? How is a compiler an essential part of a system? There are no apriori reasons to make certain "addons" part of the base system and others not. Linux does not draw this distinction and reaps the benefits of a more coherent system.

The equivalent of "base system" in linux land is called a distribution and rightfully so. There is nothing basic about a distribution. It is an arbitrary set of choices made by the distribution maintainers and it is sold/advertised as such.

I think the easier way to think about the base system is to look at Mac OS X. Stuff in the /usr are installed along with the Mac OS X system, and when people need other packages (or think some packages that shipped as part of the system is too old), they use their favorite package manager to install it to /usr/local or somewhere outside /usr. This is also the case with FreeBSD base system. The package manager do not manage packages that are installed as a part of the system, only the one installed by the user.

As far as the compiler goes, in my 10.3-RELEASE-p5, I can only see clang 3.4.1. No Python, no Perl, no even Bash. If I happen to need clang 3.8, I can just `pkg install clang38` and it will happily live inside /usr/local separate from the one in /usr/bin (that is probably presented for building the world). This one will be managed by pkg, but the one in /usr/bin will be updated when I upgrade to 11.0-RELEASE (which will ship with 3.8).

Thinking in Linux's terms, is probably like installing Debian stable only the minimum, and use pkgsrc to install the rest of the system to /opt.

You get the base system with a FreeBSD install. It includes the kernel and everything else that makes it a "FreeBSD system". This is stuff maintained by the BSD team. Everything else is an add-on.

This is why I typically find Debian to be a more cohesive system than FreeBSD. If I could run only the base system, or only the base system plus maybe one or two packages, FreeBSD would have a very good story about being developed in a unified, coherent way. But in practice I need a bunch of stuff from ports, and on FreeBSD that much more clearly falls into the "everything else is an add-on" category. There's relatively little integration testing or attempts to make the software in ports do things in a coherent "FreeBSD-style" way; it's a bunch of third-party software delivered mostly as-is. Whereas Debian considers anything in the 'main' Debian repository part of the official release, subject to release-management and integration testing, and ensures it works in a more or less "Debian way". Whether that matters depends on your use case, but for me that makes Debian feel more like a unified system.

I'm thinking mostly about servers here fwiw. On desktop the base/applications distinction works better for me, so I could run "FreeBSD" as a coherent base system and then install some separate applications on top of it, which is all fine. But on servers I prefer the coherent base system to be more "batteries included", including integrated release management of all the major libraries and software packages I'm likely to need. If I deploy on "Debian 8" vs. "FreeBSD 10", for example, the former gives me a much larger set of stable components that work together in a reasonable way, while the latter leaves me to more DIY it outside of the relatively small base system. (Whether this matters of course depends on what you're building.)

> If I need to figure out the actual daemon configuration for each I look in /etc/init.

... except that that was Ubuntu two major versions and some time ago, back when it used upstart. Nowadays, Ubuntu Linux is a systemd operating system.

* https://freedesktop.org/software/systemd/man/file-hierarchy....

Whenever I hear "BSD" I always think: "if you want to use BSD you have to build a machine for it". This isn't really based on any real world experience, but whenever BSD comes up as a topic only thing that sticks with me is: "it only likes very specific hardware" which makes me very hesitant to ever consider trying it. I've had so many hardware incompatibility problems with Ubuntu, which is suppose to support almost everything, I don't even wanna think about trying to run BSD.

Hardware can actually be a mixed bag between BSD and Linux. In my experience (which is several years dated by now), BSDs seemed to do better with various less popular WiFi chipsets.

I remember having trouble with wifi chipsets ~5-6 years ago when smaller netbooks started to hit the scene. I had one of thous, like 8" laptops with brand new ARM chip and 4 hour battery life, for it getting wifi working was hard, but after that I haven't had much trouble with wifi, but maybe I've just been lucky.

It's strange, I have heard lots of people complain who wanted to give Linux a try (over Windows) and ran into hardware issues.

On the other hand, over the last ~15 years, I have almost never checked if a piece of hardware is supported by Linux (or BSD) before buying it, and I have only run into problems twice, really. One was an Aureal Vortex sound card for which a driver was maintained outside the Linux kernel tree, so I had to download it and build the module manually; the other was a really crappy HP scanner. Ironically, these days it does work on Linux much better (meaning: at all) than on Windows. (One key factor, though, seems to be not using brand-new hardware. After a year or so, chances are much* better it is supported properly.)

Apart from that, I have had no problems at all. Maybe I was just really lucky.

GPUs have been the pain of my Linux existence, everything else is generic enough to work, but last time I tried Ubuntu the default settings manager crashed at the mere sight of my GPU and when I installed a differed WM either couldn't find the resolutions I wanted to run or they didn't stick around after booting. After messing around with some "xorg-edgers" drivers I ended up with machine which claimed it had no displays anywhere and I just gave up and installed Windows.

It always seems to be one thing or another. Either it's some program/service I use daily that doesn't work (or doesn't quite work as well as I know it can) or it's some strange issue with sound or most likely GPU

> Also, OpenBSD, DragonflyBSD, and FreeBSD can all be used as server or desktops without much fiddling. Their installers are better than anything in the Linux world. You can have one up and running with a nice wm, browser, etc, in 15 minutes.

When I wanted to try FreeBSD the installation failed multiple times and after the first success I couldn't install a DE for hours. I've also had problems with the package manager because I couldn't install anything before doing something with some configuration files. OpenBSD is the same category but at least it doesn't failed at installation as much.

Reply on news.ycombinator.com