4 ms·

I don't get the argument about the separation between /usr/bin and /usr/local that FreeBSD does: why there should be a separation of concerns about the core sys

I don't get the argument about the separation between /usr/bin and /usr/local that FreeBSD does: why there should be a separation of concerns about the core system and the rest of the packages? In Linux distributions everything is installed by the package manager, and while it may be in different repositories (for example in ArchLinux you have core and extra) the packages are exactly the same, and the package manager maintains a database of all installed files. Do you want to remove all the "non core" stuff? You can easily do that with a command. Meanwhile /usr/local is retained for stuff that is not installed by the package manager of the distro, and thus it's not registered in its database. This will include for example binaries and libraries installed with other package manager such as pip, npm, etc, or things that you install with `make install`, that are not upgraded automatically. It generates a lot of confusion, for example some files are in /etc, some others are in /usr/local/etc, some other files are in both locations and you have to know which is the correct one. And who decides that is core and what is extra anyway? There is not a clear distinct definition, for example do you define as core only the software necessary to boot? Do you include system utilities? Compilers? Of which language? It's a mess!

kjellsbells 4y ago
Sounds like OP's assertion is that with 3rd party packages installing into /usr/bin, things are mingled to an extent that upgrades (even with a package manager) cannot be cleanly completed, and (perhaps?) disk partitioning can't be done effectively (eg in the case where your 3P app is an absolute disk hog). I personally accept the second claim more than the first. UNIX used to have stronger standards here (eg /opt, /opt/etc, /usr/local, and so on) but I'm not sure if Linux ever followed such standards. And disk partitioning seems to have gone the way of the dodo these days.
- alerighi 4y ago
  If everything is managed by the package manager, there is a database of files that are installed, and assuming the package manager works correctly it shouldn't create any problems. I use installations made 10 years ago and they are perfectly fine! Different is for software that is not installed by the package manager, that in Linux is typically installed in /usr/local (if we talk about stuff that is compiled, or installed by another package manager such as pip or npm) or to /opt (for proprietary applications distributed as a binary).
