I was reading about some distro
 

And. I want to know what you, slackers, think about this
http://www.gobolinux.org/index.php?page=at_a_glance
It seems interesting

I personally think its time to rename the directories to something more readable. But FHS shows no willingness to do so. Which I dont mind at all, that's their thing. Whatever.

I think /etc/ should be named /config/

And a root /logging/ directory should exist.

Mnt? really? Can't be bothered to spell out 'Mount'?

We are really past the days where our space is limited, and filenames can be more than 8 characters. so why not utilize 'words' instead of 'abbreviations and abstractions.'

I like it.

I guess as soon as these are renamed accordingly, people must move from the keyboard to the mouse. Whether this is more harmful to the carpal tunnel cannot be decided by the FHS -- maybe WHO instead.

\t is your friend when it comes to long file names/directory names.

"ls -l /<Shift>p\trograms/<Shift>\tBash/\t\t3.0/b\tin/b\tash" is more keystrokes than "ls -l /bin/bash". Or did I count it wrong?

Lack of knowledge of The Elements Of Style: UNIX As Literature considered harmful

Unix is not just a functional implementation of POSIX. More important than that, it is a culture and a language and a heritage. It has humanity. It has continuity. If you reject the vocabulary, then you also reject the culture, and the people that participate in the culture, and their accumulated experience. If you're going to do that successfully, well, you need to be as powerful as Apple. GoboLinux is not as powerful as Apple.

I see GoboLinux supports "English | Português | Deutsch | Русском | Magyar | Français | Español | Svenska | Italiano | 日本語 | Türkçe | Norsk". Maybe they should support a project with similar aims, by throwing all those out and replacing them with Volapük.

Thats fine and dandy.

But when a car company comes up with a new system, called say "Battery based Blinker fluid injector system" they don't shoe horn it into a previous term just because there is a culture surrounding previous car terms.

If everyone continued doing everything for culture/historic/nostalgia related reasons, we would still be in the stone ages.

But im done here. Im not going to have an opinion argument over 'directory names' when I just now realized that I really and truly don't care one way or another.

At the end of the day, I will make symlinks to the old directory names for easier reading anyway.

and so on

Greetz
Several years ago I met a software developer from Brazil who told me that due to quirks in language, specifically for him, Portuguese, that many Brazilians used English as if it was part of an icon because it was just shorter and simpler. I don't know how much he was qualified to speak for large groups but I think the basic concept is sound and complies with KISS. Why spell out "mount" when everyone knows what "mnt" means? As was pointed out, even if you are a wiz with the tab key, there is still great advantage to keeping terms short.

Much more importantly, as soon as you change directory structure and/or naming conventions you immediately break everything that has gone before and to what advantage? This is my major complaint about distros with auto-dependency resolving. They are forced to restructure to do what they've added on while avoiding conflicts and this breaks compatibility and fragments Linux. Add to this, some restructure exactly in order to break compatibility to isolate themselves in hopes of becoming some de facto standard, the precursor to proprietary. I find this incredibly selfish and short-sighted.

One of the greatest strengths of *Nix is compliance with standards that insures not only the ability to accumulate skills (instead of reinventing the wheel and tossing all your hard work in the trash bin) but also The Community. The more that distros create arbitrary change the more fragmented Linux becomes and the size of communities that "speak the same language and dialect" dwindles.

IMHO that is not a worthwhile tradeoff.

Where do you think the word 'car' comes from?

Amongst other things, I do prehistoric archaeology (Neolithic and Bronze Age). Their culture progressed in incremental changes that were sometimes large and sometimes small. So does Unix.

I once snapshotted a load of developers' files from /gprs to /goats_piss_really_slowly -- it took them weeks to notice.

Where do you do this? Do you get to travel a lot? I think that's an awesome sounding profession. Or is it a hobby?

You only know "mnt" stands for "mount" once you learnt it. Just think about "/usr", for example, it is often misunderstood as "user" but it actually stands for "Unix System Resource". And, Gobo's way (lets call it this way) does not break anything. I am not saying I like it, I am just saying that it doesn't break compatibility.

