Another view.
I'm sure I don't agree. Yes, UNIX is nearly 40. Yes, there are uglies in the way that you administer it, and also in the crude security model, but what are you holding up as a shining example of something better? I've seen administration tools that looked prettier, but they generally end up being so locked down as to be largely useless, or so complex to set up (I'm thinking CDE with it's cross-system authentication here) that you have to be a real propeller-head in order to get it working.
UNIX has seen off so many alternatives, and still lives on, while everyone else learns the hard way over-and-over again that hidden complexity leads to difficult-to-manage systems. The more layers of 'gloss' you add to 'simplify' administration, the more problems you build in when it goes wrong. (I'm coining Gathercole's Law as being "Apparent simplicity causes hidden complexity" )
If you need something better for users, then Gnome and KDE will provide you something just as pretty as other OS's (and a product from the 1980's called Looking Glass, which predates usable Windows systems also springs to mind), so the so called unfriendly* command line is not necessary for those who don't need it. Sometimes you ought to look and see what it is possible to do with the simplicity of the shell command line as practiced by real power users. It may not LOOK pretty, but it is elegant and functional.
I have frequently stunned managers and younger colleges by piping together several small tools with simple stream processors (think awk or sed) to achieve in a matter of minutes things that they were prepared to commit days of work to do. This is especially true in clusters or networks of near homogeneous systems, which is where UNIX excels.
It is a testament to the original design criteria of the shell and the base UNIX command set that most of the commands I use on a daily basis came out of Bell Labs. Version 7 UNIX, dated 1976. This has been augmented over the years, but you would still recognize that system as UNIX today. This may mark me out as a dinosaur, but hey! I'm still working, and I appear to have the respect of my peers who keep asking me to do things they cannot work out an easy way to do.
In my view, what is wrong with the example quoted WAS a UNIX design flaw, that of allowing spaces in filenames (space should have been made a banned character), but the very flexibility of the shell and filesystem interface allowing almost any character in filenames has allowed multi-byte character set languages to be integrated into UNIX with comparatively little effort.
(*) Often, the reason why it was seen as unfriendly is that most users were too lazy to learn the dozen or so commands that were the core set needed to do their job. They got frightened because two-and-three letter abbreviations were not close enough to english (e.g. cat - catinate is and English word, but one many people are not familiar with). This was a matter of perception and training. Possibly the only OS that got it right on the command line was VAX/VMS with DCL, which allowed you to use full command names, or any unique abbreviation. But this made the command processor one of the largest tasks in the system and was still not English!
P.S. I'm really not looking forward to a time when role-based security (which is already present in the few genetic UNICES left and also Linux since the 2.6 Kernel) becomes the norm. I predict that we will see stories of administrators who don't fully understand the importance of local privileged accounts locking themselves out of their systems when the LDAP or ActiveX directory servers cannot be contacted to authenticate them to fix the problem.
Biting the hand that feeds IT