toast0 4y ago
So, in FreeBSD, the distinction is between base and ports/pkg +/- whatever else you install directly from the outside world (if anything?), in theory some vendor packages might install to /opt, but it's been a while since I saw that actually happen. >It generates a lot of confusion, for example some files are in /etc, some others are in /usr/local/etc, some other files are in both locations and you have to know which is the correct one. On FreeBSD, this is "simple"; if it comes in the base install, configuration files should be in /etc; if you had to install it, configuration files should be in /usr/local/etc. Now with regard to /etc/rc.conf, there's a lot of options on where to put additional configuration, and the combined configuration controls rc scripts run from /usr/local and /opt/. So that's not totally clear. > And who decides that is core and what is extra anyway? Well, the FreeBSD team does. > There is not a clear distinct definition, for example do you define as core only the software necessary to boot? Do you include system utilities? Compilers? Of which language? It's a mess! I'm not sure there's a clear definition written down anywhere, or frankly if a definition could be made that would be specific enough to be accurate while being general enough to change as time changes. In a nutshell, IMHO, FreeBSD base is enough software to be a somewhat useful system that can replicate itself, compile itself, and expand to fit the needs of the user. Not very many users will be satisfied with just base, but if your needs were small, maybe. Practically, FreeBSD base includes basic connectivity tools (ppp, dhcp/bootp client, bootp server, tftp client/server, ftp client/server, http client (fetch), ssh client/server, nfs client/server), a mail system, an editor, three shells, basic system utilities (cal grep, diff, etc), at least one pager (I don't think it always included less, but it does now), awk, a C/C++ compiler, BSD Make, a caching recursive resolver (unbound now, used to be BIND), tools to configure the kernel, and tools to do updates, install packages / ports, etc. No perl, no python, no bash, no gui, no nothing. If you want any of that stuff, you've got to install it yourself. The benefit of this separation is, again IMHO, the base system is small and compact and doesn't need to change very often. The basics you need to operate the computer are all there, and don't interfere (much) with the applications you probably actually want to install. With some exceptions, if the main application for you fits in the domain of something in base, you are actually likely to want a more feature filled option from elsewhere anyway; if you run a ftp server, you probably want more features; if you run a bootp server, well you probably actually want a dhcp server; some people like sendmail, but a lot of other people prefer postfix (and sendmail in base might be being replaced with something much simpler sometime soon, so if you wanted sendmail, you probably want that from outside base as well). If you want a webserver, that'll be from outside of base, and probably you'll want a language runtime to go with it. But if you need/want to upgrade the kernel and its accompanying software, you can probably upgrade base, and not disturb your applications in /usr/local (depending on versions, and how you upgrade, you may need to install a compat package to keep applications compiled for older versions of FreeBSD still running, and you may want to rebuild for the new version at some point). I dunno, it's a choice anyway.
catiopatio 4y ago
The base system is an integrated, supported, API and ABI stable, centrally documented, unified system. Everything else — that is, third-party software — is a package. It’s the exact opposite of a mess.

kjellsbells 4y ago

Sounds like OP's assertion is that with 3rd party packages installing into /usr/bin, things are mingled to an extent that upgrades (even with a package manager) cannot be cleanly completed, and (perhaps?) disk partitioning can't be done effectively (eg in the case where your 3P app is an absolute disk hog). I personally accept the second claim more than the first. UNIX used to have stronger standards here (eg /opt, /opt/etc, /usr/local, and so on) but I'm not sure if Linux ever followed such standards. And disk partitioning seems to have gone the way of the dodo these days.

alerighi 4y ago
If everything is managed by the package manager, there is a database of files that are installed, and assuming the package manager works correctly it shouldn't create any problems. I use installations made 10 years ago and they are perfectly fine! Different is for software that is not installed by the package manager, that in Linux is typically installed in /usr/local (if we talk about stuff that is compiled, or installed by another package manager such as pip or npm) or to /opt (for proprietary applications distributed as a binary).

toast0 4y ago

So, in FreeBSD, the distinction is between base and ports/pkg +/- whatever else you install directly from the outside world (if anything?), in theory some vendor packages might install to /opt, but it's been a while since I saw that actually happen. >It generates a lot of confusion, for example some files are in /etc, some others are in /usr/local/etc, some other files are in both locations and you have to know which is the correct one. On FreeBSD, this is "simple"; if it comes in the base install, configuration files should be in /etc; if you had to install it, configuration files should be in /usr/local/etc. Now with regard to /etc/rc.conf, there's a lot of options on where to put additional configuration, and the combined configuration controls rc scripts run from /usr/local and /opt/. So that's not totally clear. > And who decides that is core and what is extra anyway? Well, the FreeBSD team does. > There is not a clear distinct definition, for example do you define as core only the software necessary to boot? Do you include system utilities? Compilers? Of which language? It's a mess! I'm not sure there's a clear definition written down anywhere, or frankly if a definition could be made that would be specific enough to be accurate while being general enough to change as time changes. In a nutshell, IMHO, FreeBSD base is enough software to be a somewhat useful system that can replicate itself, compile itself, and expand to fit the needs of the user. Not very many users will be satisfied with just base, but if your needs were small, maybe. Practically, FreeBSD base includes basic connectivity tools (ppp, dhcp/bootp client, bootp server, tftp client/server, ftp client/server, http client (fetch), ssh client/server, nfs client/server), a mail system, an editor, three shells, basic system utilities (cal grep, diff, etc), at least one pager (I don't think it always included less, but it does now), awk, a C/C++ compiler, BSD Make, a caching recursive resolver (unbound now, used to be BIND), tools to configure the kernel, and tools to do updates, install packages / ports, etc. No perl, no python, no bash, no gui, no nothing. If you want any of that stuff, you've got to install it yourself. The benefit of this separation is, again IMHO, the base system is small and compact and doesn't need to change very often. The basics you need to operate the computer are all there, and don't interfere (much) with the applications you probably actually want to install. With some exceptions, if the main application for you fits in the domain of something in base, you are actually likely to want a more feature filled option from elsewhere anyway; if you run a ftp server, you probably want more features; if you run a bootp server, well you probably actually want a dhcp server; some people like sendmail, but a lot of other people prefer postfix (and sendmail in base might be being replaced with something much simpler sometime soon, so if you wanted sendmail, you probably want that from outside base as well). If you want a webserver, that'll be from outside of base, and probably you'll want a language runtime to go with it. But if you need/want to upgrade the kernel and its accompanying software, you can probably upgrade base, and not disturb your applications in /usr/local (depending on versions, and how you upgrade, you may need to install a compat package to keep applications compiled for older versions of FreeBSD still running, and you may want to rebuild for the new version at some point). I dunno, it's a choice anyway.

catiopatio 4y ago

The base system is an integrated, supported, API and ABI stable, centrally documented, unified system. Everything else — that is, third-party software — is a package. It’s the exact opposite of a mess.