Slashdot Mirror


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

15 of 1,318 comments (clear)

  1. 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 pclminion · · Score: 4, Interesting
      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.

  2. 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.
    1. Re:configuration by killjoe · · Score: 4, Interesting

      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.

      --
      evil is as evil does
  3. Re:Program Installation Locations by plover · · Score: 4, Interesting
    Are you suggesting that an installation process more like Windows Installers would leave easier-to-clean-up-code? Because if so, I've got this real nice bridge to sell you.

    The problem I have with an "installer" system is that immediately developers will extend it to do things it shouldn't be doing. "Hey, you know, when we install this program we should have it send gmail invites to six people, FTP a pretty picture of a llama while we construct suitable advertising panels, and create three new users with the authority to start, stop and pause the data subsystem."

    Other than the llama thing, people have done all that crap and more with Windows installation tools. They blindly overwrite shared system files (leading to DLL hell,) they muck up the registry, they install hundreds of class IDs for internal-use-only COM interfaces, plop in unrelated browser helper objects, add random directories to the front of the system path, launch odd services that do god-knows-what, wedge in a startup task or two and then demand you reboot your system.

    It's taken Microsoft many years to realize they couldn't control the installers, and so with XP they changed the OS to try to defend itself from renegade installations. It would be extremely sad to see a UNIX equivalent.

    --
    John
  4. 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.

  5. Re:OS X by ducomputergeek · · Score: 4, Interesting
    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.

    --
    "The problem with socialism is eventually you run out of other people's money" - Thatcher.
  6. 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
  7. The exact location doesn't matter to me. by WebCowboy · · Score: 4, Interesting

    What matters to me is that there is some semblance of CONSISTENCY. That is why I hope more attention is paid to FHS and LSB. Package managers can do the housekeeping--I don't care--but Fedora and Mandrake and SuSE and many others use RPM and their packages are STILL specific to their distros (even though Mandrake started as a supposedly Red Hat compatible distro way back when). I really wish RPMs at the application level were LSB compliant so they'd play nicely.

    On another note, there are reasons why apps on UNIX become installed in shared directories--it is because path management can become tedious--the PATH environment var becomes too long, or else you have to sprinkle links about your filesystem. In the GUI world this isn't really an issue, but some of us still like the command line and write scripts and typing /usr/myapp/1.0/bin/startmyapp instead of startmyapp at the prompt is annoying.

    BTW, it seems you have MS Windows confused with the Mac (the only modern PC platform I know of where the "copy a folder" install method is still commonplace). Win apps most certainly do NOT install in a single directory--nearly all use the central, monolithic, non-human-readable REGISTRY to store configurations, and typically throw .dll and other files in C:\WINNT, C:\SYSTEM32 etc etc. The "install with a single xcopy command" nirvana only exists in the dreams of .NET fanboys (it might be possible technically it won't and can't happen for a couple years yet).

  8. Re:Program Installation Locations by diegocgteleline.es · · Score: 4, Interesting

    Or what plan9 does, just kill the $PATH variable.

    In plan9 you don't have a "$PATH variable", instead you have several directories (/whatever/arch-dependent-bin, /whatever/arch-independent-bin, ~/my-own-bin) and you just "join" them in a single directory: /bin (In plan9 every process can configure their filesystem namespace like they want and normal users are allowed to do things like that)

  9. Re:Program Installation Locations by mce · · Score: 4, Interesting
    Before you make statements about how things are installed on UNIX, you should understand that what you seem to know is a personal Linux box on which you can do everything you please and of which you don't understand the package management. It is not the UNIX way.

    In the true UNIX world, application software has always been such that it can be installed stand alone underneath ONE directory, quite simply because in the true UNIX world not every (other) user has root powers and the people who do have them understand that they don't want to mix shared application files with local OS files the way toy OS-es such as Windows and (sadly) some Linux distros do.

    Where I work, we install evereything in networked directories called /our-company-name/software/package-name/version. Then we wrap everything in shell scripts that automatically select the correct platform (HP-UX, Solaris, Linux) on the fly and that automatically set every single environment variable the softare needs. Then we add links to make a specific package version current and publish the key binaries of packages that many people use through 1 common bin directory. Not a single file needs to be stored and/or managed locally (crucial, considering the amount of machines involved).

    And now comes the best part: I (yes, I developed the setup and do most of the maintainance) do not even need root powers for anything.

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

  11. Problem already fixed, for a while now by daveschroeder · · Score: 4, Interesting

    1. Since Mac OS X 10.0, you could have used UFS with Mac OS X if you really needed case sensitivity (though, using UFS broke some other things, like Classic, some Carbon installers, etc).

    2. Regardless of 1., as of Mac OS X 10.3.x, Apple now has "Mac OS Extended (Case-sensitive)": a fully case-sensitive, fully supported case-sensitive HFS+ filesystem. It's not exposed in the GUI of Disk Utility on Mac OS X client (as Journaling wasn't on Mac OS X 10.2.x client), but it can be enabled via the command line:

    sudo diskutil eraseVolume Case-sensitiveHFS+ DiskName /Volumes/SomeDisk

    man diskutil for more info. This is exposed in the GUI of Disk Utility on Mac OS X Server 10.3.x. If you would like your primary volume to be case sensitive, you can use/borrow a Mac OS X Server CD to boot your machine, format your primary volume as Mac OS Extended (Case-sensitive), and then install Mac OS X (or copy back all of your data with a utility such as asr or Carbon Copy Cloner).

    Case preservation (as opposed to case sensitivity) was never advertised or presented as a "feature"; it was an artifact of HFS.

  12. Amen! by pVoid · · Score: 4, Interesting
    The File System. Sure It Corrupts Your Files, But Look How Fast It Is!

    That's probably the single biggest problem I see with nix machines. Lazy filesystems have always reminded me of experimental planes developped by the cold war military to up the world speed record. Planes which would basically self destruct if they god forbid hit a pothole while taxying out of the hangar. RAID is obviously not a solution, and I find that backups - while essential for mission critical applications - should not be used as an excuse to allow for making a file system that is as brittle as this.

    As a broader comment, I just find that UNIX is a brittle OS. Before every zealot jumps on this statement I should clear up what I mean: the OS components are extremely lean, they do exactly what they're meant to do, but there's absolutely no inherent 'imune system' to the OS. su can go ahead unlink the root node, a power failure and the file system goes to hell, there isn't any cohesive way to manage machine state. Every daemon runs in its own little planet, unaware of everything else.

    The article the other day on /. about Sun's attempts at self healing software address parts of this actually. And other really cool apps like tripwire address other points too. But in general, the OS itself is completly stripped of an immune system.

    When Microsoft first introduced the Windows File Protection service, I was really pissed off they did something which should have been done via proper security measures (which common users were short circuiting by running as admin). But the more I face the idea, the more I realize that it's not a bad idea after all, proper code signing, system level integrity checks, basically a path towards actual 'self healing systems'.

    In general though, everyone has a long way to go still...

  13. Re:That's not just unix. :P by WgT2 · · Score: 4, Interesting

    Wow, I find that interesting. The only job I've worked at where Windows and Linux techs worked in the same office, I found the Windows techs to run the greatest gamut of character: being the most haughty and exclusive to the most inviting and inclusive. That's not to mention how much the Linux techs taught me on the job as well.

    What I found amoung the Linux techs was a greater investment of time, learning, and adapting to a well designed system that requires more out of you. Heck, you can't get away from being a proficient tech without being able to at least type 35+ words/minute. But, that is just an entry level skill to make the rest of your learning easier.

    Because of the learning curve, and the trouble-shooting skills the tech position required, involved in Linux/Unix I can see why some people would take themselves more seriously than meet; thereby deserving of the titles prevously bestowed upon them. Too bad for them, and for you, that they do not instead convey the satisfaction and enjoyment that comes from learning something that does have such a steap learning curve and currently has an underdog image (which really has nothing to do with being satisfying as far as I'm concerned, I just really enjoy the OS itself).

    Hmmm, oh well. I guess when it's all said and done, the satisfaction that I get from knowing, not even on a mastry level, of Linux, makes me not really care what others think of me, but I don't want to put them off either because I'm too self-absorbed to give them the same sort of help I too have received in the past from others in the Linux community.