I don’t share the opinion expressed in the article and think that /etc is a good place for init scripts. We don’t need even more folders, we actually need fewer, and most init-scripts are configuration expressed in code (Nobody complains that e.g. the Lua-configuration files for awesome, which are executable programs, are also stored in /etc). We should start discussing the removal of many folders that are just there for historical reasons or with questionable roles (e.g. /usr/, /usr/local/, /sbin, etc.) or have a very slim difference in meaning (/var vs. /tmp, not even beginning with /var/tmp/ etc.).
The approach taken with sta.li is a very good one (/usr is symlinked to /, /sbin is symlinked to /bin, /tmp is gone, etc.) and it makes a lot of sense.
Using /usr/bin to store user-space-tools and /bin only for system tools sounds like a good reason why it was split, but actually it was only split because hard drives back then couldn’t store everything in one filesystem (which is why /usr was externally mounted). The other “motivation” to allow the users (single-user or multi-user-systems alike) to have their own binaries somewhere also doesn’t work, given you usually can’t change anything outside of /home without root anyway. And being able to see sbin-binaries in your $PATH as a normal user is also no big deal, as it usually already is in the $PATH anyway.
All in all, I see these issues as much more important than the very nitpicky differentiation between “real” configuration files and executables acting as configuration.
Given that etc and libexec both exist already (as they do at least on OpenBSD and Slackware), I don’t see this as an argument for more directories. The argument is that etc is for local configuration while rc.d isn’t intended for that at all.
I think there’s merit to your less-not-more position; I just think it’s beside the point here.
We don’t need even more folders, we actually need fewer
I agree, thats why I love nixos. Still has /etc but its a lot less stuff than base linux. Why get rid of /tmp? What is $TMPDIR set to? What happens to scripts that expect /tmp? Seems a weird piece of unix heirarchy to remove.
We don’t need even more folders, we actually need fewer
I think you mean “directories,” the world “folders” is a Windows and Mac term. (Half-joking!)
There’s a lot of interesting history around the organization of the Unix filesystem. Most of us have read that /usr was originally invented because the PDP-11 (or whatever) that Unix was run on back in the day had a full /home disk and users needed more space and the convention carried over. But that doesn’t mean /usr is a completely userless concept today, it just has a different purpose.
But a lot of people miss the point that today’s BSDs and Linuxes are general purpose operating systems. That is, they are designed to fit an enormous variety of different (and sometimes conflicting) use cases. The “messiness” of the filesystem is an inevitable outcome of this. The good news is that once you have your system installed, it’s often trivial to customize it to your specific needs. This is a strength not a weakness.
For example, if there’s no practical difference between /var/ and /tmp to you and the applications you run, you are free to do away with one or the other. But for me personally, this is a good example of an area where I’m happy to have the distinction because I consider everything in /var to be persistent OS-level system state while everything in /tmp should be thought of as ephemeral and will be deleted the next time the host is rebooted. As a sysadmin, this distinction has proven useful many times over the years.
On all of my servers, I create a separate filesystem and directory called /data where application data is stored. This volume can be unmounted and moved somewhere else, or the system can be upgraded in-place without touching the application data. However my workstations all have just one (logical) disk and the whole system lives on one big root partition. Nothing important is ever permanently stored on them so that if (when) things go sideways, I can just reimage the whole machine and be back up and running in an hour or less.
But rc.conf.local is the only configuration file an administrator touches, and it never conflicts with changes to the rc scripts under rc.d nor the default configuration found in rc.conf.
I’ve occasionally written my own rc.d scripts, but have never needed to modify an existing one provided by the base system or packages (any configuration I would want to do would be in the daemon flags in rc.conf.local).
I’m not sure where we disagree. You’ve just described the situation that led the author to suggest rc.d doesn’t belong in etc. The best case I can muster against that view is as you describe, that a local administrator might want to write a script and drop it in rc.d, but most will just use rc.local for that.
rc.conf.local exists becuase it’s generally not wise for local administrators to modify rc.d.
The crux of the issue as I understood it is that (on netbsd) rc.conf is both used to modify configuration, and is also touched by system upgrades, and therefore can create merge conflicts. With OpenBSD splitting out this local configuration into a separate file only touched manually by the user or with rcctl, there are never merge conflicts here, or to any of the rc infrastructure (unless you changed a system/package rc.d script I suppose).
How about removing important things … like sendmail(8) for example … or incorporating more usable replacements like importing ZSH shell alongside the oldschool and HORRIBLE FOR SCRIPTING (T)CSH shell.
OpenBSD addresses both of your points. The default shell is ksh which is fine for scripting (and interactive use), and hasn’t included sendmail in ages.
I don’t share the opinion expressed in the article and think that /etc is a good place for init scripts. We don’t need even more folders, we actually need fewer, and most init-scripts are configuration expressed in code (Nobody complains that e.g. the Lua-configuration files for awesome, which are executable programs, are also stored in /etc). We should start discussing the removal of many folders that are just there for historical reasons or with questionable roles (e.g. /usr/, /usr/local/, /sbin, etc.) or have a very slim difference in meaning (/var vs. /tmp, not even beginning with /var/tmp/ etc.).
The approach taken with sta.li is a very good one (/usr is symlinked to /, /sbin is symlinked to /bin, /tmp is gone, etc.) and it makes a lot of sense.
Using /usr/bin to store user-space-tools and /bin only for system tools sounds like a good reason why it was split, but actually it was only split because hard drives back then couldn’t store everything in one filesystem (which is why /usr was externally mounted). The other “motivation” to allow the users (single-user or multi-user-systems alike) to have their own binaries somewhere also doesn’t work, given you usually can’t change anything outside of /home without root anyway. And being able to see sbin-binaries in your $PATH as a normal user is also no big deal, as it usually already is in the $PATH anyway.
All in all, I see these issues as much more important than the very nitpicky differentiation between “real” configuration files and executables acting as configuration.
Given that etc and libexec both exist already (as they do at least on OpenBSD and Slackware), I don’t see this as an argument for more directories. The argument is that etc is for local configuration while rc.d isn’t intended for that at all.
I think there’s merit to your less-not-more position; I just think it’s beside the point here.
I agree, thats why I love nixos. Still has /etc but its a lot less stuff than base linux. Why get rid of /tmp? What is $TMPDIR set to? What happens to scripts that expect /tmp? Seems a weird piece of unix heirarchy to remove.
There are more basic problems with traditional Unix file system layout. The OS related should be all read-only.
I think you mean “directories,” the world “folders” is a Windows and Mac term. (Half-joking!)
There’s a lot of interesting history around the organization of the Unix filesystem. Most of us have read that
/usrwas originally invented because the PDP-11 (or whatever) that Unix was run on back in the day had a full/homedisk and users needed more space and the convention carried over. But that doesn’t mean/usris a completely userless concept today, it just has a different purpose.But a lot of people miss the point that today’s BSDs and Linuxes are general purpose operating systems. That is, they are designed to fit an enormous variety of different (and sometimes conflicting) use cases. The “messiness” of the filesystem is an inevitable outcome of this. The good news is that once you have your system installed, it’s often trivial to customize it to your specific needs. This is a strength not a weakness.
For example, if there’s no practical difference between
/var/and/tmpto you and the applications you run, you are free to do away with one or the other. But for me personally, this is a good example of an area where I’m happy to have the distinction because I consider everything in/varto be persistent OS-level system state while everything in/tmpshould be thought of as ephemeral and will be deleted the next time the host is rebooted. As a sysadmin, this distinction has proven useful many times over the years.On all of my servers, I create a separate filesystem and directory called
/datawhere application data is stored. This volume can be unmounted and moved somewhere else, or the system can be upgraded in-place without touching the application data. However my workstations all have just one (logical) disk and the whole system lives on one big root partition. Nothing important is ever permanently stored on them so that if (when) things go sideways, I can just reimage the whole machine and be back up and running in an hour or less.Isn’t this problem solved in OpenBSD by rc.conf.local?
Nope. OpenBSD has both rc.conf.local and rc.d.
But rc.conf.local is the only configuration file an administrator touches, and it never conflicts with changes to the rc scripts under rc.d nor the default configuration found in rc.conf.
I’ve occasionally written my own rc.d scripts, but have never needed to modify an existing one provided by the base system or packages (any configuration I would want to do would be in the daemon flags in rc.conf.local).
I’m not sure where we disagree. You’ve just described the situation that led the author to suggest rc.d doesn’t belong in etc. The best case I can muster against that view is as you describe, that a local administrator might want to write a script and drop it in rc.d, but most will just use rc.local for that.
rc.conf.local exists becuase it’s generally not wise for local administrators to modify rc.d.
The crux of the issue as I understood it is that (on netbsd) rc.conf is both used to modify configuration, and is also touched by system upgrades, and therefore can create merge conflicts. With OpenBSD splitting out this local configuration into a separate file only touched manually by the user or with rcctl, there are never merge conflicts here, or to any of the rc infrastructure (unless you changed a system/package rc.d script I suppose).
That may be an issue; I don’t think it’s germane to the OP at all.
How about removing important things … like sendmail(8) for example … or incorporating more usable replacements like importing ZSH shell alongside the oldschool and HORRIBLE FOR SCRIPTING (T)CSH shell.
OpenBSD addresses both of your points. The default shell is ksh which is fine for scripting (and interactive use), and hasn’t included sendmail in ages.
I really like OpenBSD approach in many places, but currently FreeBSD offers more for my needs (even with the downsides).
I really need these: