Hacker News Reader

Comment by koehr | Hacker News Reader

So they take the MacOS file structure to Linux? Sounds horrible to me. I always loved the structure of the Unix file system. It's simple and rather efficient. You wonder if a specific binary is installed? Look in /bin. You wonder if where to configure something? Look in /etc. You want to write a program that gives you a list of all binaries installed (like a shell)? Use the path variable that contains a few paths and check their contents. In gobolinux this variable is either huge or they use yet another mechanism. It clearly will not get better though.

The file structure should be efficient for the computer and can be abstract for the user as they want a icon on their desktop and not much more.

View on HN

You think /bin, /sbin, /usr/bin, /usr/local/bin, /usr/local/sbin (and so on) is simple and efficient?

You do know it’s a hack because the original Unix computer was running out of space and they hadn’t invented Union mounts yet... right?

I think "/usr/bin" is simple and efficient, and Fedora/CentOS have converged on that a couple of years ago (/bin is a symlink to /usr/bin on those distros). /sbin is the same (linked to /usr/sbin).

I find macOS paths atrocious (too long, too inconsistent, and derived completely outside of UNIX traditions and norms) and I certainly wouldn't want them on my Linux system.

Discussion of the usr move on Fedora: https://fedoraproject.org/wiki/Features/UsrMove

Folks can progress without throwing away decades of tradition and tribal knowledge.

Would you please elaborate a bit more with regards to what makes the current system more efficient?

I'm not the one suggesting a new-fangled scheme for the filesystem hierarchy. I think whoever is suggesting something hugely disruptive would need to be the ones to defend it. I'm saying, "Hey, we got this thing that's worked for a few decades. Changing it is fine, if there's a real problem with it, and solving it can't be done without disruption."

The person I responded to said the current Linux pattern of "/bin", and "/usr/bin", and "/usr/local/bin", etc. is inefficient (whatever that means). I said I disagreed (as much as one can without really understanding what is efficient about the new scheme or inefficient about the old) and pointed to a change that Fedora has made in recent years that simplifies it somewhat and recognizes that systems have changed (and the way we boot them has changed).

I'm not saying it is more efficient, I'm saying it's not less efficient (again, whatever that means in this context, you'd have to ask the person above me that I was responding to). But, I do find "one application per directory" very messy. My package manager knows where everything is so I don't have to.

This may not be awful. I'm not saying it is bad. I'm saying, "if we're going to change everything about the way we install, manage, update, and use software on Linux", there'd better be a damned good reason for it. It must be a clear improvement. This does not strike me as a clear improvement. It's clever for the sake of clever, without any significant value.

So, tell me why I'd want this. (And, "it's like macOS" sure as heck aint sellin' it.)

Have you ever had to work with a piece of software, where, since you were not using Gentoo or something, your package manager had a very old package and had to install a new version from source?

I remember around 1999 some sysadmins would say, create your own packages from source stuff that you need. Given the current filesystem, permissions, etc. creating your own stuff is not for the faint of heart. So what you did was search the web in hopes somebody had done it for you.

Fast forward to recent times, if you had to do devops where PHP was involved in some way, you would have felt remi was a guy that should be receiving free beer. Explain why we have arrived to that sort of situations.

Luckily nowadays, the world seems to have centered around Ubuntu, from Docker to whatnot, which makes everybody target Ubuntu at least. But to this day, I'm still a very fond user of Gentoo, even if the compile everything from source approach is a bit crazy, and its latest reincarnation, Funtoo, precisely because it gives me a machine that has everything I need when the time comes to deal with "the package not in my package manager" TM.

