But then you get things like Esperanto. Esperanto takes about 1/4 of the time to learn compared to other languages. It’s taught in China and used as primary language in some settings. But, aside from a large number of people learning some Esperanto from Duolingo several years ago, it’s just another language now to have to learn.
Mac OS?
macOS is certified Unix, and necessarily implements the "legacy" cruft.
Tinycorelinux
I know that it doesn't follow the best user practices etc. but I did find its tcz package format fascinating because they kind of work similar to mountable drives and I am not exactly sure but I am fairly certain that a modern package management system where two or more packages with conflicts etc. can run on the same system.
I really enjoyed the idea of gobolinux as well. I haven't played with that but it would be good if some more mainstream os could also implement it. Nix and Guix are more mainstream but they also require to learn a new language and I think that we might need something in the middle like gobo but perhaps more mainstream or adding more ideas / additions perhaps? I would love it if someone can tell me about some projects we are missing to talk about and what they add on the table etc.
I haven't tried Gobo though so I am not sure but I really wish more distros could add features like gobo, perhaps even having a gobofied debian/fedora eh?
Edit: Oh haha, this article was posted 13 years ago and there was a similar thread which is how I dug up that link... https://news.ycombinator.com/item?id=5944594
(FWIW, Fedora 17 was released in 2012.)
Nowadays most end users just use /usr/local or /opt/local or whatever is managed by Homebrew or Macports.
Well...
battlestation : ls /opt/
homebrew local
battlestation : tree /opt/local
/opt/local
└── lib
└── libgeos_c.dylib -> /opt/homebrew/lib/libgeos_c.dylib
2 directories, 1 file
But, I in a way int kind of makes sense.
/bin and /sbin, needed for system boot. /usr/bin and /usr/sbin for normal runtime.
's' for items regular users do not need to run, remember, UN*X is a multi-user system, not a one person system like macs, windows and in most cases Linux.
Nowadays most Linux systems boot with initramfs, that is a compressed image that includes everything the system needs to boot, so you're basically saying /bin and /sbin is useless.
Not always (raise your hand if you've had an unbootable system due to a broken or insufficient initrd).
In retrospect, the whole concept of the initrd seems like an enormous kludge that was thrown together temporarily and became the permanent solution.
What seems bad about it to you? Initrd means you only need /boot (or equivalent) to be working at boot time, which seems nice to me. And looking at mine, the image is smaller than the kernel, so it's not wasting a ton of space.
Sure it could be blamed on shitty distro maintenance and development but a better architecture would be putting essential things like filesystem drivers in /boot without this extra kludge of rebuilding an initrd (that you hopefully didn't forget to do before typing reboot) which depends on a pile of config files set just right (and oh by the way different in literally every distro).
Rebuilding an image isn't a big factor there, it's a tradeoff between making setup a bit more annoying versus making it a bit easier to manage your boot files.
Eh, kinda. That's where "essential" .ko modules are packed into - those that system would fail to boot without.
Alternative is to compile them into kernel as built-ins, but from distro maintainers' perspective, that means including way too many modules, most of which will remain unused.
If you're compiling your own kernel, that's a different story, often you can do without initrd just fine.
this is the reason in my opinion and experience
as a lead dev in a rather complicated environment I tended to solve the problem many times where some identifier was used. short deadlines and no specification made us solve the problem quickly, so some shortcuts and quick actions were done. this identifier gets asked about later and super overcomplicated explanations given as a reason by people that don't know the history.
...and the history is often like 'they mounted stuff to /usr because they got a third drive'. and now, people even in this thread keep giving explanations like it's something more.
I think the only other I can think of like this is probably nix or spark and nix really wants to learn a new language so it has some friction but nix is a neat idea too
I think not many people know this but how tinycore packages work are really fascinating as well and its possible I think to have this as well by just downloading the .tcz and manually running it since it actually mounts the code to a squashfs mount loop, I am not familiar with the tech but removing applications and adding them can be just about as easy as deleting and adding files when one thinks about it.
Does anybody know some more reference pointers to a more smooth/easy way of not having to deal with dependency management etc.
I think that mise for programming languages is also another good one. Appimages/zapps are nice too for what they are worth. Flatpak's a little too focused on gui section for my liking though. Its great that we have flatpak but I dont think its just the right primitive for cli applications that much
https://itsfoss.gitlab.io/post/understanding-the-linux--usr-...
`man file-hierarcy` defines modern Linux filesystem layout.
https://www.man7.org/linux/man-pages/man7/file-hierarchy.7.h...
Also the first URL is serving me scam popup ads that do a crap job at pretending to be android system alerts. Next time please try to choose a more reputable source.
And I thought we just got over the systemd drama…
Speaking of things which are needlessly complex, I'm reminded of this classic post on the tortured history of the browser User-Agent header:
https://webaim.org/blog/user-agent-string-history/
Highly recommended!
2. “Then somebody decided /usr/local wasn't a good place to install new packages, so let's add /opt”
Not exactly. /usr/local exists so you don’t accidentally mess up your distro/package manager by changing its files. It’s “local” to your installation. But it is still structured — /usr/local/bin, /usr/local/lib, etcetera — divided into binaries, shared libraries, manpages.
Whereas /opt has no structure. It’s “the wild west”…application binaries, libraries, configuration, data files, etcetera with no distinction. Apps with “universal” packaging, or sometimes secondary package managers.
For example /usr/local/bin is normally part of PATH, but /opt is not (unless eg homebrew adds it to your bashrc).
I'm guessing it was introduced to finally move out all the (mostly system) binaries from /etc, which in ancient Unix from Bell Labs in the 1970s really meant "etc", as in stuff that didn't fit elsewhere rather than system config files, so it contained binaries like init, mount, umount.
same for /var/ or wherever you store your DB tables like MySQL.
Practically in this century if I was starting a new OS I would set it up like so:
/bin for all system binaries. Any binary from a package installed by the OS package manager lived here.
/lib same but for shared libraries
/var for variable data. This is where you would put things like your Postgres data files.
/tmp for temporary files.
/home as usual.
/dev as usual.
/boot as usual
/etc as usual
/usr would be what /usr/local is on most systems. So /usr/bin is binaries not installed by the OS package manager. /usr/etc is where you put config files for packages not installed by the package manager and so on.
Get rid of /usr/local and /sbin.
/media replaces /mnt entirely (or vice versa).
Ditch /opt and /srv
Add /sub for subsystems: container overlays should live here. This would allow the root user (or a docker group, etc.) to view the container file system, chroot into it, or run a container on it.
Then again, nobody gave me a PDP-11 to decide so my vote doesn’t count :)
This one never sat well with me. I think of /var as temporary data, something I can lose without much consequence. But never data files. I know it's the default, but still.
/srv I like because it seems like a proper place to separate server-related data, i.e. /srv/wwwroot or similar. But if you like /var, that of course would be the place for this type of data.
/var is data that needs to be writable (/usr/*, /bin and /lib may be readonly), and that might be important. Like databases, long-term caches, mail and printer queues, etc.
If a system is intended to serve data on a network (file shares, databases, websites, remote backups, etc), /srv is where the requisite data for those things should live. I think that's a good idea.
> This directory contains subdirectories which are used as mount points for removable media such as floppy disks, cdroms and zip disks. https://specifications.freedesktop.org/fhs/latest/media.html
/var is used for websites and databases, but defaults for most packages don't use /srv by default. (I have the feeling that /srv is relatively new.)
Along p_ing's lines I'd rename /var to something else, possibly not /srv because it's not just for servers, but it could be /data
My understanding is that sbin for system binaries, not necessarily statically linked. Normally /sbin is only in root's PATH, not normal user's. They are likely world executable, but in many cases you cannot actually run them as non-root since they usually touch things only root can access without special access (e.g. raw devices, privileged syscalls, /etc/shadow etc.). Not always though, like you can run /sbin/ifconfig as normal user in read-only mode.
I think that became the rationale for /[s]bin vs. /usr/[s]bin (although based on the linked article, that may have been retconned a bit).
You were supposed to keep your root/boot filesystem very small and mostly read-only outside major updates. That meant that you could boot to a small amount of utilities (e.g. fsck) that would let you repair /usr or any other volume if it became corrupted.
I think the other poster is correct that stuff like fsck is supposed to go into /sbin because it is a "system" binary (but also statically linked since /usr/lib isn't mounted yet) and doesn't make sense to have in user $PATHs since nobody other than root should really be running that one.
Regardless, this is all deeply meaningless these days, particularly if you are running "ephemeral" infrastructure where if anything goes that wrong you just repave it all and start over.
Since Linux has no concept of a base system, it's a stand-alone kernel with a hodgepodge of crap around it - this distinction makes no sense on Linux.
/opt is generally for software distros for which you don't have source; only binaries. Like commercial software packages. More common on Real UNIX(R) because most Linux users outside enterprise aren't running commercial software. You're putting your $500k EDA software under /opt.
The Linux base system is managed by the package manager, leaving local for the sysadmin to `make install` into
There is no such thing as a Linux base system.
Separate components, separate people.
Hence the term Ganoo plus Leenox...
Every occasion I’ve seen GNU coreutils installed on BSD, it’s been outside of the base and thus installed outside of /bin. Eg /usr/local or /opt/homebrew
In most distributions yes, there is Linux and then there is userspace on top of it. What you call "base system" is actually part of userspace, which has nothing to do with Linux itself.
Steam says hi.
On Windows, a common Steam library exists in Program Files directory, therefore not user specific. On Linux, each user has a separate Steam installation and library. I'm not sure why there isn't a common Steam library on Linux, but /opt would be a good place for it.
No reason this can't be done on Linux but since NT's security model is more flexible it's a lot easier to do so on Windows. You'd need to add dedicated users. (Running a Steam daemon as root would probably cause an uproar.)
Developers who knowingly reduce or disable default Windows security settings should be censured. Because in 99% of cases it is due to ignorance or plain laziness.
It doesn't "reduce or disable default Windows security settings" in a meaningful way if you say to yourself "that folder effectively is in ProgramData, but spelled wrong".
You should never hardcode the path since it can and has moved around, though MS has implemented hard links to legacy paths because most developers are stupid and against persistent better advice do it anyway. I've seen multi-million dollar software packages whose vendor requires it to be writable by "Everyone".
Steam was first released in 2003, three years later.
For 80% of grievances about Windows, there is likely a solution in place that no one knows about because they didn't read the documentation.
And it's the same permissions either way. This isn't about permissions, it's about where they put the folder.
But Windows XP, which came out in 2001, inherited everything from Windows 2000 and more, and was used extensively for gaming.
They didn't stop advertising Win98 support until sometime in early 2007.
Granted, Steam back then was a different creature than Steam now.
[1] https://web.archive.org/web/20020605222619/http://www.steamp...
It's also assumed that its contents can be safely restored from original sources, so Program Files is often not backed up - because it's wasteful and not needed.
Rogue developers thinking they know better than the people who actually designed the system and ignoring the rules put in place is the source of an untold number of problems in the software world. It's absolutely stupid and I have no empathy for the problems caused as a result of their laziness. This attitude is why modern Linux is a complete clusterfuck, a free-for-all with components duct taped together every which way. Do it right or don't do it at all.
The save files don't go in the steam folder, they go into per-user Documents or AppData.
The actual solution, which remains both compatible and consistent with the security model, is that you should have to be administrator and pass UAC to install a game, just like you do to install anything else.
Regarding "that's a Linux-ism" - well yeah? Linux is the main OS this is about. FreeBSD can do what it wants, too.
That's a Linux-ism. Other *nix there is a lot more in /usr/local.
In reality /usr is similar to Windows' System32 directory on most Unicies.
/opt is really the only good place for Java and where I've been putting it for decades (old habits die hard).
See, you assume here that /usr/local/ makes any sense.
I use a versioned appdir prefix approach similar to GoboLinux. So for me, /usr/local never ever made any sense at all. Why should I adhere to it? I have ruby under e. g. /Programs/Ruby/4.0.0/. It would not matter in the slightest WHO would compile it, but IF I were to need to store that information, I would put that information under that directory too, perhaps in a file such as environment.md or some other file; and perhaps additionally into a global database if it were important to distinguish (but it is not). The problem here is that you do not challenge the notion whether /usr/local/ would make any sense to begin with.
> /opt is generally for software distros for which you don't have source; only binaries.
Makes no sense. It seems to be about as logical as the FHS "standard". Why would I need to use /opt/? If I install libreoffice or google chrome there under /opt, I can as well install it under e. g. /Programs/ or whatever hierarchy I use for versioned appdirs. Which I actually do. So why would I need /opt/ again?
You’re presenting your comment as a rebuttal but you’re actually arguing something completely different to the OP.
They’re talking about UNIX convention from a historic perspective. Whereas you’re talking about your own opinions about what would make sense if we were to design the file system hierarchy today.
I don’t disagree with your general points, but it also doesn’t mean that the OP is incorrect either.
The BSD ports explanation is a bit revisionist I hate to say, this all predates ports.
It was a location in a second stage mount you knew the upstream wouldn’t overwrite with tar or cpio. Later ports used it to avoid the same conflict.
* e.g. exempli gratia (or, in Spanish, ejemplo gratis)
* i.e. id est (literally means "that is")
"some" is an understatement.
The ports tree will still be very different from base, but I feel this may erode some of the difference between FreeBSD and a typical Linux distro in terms of user experience, with respect to base vs ports. You'll update both with pkg.
Good grief. How does this end up as the top comment on HN of all places? I'll bet anything that this author also thinks that systemd is way too opinionated and unified and that the system needs a less coupled set of init code.
Edit to be at least a tiny bit more productive: the Linux Filesystem Hierarchy Standard is about to pop the cork on its thirty second birthday. It's likely older than most of the people upvoting the post I responded to. https://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard
To wit: that's outrageous nonsense, and anyone who know anything about how a Linux distro is put together (which I thought would have included most of the readers here, but alas) would know that.
[0]: https://www.psychologytoday.com/us/blog/thinking-makes-it-so...
char string[10000];
strp = string;
for (i=0; i<9; i++)
*strp++ = "/usr/bin/"[i];
p = *argv++;
while(*strp++ = *p++);
// string == "/usr/bin/foo"
execv(string+9, args); // foo (execv returns only in case of error, i.e. when foo does not exist)
execv(string+4, args); // /bin/foo
execv(string, args); // /usr/bin/foo
Latter, if desired, the system, could override those libraries with another ones (newer compatible or patched), more thinking is needed about this. The key, from the process point of view, would to limit the access of such process to their own directories and some very limited system only local services by default,
And to extend this permissions, each binary in such directory would need to be in companion of a permissions request file that would require the approbation from the user or the system defaults patterns (each distro would have a point of view I guess), in the aim of improve process isolation and system, drivers, services access permissions.
This would need also restructure the console philosophy, how can manage the processes, and so on, that would need a big restructuration.
I mean, anyway people is duplicating space with containers trying to isolate process, remark in trying.
I know this is unrealistic due the deep change it would suppose, so consider I'm just thinking out loud.
PS: If you answer it already exists with AppArmor, SELinux, etc, then you did not understood the root of the issue with such modules.
So the /bin /sbin became redundant.
Sometime around 2020 someone observed that no current Linux can boot without /usr anyway. So what did they do? Move everything from /usr to / and drop the whole /usr legacy? Noooo, that would be too simple. Move / to /usr. And because that is still too simple, also move /bin, /sbin and /usr/sbin to /usr/bin, and then keep symlinks at the old locations because who's gonna fix hardcoded paths in 99% of all Linux apps anyway??
Oh, how I wish I was born in the '60s, when the world was still sane.
As one who was, I find it makes the current world even harder to accept. Be careful what you wish for.
It's a lot simpler to merge them in a directory that can be mounted across multiple machines than have four separate mountpoints.
Nearly every shell script starts with "#!/bin/sh", so you can't drop /bin. Similarly, nearly every python script starts with "#!/usr/bin/env python", so you can't drop /usr/bin.
Hence symlink.
busybox in Alpine Linux has for example `ps` builtin. If you install ps with `apk add ps` to get the full version, it will remove the symlink for /bin/ps and replace it with the one you installed.
You need to read up on the purpose of busybox. It is not something that the kernel people has decided upon. It is an initiative of an group of people who needed some tools onto a single floppy.
/bin/ps on a Debian distro is 154522 bytes. The whole busybox in Alpine Linux is 804616 bytes and contains a whole lot more than just ps.
> merge-usr is a script which may be used to migrate a system from the legacy "split-usr" layout to the newer "merged-usr" layout as well as the "sbin merge".
> It is required for systemd ≥255 due to changes upstream, but it remains optional for other init systems.
Slapping it down as "FHS is now a standard" does not change anything. People will ask why it is suddenly a standard when it hasn't made any sense at all whatsover. bin versus sbin is also pointless. Inertia is one primary reason why nobody fixes things usually.
We'll skip PDP-7 UNIX, no hierarchical file system yet.
UNIX v1 on the PDP-11 had an RF11 fixed head disk (1mb) for / and swap, and an RK05 moving head disk (2.5mb) for /usr (the user directories)
By v2 they had added a second RK05 at /sys for things like the kernel, manual pages, and system language stuff like the c compiler and m6.
By v3 they added yet another RK05 at /crp for, well, all sorts of crap (literally), including yacc apparently. /usr/bin is mentioned here for the first time.
I don't feel like looking up when sbin was first introduced but it is not a Bell Labs thing. possibly BSD or AT&T UNIX? Binaries that one would normally not want to run were kept in /etc, which includes thing like init, mount, umount, getty, but also the second pass of the assembler (as2), or helpers like glob. Also i don't know when /home became canonical but at Bell Labs it was never a thing (plan 9 has user directories in /usr where they had always belonged logically).
The lib situation is more difficult. Looks like it started with /usr/lib. By v3 we find the equivalent directory as /lib, where it contains the two passes of the C compiler (no optimization pass back then), C runtime and lib[abc].a (assembler, B, C libraries respectively). /usr/lib had been repurposed for non-object type libraries, think text-preparation and typesetting.
By v4 the system had escaped the labs (see the recent news) and at that point everyone modified the system to their taste anyway. Perhaps it should be noted that the v7 distribution (which is the first that is very clearly the ancestor of every modern UNIX) has no /usr/bin, only /bin. /lib and /usr/lib are split however.
These are just some rough notes and due to a lack of early material they're still not as accurate as i would like. Also UNIX ran on more than one machine even in the early days (the manuals mention the number of installations) so there must have been some variation anyway. Something I'd like to know in particular is when and where RP03 disk drives were used. These are pretty huge in comparison to the cute RK05s.
I am also totally adding a /crp directory to my next system.
Doesn't being under $HOME make .local redundant? I guess one could argue for binaries going in an architecture-specific subdirectory if $HOME was on a shared filesystem, but that's not what's being done here.
To me, $HOME/.local/share and its siblings are just a needless level of indirection, forcing me to jump through an extra hoop every time I want to access what's in there.
(I know it's sometimes possible to override it with an environment variable, but the predictably spotty support for those overrides means I would then have to look for things in two places. I think sensible defaults would be nicer.)
This would match the more recent $HOME/.var that's in widespread use via Flatpak.
It is Microsoft thing. You must pollute the user's /home as much as you can. Can i say that i have 3 daemons on my computer respobsible for ... credentials. This is the way to go.
For me this was an eye-opener. I kept trying to wrap my head around all these different paths and "standards" because I thought it was correct and deliberately designed. Looking back through the history this doesn't seem to be the case; I feel much better for being confused by all the different PATH conventions and strict hierarchies.
jagged-chisel•19h ago
Additional info: many rules from many places are now in force that maintain the historical structure.