Slashdot Mirror

← Back to Stories (view on slashdot.org)

What's Wrong with Unix?

Posted by Cliff on from the defects-and-potential-solutions dept.

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?'"

25 of 1,318 comments (clear)

  1. Several frustrating points by SIGALRM · · Score: 5, Insightful
    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.

    --
    Sigs cause cancer.
    1. Re:Several frustrating points by Anonymous Coward · · Score: 5, Insightful
      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.
    2. Re:Several frustrating points by jargoone · · Score: 5, Insightful

      Add another thing that's wrong with Unix: the elitist attitude towards outsiders.

    3. Re:Several frustrating points by insert_username_here · · Score: 5, Insightful

      Mod parent up!!

      I've been happily using Linux on my home PC for about 4 years, but the filesystem layout has always been an annoyance.

      Without a package manager, it's practically impossible to remove a program; even with a package manager, you can't even determine how big a given package is! (if you know how to with Portage, I'd like to know). A better filesystem layout (perhaps the way MacOSX, GoboLinux or RoX does it) would make package managers obsolete.

      A lack of standard configuration layout is another thing: why should people have to learn hundreds of config file formats? Yes, comments help, but it'd be nice if they weren't needed. Why not come up with one standard text-based config format/filesystem layout and get everyone to use it? This would also save programming time, as you could create a library (with a name like libconfig or something similar) and not have to worry about parsing configuration settings. The Windows Registry Hell can be avoided by using a text-based format(e.g. like Java properties files or XML).

      A standard configuration layout (with suitable metadata) would also go a long way to allowing a standard graphical system configuration utility (Whatever happened to linuxconf? I loved that app!), making Unix/Linux that much more accessible to ordinary people.

      Replies, flames, etc.

      --
      -- Dramatisation - May Not Have Happened
    4. Re:Several frustrating points by MarkByers · · Score: 5, Informative

      even with a package manager, you can't even determine how big a given package is! (if you know how to with Portage, I'd like to know)

      equery size package

      equery is part of gentoolkit

      --
      I'll probably be modded down for this...
    5. Re:Several frustrating points by linguae · · Score: 5, Insightful

      I strongly agree. Snide comments such as "BSD isn't for you," especially if the person trying to install it seems interested in learning about it, isn't going to help the Unix installed base grow. Such trolls hurt the *nix community in general because they are turning away prospective users.

      If anything, us Unix users should be trying to convert as many people as we can to our OS, not turning them off and turning them away.

    6. Re:Several frustrating points by antoy · · Score: 5, Insightful

      Given the skill and experience that it takes, in my experience, to be able to run Unix as naturally as some people do... perhaps they've earned that attitude.

      That's complete nonsense. Installing and running Unix hardly counts as one of the more difficult intellectual tasks. It's hard, sure, if you're used to something different, but the description 'windows people' includes novelists, artists and nuclear scientists who just don't give a damn about the stupid OS their computer runs.

      Would you like it if an artist made fun of your pens and call you and your friends BIC people? Well, that's how stupid this sounds.

  2. Screen is too black... by raile · · Score: 5, Funny

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

  3. OS X by BWJones · · Score: 5, Insightful

    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.

    --
    Visit Jonesblog and say hello.
    1. Re:OS X by hey · · Score: 5, Funny

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

    2. Re:OS X by edesjard · · Score: 5, Insightful

      This is actually a really good point. My biggest complaint about Linux has always been that it constantly tries to copy WINDOWS which I have been totally disgusted by and why I love my Mac. I keep hearing that everyone wants OS X on x86 hardware. Why hasn't Linux, which appears to be floundering aimlessly, focused its efforts on being more like OS X than Windows? Isn't it what will REALLY motivate people to give Linux a try?

  4. needs some VMS stuff by nocomment · · Score: 5, Interesting

    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*.

    --
    /* oops I accidentally made a comment, sorry */
    /* http://allyourbasearebelongto.us */
    1. Re:needs some VMS stuff by tntguy · · Score: 5, Funny

      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!

  5. configuration by meshko · · Score: 5, Interesting

    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.

    --
    I passed the Turing test.
  6. Plan9 is what's right with UNIX by andrewzx1 · · Score: 5, Informative

    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

  7. cynical view by Keitopsis · · Score: 5, Insightful

    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

  8. KSpaceDuel by jkauzlar · · Score: 5, Funny
    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).

  9. Easy! by Telastyn · · Score: 5, Insightful

    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.

  10. The C language by lazy_arabica · · Score: 5, Insightful

    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.

  11. Here's a start: by Slack3r78 · · Score: 5, Interesting

    The Unix Hater's Handbook

    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.

  12. Re:Program Installation Locations by umrk · · Score: 5, Informative
    ./configure --prefix=/usr/local/stow/foo-1.2
    make
    sudo make install
    sudo stow /usr/local/stow/foo-1.2
    Done.
  13. Re:Program Installation Locations by mandos · · Score: 5, Interesting
    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
    --
    Mike Scanlon
  14. Re:In a word... by Tackhead · · Score: 5, Informative
    > 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.

  15. Re:Program Installation Locations by i+am+fishhead · · Score: 5, Interesting
    Well, it depends on what you want to do. Until I started to admin a linux cluster, I didn't really understand why this was done either.

    1) Most of the folders have a PURPOSE. /bin has vital system binaries (sh, login, and so on), /sbin has binaries and daemons vital to starting up the system, /etc has files containing startup and default settings, /var has variable information (like logs), /tmp is for temporary files, and so on.

    Why is this powerful? Well ...

    - Want your machines to behave similarly on startup? Replicate /etc on these machines or have them mount a shared /etc on top of the original early in the boot process.
    - Want to have faster access to temporary files? Make /tmp be on a ramdisk.
    - Want to limit log sizes so they don't fill up the disk? Make a seperate partition for /var
    - Want to shared data across a bunch of *nix boxen? Make /usr/share and friends NFS shares.
    In general, You can do interesting things by combining the fact that directories are usually per-purpose rathar than per-program. Granted, in the desktop world, this isn't so much useful, but it makes cluster management and system maintainence SO much easier.

    2) The issue you complain about can be taken care of by a package management system or some arangement of symlinks.

  16. My list. by Yaztromo · · Score: 5, Insightful

    Here are the general problems I have with Unix and Unix-like operating systems:

    • Threading models and scheduling. A few Unicies have decent thread models, but others have abysmal thread models and scheduling. Because of this, far too many Unix applications wind up eschewing threads for simply running multiple processes, which isn't the same thing. Thread priority needs to be global, and the thread should be the most primitive execution unitt upon which all other execution units are built. No more "my thread priority is set to the max, but I get very few slices because my process priority is set low". My OS/2 machine running on a P3-450 can still out-thread many multi-gigahertz Unix systems, and that's just sad. Too many Unix kernels have had threads bolted on as an after-thought, and it shows.

      (Note that this isn't to say that every Unix-style system has a bad threading model -- some of them are pretty good, and others are getting better. But it's currently difficult to write decent cross-platform multithreaded Unix code when some Unicies you know in advance have really crappy threading subsystems).

    • Clipboard support in GUI subsystems. Come on, it's 2004 already. Unified clipboards have been around for more than 20 years now, and yet many Unicies still can't get this right. Cutting and pasting between applications shouldn't be a major PITA. Users shouldn't have to worry about which widget library an application was compiled against to figure out if they'll be able to paste to that application from another. Things are getting better, but really, this should have been fixed years ago, and shouldn't be taking so long.
    • GUI application font support. Again, a rare few get this right, but most of them have this big conglomeration of font types, and no unified font access system. Windows 3.0 had a beter font subsystem than what some Unicies have.
    • Printing. Again, some Unicies have done a good job, but far too many still don't have a good unified printing subsystem. Others here have done a great job of pointing out the problems with Unix printing in general, so I won't rehash them all here.
    • Desktop access APIs. Even with KDE and Gnome, there still isn't an API to call to do something as simple as create an application icon on the desktop or in the application menus which can be used to launch an application. Everyone winds up having to roll-their-own, if they bother to do so at all. Again, not all Unix GUI environments suffer from this, but the majority do. As I developer, I shouldn't have to care what environment a user is running if I want to do something like put an icon on their desktop as a part of an installation/configuration routine -- there should be an API I can call that says "create an icon with the following properties", and have it worry about WM/environment specifics.
    • USB driver development and device access. Again, in many Unicies this is fundementally flawed and can be very difficult for users to set-up and configure. And it differs drastically from Unix to Unix. Where we have pretty standard systems for accessing RS-232 serial ports, and parallel ports, USB access is completely non-standardized across Unicies. Just witness the PITA it is to set-up the newly standardized javax.usp API on Linux, and the kernel work-arounds that had to be implemented to allow APIs like this to unload aggressive modules that grab interface focus immediately just because they were included with the distro. There isn't much excuse for this IMO.
    • Unicode support. Again, hit or miss.

    Okay -- now don't get me wrong -- there are a lot of things to like about Unix and Unix-like environments. But those are the items I personally have problems with in the general case (and again, not all Unicies exhibit all of these issues. In particular, Mac OS X doesn't suffer from any of them, and is my current OS of choice for doing development and as my personal workstation desktop environment).

    Yaz.