Thanks, but we are just amateurs. I get to travel approx five miles ;)
http://csirm.wordpress.com/ and http://www.bingleyhistory.co.uk/cup_and_ring.html
We have circumstantial evidence that Bronze Age people were incorporating neolithic rock art into their burials, maybe a thousand years after the rocks were decorated. Some people think the rock art tradition even continued into the Iron Age. But over the same centuries tool technology and agriculture seems to have changed in sudden bursts. Some modern research indicates that there were hunter-gatherer communities and agricultural communities in the same place at the same time for hundreds of years. These were people who were modern in every way, except culturally. They were weird :scratch:

Sorry for the off-topic :redface:

A short glance at the words of UNIX ("mnt", "umount", "ls", "cp", "mv", "rm", "passwd", "mkfs", "fsck") should suffice to illustrate the fact that UNIX developers around the world are still struggling with the concept of vowels.

:D

Well, filesystems are already represented in a virtual way and there's nothing to stop you from 'customizing' what is displayed -even without having to change underlying structures. Custom versions of file-managers/ls, etc could be made to show and use something different.

I've looked at gobo and earlier predecessors it was based on. All wind up with longer names and less-informative, less-useful name structures. As an aside, the current buzz around eliminating /bin, /sbin and /lib similarly accomplishes a less-useful, less-informative structure.

mnt is when you do a quick mount :)

Nope, it really does mean user!

From lists.busybox.net/pipermail/busybox/2010-December/074114.html:

Don't believe Rob? Ok, here are some notes from Dennis Ritchie from 15 March, 1972 where he briefly mentions the purpose of /usr

I believe that was back when /usr was used as /home. No?

Sure (did you read the whole quotes?), anyway it is the reason why /usr is named thusly (since it was for users to have their files). "Unix System Resource" is just a backronym, invented later.

Are you talking about the suggested merger of these into /usr? If so, have you ever read Rob Landley's post to the BusyBox mailing list? If not I would encourage you to.

I also asked Pat about this once, here is a snipit of what he had to say:

On BSD UNIX, if there are only two disks (partitions), home directories go into /usr/home. So /usr still makes perfect sense.

@ruario:

Many thanks for your contributions on this topic. Very enlightening quotes. I also appreciate the links to the sources. I've studied some on the history of unix, but usually from the viewpoint of the developement of the c language in relation to unix evolution. It's always a good day to learn something unexpected :)

Of course, here we have an embedded developer having to deal with Unix heritage, because he wants to use Linux (an Unix clone) as a kernel . But in a custom-built embedded installation you don't really need anything else than a /busybox. :)

Unlike BSD, Linux userland never had a well-designed /usr separation that made sense, so Rob is right in this respect. The classic question of intelligent design vs. evolution. As far as I understood, BSD separated single-user and multi-user into / and /usr and I know of no plans to change that. BSD's mechanism for in-place upgrades of the operating system depends on it. Also / played the role of /boot for a long time (kernel was just called /bsd and the bootloader could only read /) and /usr/local gets all the third party packages, a distinction Linux never made.

So yes, Linux' filesystem hierarchy is a chaotic mess, a result of chaotic evolution. But trying to design stuff retroactively only harms the ecosystem by breaking compatibility. I think we should keep software compatible, there are people out there, who depend on it. Just accept it and embrace it.

Although it does mention that Unix commands are still available, it gives:

ls -l /bin/sh | cut -b 45-

as one of the examples.

I don't see any real issues with the current tree based system personally. While having things like /programs, /system, etc. all seem more balanced and segregated, this stretches out another old question, "Why does GNU/Linux have to be like DOS/Windows?"

I think the tree based structure of /(root), /usr, /usr/local, /home, and other system partitions allow for easier resource structuring, network accessibility, and system control. It's far superior to anything Windows has in terms of modularity.

