Unix doesn't follow the Unix philosophy
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).
E-mail Print r 1   111 Comment(s) http://osne.ws/k28
Permalink for comment 519603
To read all comments associated with this story, please click here.
RE: Re:
by Doc Pain on Sun 27th May 2012 09:25 UTC in reply to "Re:"
Doc Pain
Member since:
2006-10-08

Someome needs to build wrappers for Unix's CLI commands, now.


To wrap them into what exactly?

This would also seperare interface fron engine.


For CLI programs, I think one can see the interface as an essential part of the engine. You cannot separate them at this low level.

The fact the hard drive unix is installed gets labelled as "/", and everything else is essentially mounted on a virtual folders inside /mnt is also insane.


First of all, please try to use the proper terminology. There are no folders. Those are called directories. A folder is the name of a visual representation of a directory.

Then, the disk isn't "labeled as /". Depending on support, disks and their partitions can actually be labeled (e. g. "bootdisk", "datadisk1", "datadisk2"). / is the root of the file system hierarchy. This is not neccessarily a hard disk! For example, if you boot from a DVD or a USB stick into a RAM disk like environment, there are no hard disks at all. And now you introduce hard disks to that system. Depending on if you apply some RAID technology, a disk, a part of a disk or a compound of disks might be mounted at /home in that hierarchy.

Depending on the system you're using, /mnt might be reserved for specific operations, e. g. as a temporary mount point for the system operator. Using the "everything is rooted in /, but mounts can be done everywhere" concept, you are free do even mount several disks "combined" into one directory, e. g. you have /opt/stuff containing files of many disks. This enables you to separate functionality of the system into different media (or as a memory file system), and you can easily enforce specific mount options for security (e. g. no execution possible) or access (e. g. can only be read) or speed. You can even swap the set of installed programs or databases based upon mount point (just changing which device gets mounted).

Let's be honest, this is a hack because unix was designed for systems with only one drive.


As you see from my examples, UNIX has been designed to have lots of drives. Flexibility is the key.

If this can't be fixed, let's at least fix it at terminal/GUI level so we can have HDD2:something.jpg instead of /mnt/hdd2/something.jpg


What's the difference? I don't see anything significant here. I see you show a "drive as a prefix" habit such as the "drive letters" you find in DOS and "Windows", but why should they be tied to be the 1st element of a path? What if symbolic links enter the stage? How should that be processed?

You see that the flexibility of "mount wherever you need it" is superior to this approach.

However, the representation to the user is a totally different thing. For example, if you attach a disk to the system, an icon pops up on the desktop, you click it and see what's on the disk. Need to deal with device names or paths? No.

Commands should be seperated by ASCII "unit seperator" not spaces.


The space is the command line separator. If filenames do contain spaces, quoting or escaping is needed.

If you compare to VMS, you'll find a slightly different approach: Here command options or qualifiers are often found as associations, e. g. instead of calling "dostuff in.txt out.txt" you do "dostuff /in=in.txt /out=out.txt" which is more verbose, but you could omit the spaces.

Using the space as both a seperator and a legit filename character is bad.


Correct. You shouldn't use spaces in file names. Using _ is possible, and many GUI programs simply substitute the _ to an actual space in display. However, there are "tricks" that a good programmer has to implement to make scripts work with malformed filenames that don't just contain spaces, but also other possible characters, such as quotes, newlines, and backspaces.

Anyway, as a last note, the author of the linked article is falling into the same trap the unix haters handbook fell, treating "Unix" as if it's one thing.


This makes it easy to compare to "Windows" which is also interpreted as being "one thing". :-)

Reply Parent Score: 3