Linked by Thom Holwerda on Fri 25th May 2012 14:55 UTC
General Unix James Hague: "But all the little bits of complexity, all those cases where indecision caused one option that probably wasn't even needed in the first place to be replaced by two options, all those bad choices that were never remedied for fear of someone somewhere having to change a line of code... They slowly accreted until it all got out of control, and we got comfortable with systems that were impossible to understand." Counterpoint by John Cook: "Some of the growth in complexity is understandable. It's a lot easier to maintain an orthogonal design when your software isn't being used. Software that gets used becomes less orthogonal and develops diagonal shortcuts." If there's ever been a system in dire need of a complete redesign, it's UNIX and its derivatives. A mess doesn't even begin to describe it (for those already frantically reaching for the comment button, note that this applies to other systems as well).
Thread beginning with comment 519594
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[2]: Re:
by Zobeid on Sun 27th May 2012 03:33 UTC in reply to "RE: Re:"
Zobeid
Member since:
2012-04-28

You seem to have a fundamental misunderstanding of how the UNIX file system hierarchy is constructed and why it is that way. There is no reason at all to change it, even a little bit.


I'm with kurkosdr, it's madness. His (and my) "fundamental misunderstanding" is indicative of just how wacky it is. Your inability, or unwillingness, to explain what we're missing just further underscores this. I'm guessing it would take a major effort to lead us through the convoluted logic to justify a scheme that's so counterintuitive to normal, non-Unix-indoctrinated people.

Furthermore, I've see how well named volumes worked on the AmigaDOS command line. That made sense.

Reply Parent Score: 1

RE[3]: Re:
by Doc Pain on Sun 27th May 2012 09:50 in reply to "RE[2]: Re:"
Doc Pain Member since:
2006-10-08

Furthermore, I've see how well named volumes worked on the AmigaDOS command line. That made sense.


Since many UNIX and Linux systems support file system labels (in different ways), this functionaliy can be considered a standard functionality. It's a feature commonly used today.

You can "mount /dev/label/data2012 /home/db/thisyear", or have the disks in your NAS labeled A1, A2, B1, B2, and SPARE. You can reflect RAID criteria (part of mirror, part of stripe, spare) as well as functional parts (system disk, data disk, program disk, scratch disk, secret disk). You can even automate mount actions depending on labels.

Reply Parent Score: 2

RE[3]: Re:
by Vanders on Sun 27th May 2012 12:41 in reply to "RE[2]: Re:"
Vanders Member since:
2005-07-06

Your inability, or unwillingness, to explain what we're missing just further underscores this. I'm guessing it would take a major effort to lead us through the convoluted logic to justify a scheme that's so counterintuitive to normal, non-Unix-indoctrinated people.


Oh I'm sorry, I didn't realise I was here to provide a CIS lecture. How about you make it your responsibility to educate yourself and then we can have an informed debate on both sides?

From the context of your post I'm guessing you're complaining about the directory structure. That wasn't what the original discussion was about. Whether "everything is a directory" with volumes mounted under / makes sense and whether the names and structure of those directories makes sense are two different things.

I'm actually inclined to agree that the current hierarchy and naming scheme in most *nixes are a complete mess.

Furthermore, I've see how well named volumes worked on the AmigaDOS command line. That made sense.


So do I. Volumes on the Amiga were no more intuitive than everything-is-a-directory on UNIX. Why is LIB: or C: any more easy to understand than /usr/lib or /bin?

Edited 2012-05-27 12:44 UTC

Reply Parent Score: 3