I've seen people calling it "user" and Unix Resources, I am confused. I read it as "user" anyways.
EDIT: Yeah, I rather use the "normal" way than something that looks like a bit with Windows

Greetz
The reason I mentioned Brazilian methods was that it really doesn't matter if anyone realizes "mnt" means "mount". In short order they know it's where non-root file systems go. Similarly, while I speak "/usr" phonetically as if it were "user", I really don't care what it was originally meant to be... only how it functions. In just a day or two of reading about and using Linux, I knew the basics of what is stored there. Same with "/var" etc.... I mean "/etc" etc :P

It looks nice on the surface, e.g. mapping /usr/bin, /usr/sbin, /usr/local/bin all to /Programs but note the following.

On slackware by default, for an ordinary user the command
returns something like
because /usr/sbin is not on an ordinary user's path (by default), i.e. it is possible to "hide" certain commands from ordinary users.

It seems to me that if /usr/sbin and /usr/bin both link to /Programs then you can't do this.

Michael

i find the current organisation logical

Exactly.

Btw this is what the tree structure is for:

/(root) - kernel and low level utilities
/usr - user land and network accessible utilities
/usr/local - user land local only utilities

I find the current organisation a bit of a mess. Why is /usr/lib full of stuff that doesn't end with .so or .a? Why is /var/lib called 'lib' at all when it contains rw application data? Why in gods name did they deprecate /usr/libexec when there's clearly a role for it.
IMO the guy who decided "Hey, we don't need libexec, lets just dump everything in directories under /usr/lib" should be taken out back and shot! (ok, maybe that's a little harsh... given a good beating will suffice ;)).


The problem with Gobo is that they tried to be too radical. Would have been much easier to sell a scheme along the lines of:
/usr/data/... (instead of /usr/share, /usr/games, /usr/info and the like)
/var/data/... (rather than /var/lib etc...)
/opt/$program-$version

The continued use of traditional /usr/... and /var/.. and /opt/... prefixes would have made it seem more like a refinement/evolution of the existing scheme.


BTW, I'm all for the /bin /usr/bin merger. I don't think the split makes sense in the modern world.


... but that's just me. YMMV. ;)

Merging /usr/bin and /bin would bring a load of security issues. There's a reason why kernel and user land utilities are kept segregated. Security. Its all permissions.

Sorry, don't see it. Our $PATH already contains both /bin and /usr/bin so I really don't see how a unified directory would be in any way worse than what we already have.

Note: I'm not saying bin and sbin should be merged (which I believe Fedora were actually considering at one point), which would be IMO idiotic.

i'm not that experienced


if you make it so a user with some pseudo sudo can only install to /usr/bin

a binary is first checked in /bin, then /usr/bin
so there is no way for that user/package to override it for others
(i know users should install extra/unnecessary programs to opt)

hier(7) is a good read on this. You will notice, that libexec is still there and they never had a /var/lib. Sometimes it doesn't harm to look at a real Unix implementation. :-)

Indeed. OpenBSD's hierarchy is much cleaner too. The /usr/lib and /var/lib thing we see on linux is definitely a deviation from traditional UNIX.

P.S. I don't mind deviations as long as they make sense.

Slackware has this. Since when is it deprecated? Or is it planned? Would be a pity, I even have SlackBuilds that install additional executables there...

I think current practice with Slackware is to configure using: --libexecdir=/usr/sbin

Some certainly do, though I think /usr/lib/$appname is a more common place and if I'm remembering rightly what the FHS mandates for indirectly executed executables.

I'm a bit of a neat-freak when it comes to the filesystem. Though I'd rather see .../libexec used for the purpose, I can tolerate putting app specific subdirectories in /usr/lib${LIBDIRSUFFIX/ but when stuff just gets dumped directly into /usr/lib$LIBDIRSUFFIX such as xml2Conf.sh and tkConfig.sh and the like, well, that's just messy.

But, I suppose those of us who care about such things are in the minority. I suspect the vast majority of linux users never look outside of their home directories.

Well, it wasn't so much that it was explicitly 'deprecated'. The FHS decided to take an alternative approach rather than use the BSD style /libexec that older distros were already supporting, and package maintainers have just drifted in that direction. The default libexecdir setting of ./configure on linux is probably a big factor in the migration to the FHS way of doing things.

Some of that mileage variance is "I'd like to mount /usr on its own logical volume.".

I like it, and if I had to choose between to otherwise identical distros for my workstations I would choose the one laid out like gobo. I'm gonna look at gobo in more detail, but truth be told there is more to a distro than the file system layout, so I might not switch over my production systems yet ^^

PS: and thanks to ruario for reminding us about the origin of some design decisions made at the dawn of UNIX. It never ceases to amaze me how standardisation organsiations and corporate concrete heads turn arbitrary and outdated design decisions into the gospel. On the other hand I do see the value of standardisation, and I realize sometimes it is better to live with a suboptimal standard than with none at all. That's where standardisation organisations could help by slowly introducing a standard B while standard A is still in operation.

Yep, some folks like to do that, and I ran with a separate /usr for a long, long time, but I stopped a few years back when it occurred to me to ask myself, "Why am I doing this?" and the only answer I came up with was "tradition". I wonder how many of the people who still do this would come up with the same answer if they asked themselves that same question.

I have separate /var, /tmp, /home and even /usr/src filesystems on my system (using LVM), so I'm not against the principle of using separate filesystems where there's benefit to be gained from it.

In the early days I had a simple setup with only / and /usr separated on BSD, which makes perfect sense:

/ on a faster smaller disk contained performance-relevant stuff including /var and /tmp and everything required for a fast boot like /bin/sh, /etc/rc and so on.

/usr on a slower but larger disk contained third party packages, sources, home directories and everything else (/opt doesn't exist, packages install into /usr/local, /usr/pkg or something like that.)

The advantage over a single / was better performance and more reliabilty. There was no need to separate /var or /home (and run into space issues), both installed applications and home directories (including apps installed into $HOME) could make use of the full available disk space on /usr. Back then I had only disks with a few GBs, so that was important.

It is not possible to reproduce this setup on Linux. The Linux /usr equivalent is / now, so you basically end up with a single /.

My guiding principle is to separate predominantly 'rw' filesystems from predominantly 'ro' filesystems, which is why I'd never leave /tmp, /var or /home in the rootfs. And while / is still subject to a little writing even after separating those 3 filesystems, write activity will be minimal, so I see no value in separating /usr from it. Coincidentally, it also results in a pretty clean split between what can be considered 'system' and 'data' which is also nice.


I understand what you're describing above, but those sorts of hardware optimisations are a thing of the past. Large memory, VFS Cache, faster devices with on device buffers/cache/abstraction/virtualisation have pretty much negated many of the choices we used to have to make. I suspect a lot of newer admins will just give you a blank stare if you ever talk about 'inner-edge', 'outer-edge' or 'middle'. ;)

Anyway, we're starting to get seriously off-topic here, so I'll leave it there. :)

I've often seen people trying to save / from write accesses, but they never tell a technical reason for it. I can see the point of having a separate /var on a heavy-loaded server, so now we need a /run directory, because /var/run isn't available at boot. :) But sometimes you want to keep things simple and don't create dozens of partitions, only two or three. BTW: Separating /home is only needed, because it contains the home directories instead of /usr. It was never meant to be left on /.

As I said, Red Hat Linux now treats / as /usr (UsrMove).

Of course not, today we have devices with small fast embedded flash memory and a slow SD card. And the well-organized BSD filesystem hierarchy is still able to adapt to that much better.

This is still a thing with hard disks, they are faster on the outside (smaller LBA numbers).

/(root) technically shouldn't be accessed as often as /usr. /(root) operates more in the kernel space of the OS rather than the OS's userspace as /usr does. You shouldn't be accessing anything in /(root) as a user unless either A) you're the root user, and B) you're starting up, powering down, or rebooting the system.