What's with this anti-directory structure movement?
Linked by Thom Holwerda on Wed 25th Jul 2012 22:18 UTC
OSNews, Generic OSes The article I'm about to link to, by Oliver Reichenstein, is pretty terrible, but it's a good way for me to bring up something I've been meaning to talk about. First, the article: "Apple has been working on its file system and with iOS it had almost killed the concept of folders - before reintroducing them with a peculiar restriction: only one level! With Mountain Lion it brings its one folder level logic to OSX. What could be the reason for such a restrictive measure?" So, where does this crusade against directory structures (not file systems, as the article aggravatingly keeps stating) come from?
E-mail Print r 19   · Read More · 164 Comment(s) http://osne.ws/k8c
Thread beginning with comment 528492
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[5]: Oliver has lost it.
by daedalus on Fri 27th Jul 2012 12:27 UTC in reply to "RE[4]: Oliver has lost it."
daedalus
Member since:
2011-01-14

If you are confused by system files, just don't look at them!


Which is all well and good until something doesn't quite work. There are plenty of tools and things out there which need to have their configurations manually set in text files - some of them are in /bin, some are in /usr/bin, some are in the home directory and so on. For example, on my Ubuntu 10.04 box I can't save changes to my graphics card settings without editing the text file manually because something funky is going on with the Nvidia configuration tool. I've done it several times, yet I still couldn't tell you which file I need to edit or where it is until I spend a while trawling through forums and FAQs. The same for SMB mounts of my NAS. They're not reliable unless I mount them by hand, and so to have them available at boot means wading through the system files.

I appreciate that that's a little OT, and that with Linux all the folders are basically as you see them, but it doesn't stop it from being confusing / messy. Again, comparing it to the Amiga way of handling drives, mounting media is quite unintuitive, with things like a CD drive having nothing to distinguish it from any folder on the hard drive. IMHO there shouldn't be a filesystem higher than the root of any drive, and having the root of a CD at /mnt/cd0 or whatever just doesn't make sense in the whole desktop/folders paradigm.

Reply Parent Score: 2

RE[6]: Oliver has lost it.
by UltraZelda64 on Fri 27th Jul 2012 16:18 in reply to "RE[5]: Oliver has lost it."
UltraZelda64 Member since:
2006-12-05

Honestly, I don't know the last time I had to set up system files. Configuring SSH or MPD maybe? I doubt that a typical person coming from Windows would even know what a daemon is as I mentioned, and I wish them luck on somehow managing to download some kind of malware to destroy things like /boot as I mentioned to truly wreck a system, Windows-style. UNIX doesn't make it easy.

For those people who *are* likely to play around by experimenting heavily and screw up OS installations, well, chances are they're intermediate to advanced users, and at least have an understanding on the Linux filesystem to get things back up again if needed. For those users who do hear of some interesting daemons that they'd like to learn to use, well, a couple commands for start/restart/stop and editing a file or two under /etc is really not that difficult, and by the time they learn of it they'll probably already feel at home in the OS.

I don't recall ever having to modify a program's configuration that placed its config files in /bin or /usr/bin. If the configuration is not within a configuration window of the program itself, it's somewhere under /home/user. If it's a daemon, it's somewhere under /etc, or for some web-based daemons it can be accessed as a GUI by logging into a web page on the machine running it. Simple as that.

Reply Parent Score: 2

RE[6]: Oliver has lost it.
by tupp on Fri 27th Jul 2012 17:13 in reply to "RE[5]: Oliver has lost it."
tupp Member since:
2006-11-12

Which is all well and good until something doesn't quite work. There are plenty of tools and things out there which need to have their configurations manually set in text files - some of them are in /bin, some are in /usr/bin, some are in the home directory and so on.

If configurations files are in /bin or in /usr/bin, something is probably wrong. "Bin" is short for binary, so, only binary files (apps) should reside in such directories. User-specific configuration files are usually hidden in the user's home directory.

See how these names/organization make sense?

However, global configuration files are usually found in the /etc directory. This directory name is probably held over from the early Unix days. It doesn't seem intuitive, but it is easy to guess how the name evolved, and it makes sense when thinking of the name in that regard.

By the way, aside from the intentional "pseudo" obfuscation, Windows has similar problems with cryptic system directory/file names. Anyone who has been "dumbified" will have the same trouble navigating Windows system internals.

It's much worse when a "tardified" Apple user has to go into the OSX system internals. Such users have to contend with two sets of system directories: the hidden, cryptic Unix bottom layer, and the tard-oriented top layer.


I've done it several times, yet I still couldn't tell you which file I need to edit or where it is until I spend a while trawling through forums and FAQs.

I think we've found the "root" of the problem.

If one has trouble remembering things like file paths, all one has to do is write down the path somewhere. Or, one could record the path into a file and give it a name that one can remember (and, of course, put it in a directory where one can remember it).

Reply Parent Score: 1

RE[7]: Oliver has lost it.
by tidux on Sun 29th Jul 2012 01:20 in reply to "RE[6]: Oliver has lost it."
tidux Member since:
2011-08-13

/etc stands for Editable Text Configurations or "Et Cetera," because it's not a binary, a bootloader, a library, /var-iable size data, or anything else the top level directories contain.

Reply Parent Score: 2