Sure, I remember 1999 (and I've built my own packages thousands of times since then, and still do a couple times a week, though mostly for my own software for distribution).

I understand the pain that older packages sometimes cause, but I think the notion that we should throw away good package management in exchange for...I'm not sure what exactly you're suggesting this new scheme provides, is a good trade. Gentoo is not a realistic option for most situations where you need stability over some length of time.

I looked over GoboLinux, and I see they offer multiple versions of packages, and that's cool and all. There are repos that do the same for CentOS/RHEL; Software Collections Library is a very good one that is sponsored by Red Hat. And, there's stuff like Flatpak coming down the pike which allows packages to be bundled up in a container with everything it needs.

One could argue that GoboLinux foresaw these needs (it's been around since 2002, apparently) and came up with a partial solution to the problem. I can't argue with that. But, it was, IMHO, so partial that it wasn't worth the trade. I'm not sure containers-as-packages are worth the trade in some cases, either, but it seems inevitable. So, I'm embracing it in my own work. It's definitely got some advantages.

And, yes, Gentoo is crazy.

I'm not sure I follow you; naming is an area where "UNIX traditions and norms" is clearly an example NOT to follow.

Why not?

For e.g. on Archlinux, all but /usr/bin is a symlink to /usr/bin.

That's not the whole thing about LFS. The split by kind rather than application is also a "feature" (or a bug, depending on your opinion). I used to like the fact that documentation was in one place, binaries in another, configuration etc etc

Nowadays I prefer isolation though.

Yeah, uhm, no. /bin and /sbin contain tools fundamental for booting the OS. /usr can be mounted from NFS resource, and as such, can be missing at boot time. /usr/local is for things installed locally by sysadmin.

This split comes from the times when it was not uncommon for workstations to share installed programs using network filesystems.

The split comes from when Bell Labs got a brand new huge 3MB disk that they mounted at /usr. The rest is retroactive rationalizations.

That it was introduced as a historical accident doesn't make today's use cases invalid or useless.

On most modern systems this is not strictly true anymore.

don't forget /opt

This way certain directories could be mounted read only (i.e. reside on a read-only partition/disk). Some directories were supposed to be governed by the core distribution, some were for user-installed software etc. It makes sense given the original intentions & restrictions. It may look weird on a one-person working station.

When you know that some default directories in Unix are result of one of the authors running out of disk space, and then religiously followed by everyone, finding countless arguments why is it the right way, how could you take it truly seriously?

Or bad quality of keyboards in the past forcing use of super short commands/directory names?

What's wrong with short commands? Not all of us enjoy overly verbose powershell-style syntax.

Nothing wrong. Just the reason for them might have been some "wobbly wooden keyboard" difficult to use rather than intentional shortness.

Just because they were optimizing for length doesn't mean they threw mnemonic potential out the window.

And either way it's quite arbitrary because almost all command names are still based on English that is a second language to many (including yours truly, but I'm not complaining, I find the usual unix shortcuts rather nice and intuitive most of the time and most of all - extremely quick to write, PowerShell makes me shudder and I had such big hopes for it).

Many concepts are also unique to unix/computers/low-level usage so any name will be non-intuitive. If you never encountered the concept of mounting a filesystem and don't know what an inode is then 'list inodes too' and 'list mounted filesystems' are no better to you than 'ls -i' and 'df'.

And someone who knows will prefer the latter, because it's that much quicker to type and harder to mistype.

Typing commands was originally limited by the speed of a teleprinter (before screens became standard), not the quality of the keyboard (QWERTY keyboard was created to slow down typists that were so fast they broke typing machines so I'd assume that it already limited typing speed enough).

This is also likely where the prompt character comes from, today we can do without it because terminal emulators remember the input and execute it once the current command is done but back then it actually prompted you to start typing.

Teleprinters is also where the word 'tty' (there are tty and tty with numbers in /dev that represent virtual terminals and you can play with them a bit if you know how) came from.

Hidden files starting with a dot was also a quirk of the ls reimplementation at the time of making filesystem hierarchical that was supposed to hide . and .. (current and parent dirs) but the check it did was for the first character being a dot, thus the concept of 'hidden files' was born.

See: https://plus.google.com/+RobPikeTheHuman/posts/R58WgWwN9jp

/bin is a link to /System/Index/bin. And as a matter of fact, so is /usr/bin. And /usr/sbin... all "binaries" directories map to the same place. https://gobolinux.org/at_a_glance.html

That's a great solution tbh

> Look in /bin.

What about /usr/bin? /sbin? I know the background but Plan9's overlay directories are a better alternative to PATH.

Technically /bin and friends are still there, as hidden symlinks into /System/Index.

In theory one could have a variant of /Programs live under /usr or some such, and just aim the symlinks into the traditional FHS. But the Gobo people figured that if they were to build a distro from scratch (initial Gobolinux releases piggybacked on existing minimal distro installs) why not see how far one could go.

Unlike various other projects out there, Gobolinux plays nice with the FHS. There is no demand from them regarding how the rest of the Linux community should structure things.

When reading the overview, it says that you can enable the classical /etc and /bin (and /usr/{s,}bin) which will contain liks. These are hidden by default with a kernel module though, but always present.

You might want to actually read the website, it looks like it answers all your questions[0].

[0]: https://gobolinux.org/at_a_glance.html

Reply on news.ycombinator.com