What's Wrong with Unix?

aaron240 asks: "When Google published the GLAT (Google Labs Aptitude Test) the Unix question was intriguing. They asked an open-ended question about what is wrong with Unix and how you might fix it. Rob Pike touched on the question in his Slashdot interview from October. What insightful answers did the rest of Slashdot give when they applied to work at Google? To repeat the actual question, 'What's broken with Unix? How would you fix it?'"

Several frustrating points

[SIGALRM (784769)]

What's wrong with UNIX? Depends on which perspective you start...

In my opinion, here are some headaches that have plagued a wary UNIX engineer or two:

IEEE and Posix, X/Open, etc. provide a basis for standardizing UNIX interfaces, but adherence tends to be spotty

Difficult to implement a microkernel architecture

XPG3 aside, a de facto "common API" has never really been acheived

In many cases, code scrutiny is difficult or impossible

Progress and innovation tends to occur within the context of aquisitions (i.e. UnixWare)

The COFF symbolic system is terrible (OK, I know it's a deprecated, but still...)

PIT initialization (time management)

Kernel tuning (anyone fiddled with the /etc/conf/cf.d subdir on OS5?) These are just a few things, in my experience. That said, UNIX has had some great days.

KSpaceDuel

[jkauzlar (596349)]

Certainly this component of Linux needs rewritten. Firstly, it is far too difficult to maneuver your ship with the gravity the way it is, and secondly, the bullets go too slowly. Thirdly, it isn't intuitive what the different colored blobs are; its easy to forget what is energy and what is a mine, or something like that.

I would suggest to the KSpaceDuel team that they meet with the KAsteroids team to discuss usability issues. There should also be a cap on how fast you can go, since it is possible to speed up so fast that your spacecraft appears to be moving very slowly (sort of like a tire in motion).

Re:Several frustrating points

[by Anonymous Coward]

In addition:

1. Crappy filesystem. Resier4 or XFS is what UNIX should have started with and even now we don't have file versioning.
2. POSIX permisions suck. The suid bit sucks even more. ACL's make more sense, and UNIX should have had them from the start. If we're doing it now, capabilities would be even better.
3. IPC primitives are poor. SySV shared memory goes some way to helping, and UNIX domain sockets are O.K, but a proper message/event marsheling system would eclipse them all.
4. The filesystem hierachy is an awful mess. Non-standard across all unices and poorly evolved to cope with modern systems. /etc was a horrible copout and it shows. UNIX needs proper application packaging with proper self-contained application packages.
5. Providing lots of little applications to do specific tasks was the best idea ever, but not providing a decent scripting language to bind them together was a bone-headed mistake. Likewise not standardising some basic data-interchange formats (Even it was just pre-formated ASCII) just makes piping all those little tools together to do anything useful a pain.

Here's a start:

[Slack3r78 (596506)]

The Unix Hater's Handbook [microsoft.com]

Yes, the link is hosted on MS servers, but before you ignore it for that, at least notice that the forward is by Dennis Ritchie and it was contributed to primarily by Unix geeks. It's about 10 years old, but large portions of it are still relevent today.

Screen is too black...

[raile (610069)]

I'm used to reading my system text as a white font on a blue background.

OS X

[BWJones (18351)]

Based upon my experience with IRIX and Solaris (with some Linux), I would have to say that most of the things that *NIX did poorly have been rectified with OS X. I would have said OS X was still lacking true 64bitness, but that is coming in 10.4 rather quickly now. The numbers of Macs involved in secure and classified work in the Federal government have been exploding and high bandwidth networking options for cluster computing have also been resolved with options such as Infiniband. Development issues have been streamlined with rather nice tools from Apple itself obtained via NeXT. Open standards are being embraced just about everywhere you turn in OS X, a true plug and play environment now exists (I am reminded of the last video card install on my SGI O2 which had me down for two days solid), the GUI is consistent and the CLI is present and fully integrated with the GUI as well. Additionally, more and more networking options are being supported natively within OS X which is one of the last hurdles to true interconnectivity cross platform. And the G5! Oh, the G5 is a wonderful bit of hardware with which to run *NIX on.

Problems that remain are being able to create one seamless environment with shared memory and such, but the rest of the *NIX world is still having those problems as well.

You can argue about the specifics and details of many things, but in terms of a UNIX workstation, OS X pretty much has it all for our needs.

Re:OS X

[ducomputergeek (595742)]

I generally have to agree. I had used solaris, Linux, FreeBSD, and OpenBSD systems before switching to OSX about 2.5 years ago. Granted I'm still running on my G3 iBook so the great power of the G5 chips are of little conquence, I've been developing for *iux web systems for 2 years now on Mac.

That coupled with the ablity to stay connected to the rest of the business world via MS Office for Mac and Adobe tools along with fine opensource apps such as Blender, and Apple only software like Final Cut Pro has been great.

What has happened to Unix is that Apple has developed the better *iux desktop system that coupled with the new G5's has been the final death nail into SGI coffin and put the hurt on SUN. Back in the days at McDonnell Douglas (now boeing), much of the engineering development was done on extremely expensive Sun workstations that could easily run $20k a peice. Today, a lot of development and code is being written on $3000 - $4000 PowerMac G5's.

While Apple remains expensive for many consumer users, in engineering and scientific fields, the PowerMacs with OSX are extremely inexpensive. Many of my friends in scientific fields have flocked to Macs with OS X in the past three years.

Re:OS X

[hey (83763)]

Lots of people agree that OS X is the best Unix going. So now us Linux fans has something to copy. Lets get started.

needs some VMS stuff

[*no comment* (239368)]

I like Unix, but I think I'd add some VMS stuff. Like a Delete attribute. VMS you can set people to have read/write/execute and delete. in unix if people have write, they can write it to "null" *grumble*.

Re:needs some VMS stuff

[pclminion (145572)]

My point was, why protect against somebody "deleting" a file when they can just overwrite it with zeros? It's the same thing, right?

If you really want the kind of behavior you are talking about (although I can't imagine why), you can do it by making a hard link to the file in question into a directory which is "safe" from the user you are protecting against. They are still able to move the file around, modify it, etc. But if they delete it, the second hard link still remains, so the file is not actually deleted.

Re:needs some VMS stuff

[tntguy (516721)]

I can't count the number of times I've dragged a file to the "Overwrite With Nuls" icon on the desktop. This wouldn't help at all!

Re:needs some VMS stuff

[*no comment* (239368)]

Well to work properly it would also need to have the versioned filesystem of VMS. So if someone were to say overwrite it with zero's then you just revert back to the previous version that wasn't zero's. You see? If the file is deleted the file is gone, but if someone changes the file to be useless, then I could jsut revert it. Make sense? There's no way anyone with only write permission could destroy any part of the system permanently. It's just a one command restore.

Program Installation Locations

[ShortSpecialBus (236232)]

The first thing to change should be how programs get installed.

EVERYTHING right now goes in /usr, without a directory, because everybody is too lazy to have /usr/foo/bin and /usr/foo/lib in their respective environment variables, because it's too much of a "pain" to put them in there on software installation, and it makes library linking more difficult.

Right now, if I want to uninstall a program, I have to remove it from about 10 different places, many of which aren't obvious (/etc, /usr/lib, /usr/bin, /usr/share, et al.) and there's no good way to do it.

Find a way (maybe symlinks /usr/lib/foo.so -> /usr/local/foo/lib/foo.so, maybe something else, I don't care) to make it so program installation/uninstallation makes more sense.

Re:Program Installation Locations

[umrk (99195)]

./configure --prefix=/usr/local/stow/foo-1.2
make
sudo make install
sudo stow /usr/local/stow/foo-1.2

Done.

Re:Program Installation Locations

[mandos (8379)]

This is basically what Gobo Linux is trying to accomplish. From their FAQ:

• 
  GoboLinux is a Linux distribution that breaks with the historical Unix directory hierarchy. Basically, this means that there are no directories such as /usr and /etc. The main idea of the alternative hierarchy is to store all files belonging to an application in its own separate subtree; therefore we have directories such as /Programs/GCC/2.95.3/lib.
  
  To allow the system to find these files, they are logically grouped in directories such as /System/Links/Executables, which, you guessed it, contains symbolic links to all executable files inside the Programs hierarchy.
  
  To maintain backwards compatibility with traditional Unix/Linux apps, there are symbolic links that mimic the Unix tree, such as "/usr/bin -> /System/Links/Executables", and "/sbin -> /System/Links/Executables" (this example shows that arbitrary differentiations between files of the same category were also removed).
  
  www.gobolinux.org
  

configuration

[meshko (413657)]

I think the biggest problem with Unix is the lack of standardized way of doing certain things, in particular program configuration. Even simple programs that require very simple configuraiton store it in random places and formats. Not to mention things that require some serious config files, like sendmail, apache or X. Creating a cross-platform powerful configuration language would help.

Re:configuration

[killjoe (766577)]

Ideally all confi files would follow the same format and syntax (god no please don't say XML).

Ideally there would be a uniform way for programs to retrieve configuration information from a centrallized location.

Ideally local users and machines would be able to merge their prefs and config with the master to override certain prefs.

Ideally the hierarcy of administrators would be able to prevent entitities under them from overriding certain configuration options.

Ideally all of that could be done with plain text files which are automatically checked into a version control repository so you can roll back any change in a jiffy.

Does it reliably enable true modern computing?

[Ars-Fartsica (166957)]

Does unix enable people to build clusters, serve multimedia content, create sustainable high-throughput networks etc etc? Yes. Most implementations also provide for these true modern computing environments reliably and cheaply. What else do you want an OS to do? If an OS can reliably enable the modern application layer, to me it has satisfied the criteria of an OS.

While I agree that the core OS has not moved much in decades, I also see very little motivation for this as much of the required functionality has moved up the stack to the application layer.

Plan9 is what's right with UNIX

[andrewzx1 (832134)]

If you read the motivations behind writing Plan9 (documented on slashdot previously), there are many descriptions of what the authors thought was wrong with UNIX. And the guys who wrote Plan9 are the same guys who wrote the better part of UNIX. And for you youngsters, UNIX is not LINUX. - AndrewZ

cynical view

[Keitopsis (766128)]

Problem:
Unix is great!, unless:
- You just want a plug and pray answer
- You just want a word processor
- You just want ......

If someone is only looking for a single application, it is hard to shove such a versitile system down their throat.

Solution:
Create a truely modular UNIX/OS that does not depend on any single environment(init/SYSV). Make a pluggable API-level interface that you can plug anything from a single application to a complete system environment into. Then get someone to develop EXACTLY what you want.

Idiotware without the bloat.

Laughing all the way,

-- Kei

Easy!

[Telastyn (206146)]

Lack of coherent newbie documentation.

Sure, man pages exist, but even once you learn that man does what help really should the man pages are generally written by programmers for programmers.

Newbie guides generally don't get any further than a small command summary, which doesn't really show any strengths of unix over using a gui [or windows!]

The best thing I think would be to provide more "whole system" examples/help rather than help for each individual command. Take some nice simple topics [how to add many users, how to determine network utilization programatically, how to determine open ports and what process is using them...] which are painful to do on windows and use a variety of unix tools to solve them.

There's only one thing wrong with UNIX:

[gellenburg (61212)]

Not everyone's running it.

Laugh.

It's a joke.

The C language

[lazy_arabica (750133)]

Yeah, I know that most *nix lover simply love it. But let's face it : this language, which is still the most important one in a unix environment, is really aging. It is possible to develop big software in pure C, but it takes much, much time, and the risk of introducing bugs and security flows is huge. Only the minimal low-level core of the system should be based on C ; the rest should be developed in a modern, high-level language.

In no specific order:

[Qbertino (265505)]

-the allmighty root (single largest security risk)

-ancient directory organization which doesn't take modern computer usage into account (more powerfull single workstations)

-bad historically grown naming ("home", "usr", "var", etc.) and incosequent File System Herarchy Standard

-crappy vendor support

-unix printing still sucks big time (see 'vendor support')

-grafics system and font handling

-inconsistent standards of configration

-histrically grown elitist utility naming (large anoyance)

That's all I can come up with right now. Note that some of these are dealt with by certain unix variants. Printing and pretty much everything else is a breeze on OS X for instance. Configuraion and installation with Debian Linux is very smooth and goes great length to keep those countless OSS utilities manageable. And Solaris 10 seems to have the one or other card up its sleve to deal with security risks that result in the allmighty root.

Coming to think of it: Can't we just have an OS with OS X ease of use, Debians installation system, Solaris 10 low-level features and Windows Vendor support? We'd all be set and 100% satisfied.

Re:In a word...

[Tackhead (54550)]

> This sillyness of having to generate postscript so Ghostscript can generate PCL so you can print is just wrong - empty brained, someone forgot to wake up wrong.
>
>PCL is available on every major printer on the market today - it IS the standard. PostScript is a has-been. Dump it today.

Huh? I think you've got that backwards.

PCL requires that most of the "brains" exist on the "computer" side of the "computer/printer" connection. A PCL printer needs less "brains" than a Postscript printer because all the processing is done on the "computer" side of the connection.

Not to put too fine a point on it, but a PCL printer is to a Postscript printer what a Winmodem is to a hardware modem.

For printers, the PCL tradeoff made a lot of sense sense when embedded CPUs were (extremely) limited in computational power compared with desktop CPUs. Rather than have your $1500 486-33 sitting idle as it dumps a pile of Postscript code to another $1000 68020 in the printer, I'll use my $1500 desktop CPU to turn my document into PCL that can be parsed by the $1.99 Z80 or whatever's in my $100 PCL printer.

Now that your $25 disposable cell phone has a 200 MHz core, that tradeoff is no longer a requirement. Embedded systems smart enough to interpret and run Postscript code are no more (and no less) expensive than those capable only of PCL.

Methinks you've got the PCL/Postscript design tradeoff backwards.