5 ms·

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. Y

by koehr 9y ago

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.

hdhzy 9y ago
> Look in /bin. What about /usr/bin? /sbin? I know the background but Plan9's overlay directories are a better alternative to PATH.
xenadu02 9y ago
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?
- SwellJoe 9y ago
  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 https://fedoraproject.org/wiki/Features/UsrMove Folks can progress without throwing away decades of tradition and tribal knowledge.
  - ahmedfromtunis 9y ago
    Would you please elaborate a bit more with regards to what makes the current system more efficient?
    - SwellJoe 9y ago
      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.)
      - aclsid 9y ago
        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.
- oxplot 9y ago
  For e.g. on Archlinux, all but /usr/bin is a symlink to /usr/bin.
- agumonkey 9y ago
  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.
- dozzie 9y ago
  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.
  - kryptiskt 9y ago
    The split comes from when Bell Labs got a brand new huge 3MB disk that they mounted at /usr. The rest is retroactive rationalizations.
    - Gracana 9y ago
      That it was introduced as a historical accident doesn't make today's use cases invalid or useless.
  - mondoshawan 9y ago
    On most modern systems this is not strictly true anymore.
- heeen 9y ago
  don't forget /opt
- stewbrew 9y ago
  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.
setzer22 9y ago
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.
deleted 9y ago
[deleted]
gcoda 9y ago
/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 https://gobolinux.org/at_a_glance.html
- gatlinnewhouse 9y ago
  That's a great solution tbh
bitL 9y ago
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?
- dagenleg 9y ago
  What's wrong with short commands? Not all of us enjoy overly verbose powershell-style syntax.
  - bitL 9y ago
    Nothing wrong. Just the reason for them might have been some "wobbly wooden keyboard" difficult to use rather than intentional shortness.
    - FRex 9y ago
      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.
- FRex 9y ago
  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 https://plus.google.com/+RobPikeTheHuman/posts/R58WgWwN9jp
Sean1708 9y ago
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 https://gobolinux.org/at_a_glance.html
digi_owl 9y ago
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.

by koehr 9y ago

hdhzy 9y ago

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

xenadu02 9y ago

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?

SwellJoe 9y ago
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 https://fedoraproject.org/wiki/Features/UsrMove Folks can progress without throwing away decades of tradition and tribal knowledge.
- ahmedfromtunis 9y ago
  Would you please elaborate a bit more with regards to what makes the current system more efficient?
  - SwellJoe 9y ago
    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.)
    - aclsid 9y ago
      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.
oxplot 9y ago
For e.g. on Archlinux, all but /usr/bin is a symlink to /usr/bin.
agumonkey 9y ago
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.
dozzie 9y ago
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.
- kryptiskt 9y ago
  The split comes from when Bell Labs got a brand new huge 3MB disk that they mounted at /usr. The rest is retroactive rationalizations.
  - Gracana 9y ago
    That it was introduced as a historical accident doesn't make today's use cases invalid or useless.
- mondoshawan 9y ago
  On most modern systems this is not strictly true anymore.
heeen 9y ago
don't forget /opt
stewbrew 9y ago
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.

setzer22 9y ago

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.

deleted 9y ago

[deleted]

gcoda 9y ago

/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 https://gobolinux.org/at_a_glance.html

gatlinnewhouse 9y ago
That's a great solution tbh

bitL 9y ago

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?

dagenleg 9y ago
What's wrong with short commands? Not all of us enjoy overly verbose powershell-style syntax.
- bitL 9y ago
  Nothing wrong. Just the reason for them might have been some "wobbly wooden keyboard" difficult to use rather than intentional shortness.
  - FRex 9y ago
    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.
FRex 9y ago
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 https://plus.google.com/+RobPikeTheHuman/posts/R58WgWwN9jp

Sean1708 9y ago

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 https://gobolinux.org/at_a_glance.html

digi_owl 9y ago

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.