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?'"
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 */
Maybe I am just stupid but it is kind of hard to install. I am a Unix newbie. I have downloaded FreeBSD and almost had it installed but I have failed many times, therefore going back to Linux or even Windows. If they can make the installers just a bit more user friendly like this, then I am all for it.
Friends help you move...
REAL Friends help you move dead bodies... ^_^
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.
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
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.
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.
GoboLinux is a Linux distribution that breaks with the historical Unix directory hierarchy. Basically, this means that there are no directories such as
To allow the system to find these files, they are logically grouped in directories such as
To maintain backwards compatibility with traditional Unix/Linux apps, there are symbolic links that mimic the Unix tree, such as "/usr/bin ->
www.gobolinux.org
Mike Scanlon
Files: this is one thing Windows has right. There should be all sorts of capabilities built in to Unix: append-only files, append-only by user, unchangeable permissions, and so on. FreeBSD's flags are the way to go, but like I said: they should be built in to Unix, not an extra add-on.
And a subset of that is coarse permissions of files. Why in God's name do we still enforce root-only opening for ports built in to Unix, not an optional add on. Something like "chgrp www /dev/tcp/80; chmod 600 /dev/tcp/80", rather than having to open as root then drop privileges (hope you did that right!), would be amazing.
Carousel is a lie!
Why the microkernel part? Although I don't have much experience in this, I'd say it should be quite simple, relatively speaking. Look at Linux, most of the kernel tree is drivers. The kernel itself is pretty small.
From reading stuff and watching discussions what I got is that the problem with microkernels is that they're hard to properly implement and still have fairly bad performance. In fact, I hit those same problems when trying to code an extremely modular application, that I tried to write as an experiment.
My experiment consisted in writing a small chat server in the most modular way possible, that is, the core does almost nothing, and everything is implemented externally, with "services". Soon it became clear that if you go at it this way, there's lots and lots of latency. For example, a service could trap events. The theory is that I let people just login without a password, then a module overrides that, requiring whatever authentication method was desired. It would be modular to the point that it could do completely different things depending on the services running.
In practice this meant that a login would arrive to the server, get parsed, be forwarded to the service which would do its own processing, get sent back to the server, which would finally reply to the client. Now imagine this happens almost during every request.
Now, of course I'm not a programming genius, perhaps somebody can pull this stuff off with good performance and make it look good, but the point is that I finally realized that I could write a very basic chat with shell script and named pipes, while this thing would need thousands of lines of code before starting to do anything at all. Linus' quote about message passing and masturbation seems to fit here quite well.
The correct solution to this problem was investigated in Plan 9. Plan 9 has a great many features that one could discuss, but the relevant one to this discussion is its threatment of filesystems. In Plan 9 EVERYTHING is a filesystem. Probably as a result of this, there are a lot more things that you can do with filesystems. In particular, you can mount multiple filesystems at the SAME location in the filesystem and view the contents of both filesystems. (in case you're worried, the behavior for writing to such a location is well defined) Thus each program could have its own files in its personal set of filesystems which could automatically be mounted on top of /usr/lib and /usr/local/bin without actually combining everything in one place. To remove an application, it would just be necessary to remove its filesystems and all the relevent files would disappear. This is one of the excellent results of the great experiment called Plan 9 that should be integrated into other systems like *NIX.
One of the nicest features of Windows is the standardised use of COM throughout. Everything about the shell is done through COM, which allows progams to work in a consistant and predicatable manner. Cut'n'paste, shell extensions, drag and drop. namespace handlers, OLE embedding, scripting, automation etc is all possible and well supported by most programs because of this use of COM.
Unix may have some form of COM, but it is far from the kind of support that is available under Windows. It is the reason clipboard and document embedding is such a pain under Unix, and why the shell 'feels' clunky and basic operations such as drag and drop between applications isn't possible.
So bring in a standard COM system, and standardise the shell interfaces and you will have kde and gnome applications that can integrate with the shell without having to have separate progams.
I.O.U One Sig.
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.
/usr/myapp/1.0/bin/startmyapp instead of startmyapp at the prompt is annoying.
.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).
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
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
Or what plan9 does, just kill the $PATH variable.
/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)
In plan9 you don't have a "$PATH variable", instead you have several directories (/whatever/arch-dependent-bin,
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.
Linux user since early January 1992.
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. /tmp be on a ramdisk. /var /usr/share and friends NFS shares.
- Want to have faster access to temporary files? Make
- Want to limit log sizes so they don't fill up the disk? Make a seperate partition for
- Want to shared data across a bunch of *nix boxen? Make
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.
BeOS is dead, and last time I heard about it, OS X runs all of Darwin as one big process. Now, this area of my knowledge is very fuzzy, but if true then it's not much of a microkernel, when if I understand correctly, the original idea was to have lots of little components.
NT might have been somewhat of a microkernel in NT 3.51, but it's not anymore. Win2K is a NT system, and I haven't seen it resist driver failures. In fact, any serious kernel failure results in a BSOD, followed by a reboot. Heck, even Linux seems to stand kernel oopses better, because quite often it does manage to continue despite a failure.
I think you misunderstood the part about pipes. I was meaning to use it as an agreement with Linus' quote - that a kernel that does message passing accomplishes absolutely nothing by itself, and that writing a server the "microkernel way" was resulting in a lot of code that did nothing useful at all.
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).
/Volumes/SomeDisk
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
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.
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...
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.
..as a Mac admin since '97, it's blackly amusing that now that Apple's shipping unix, all my old linux friends are now flaunting powerbooks. :P
:|
OS X takes the bullshit out of getting Work Done, and that's nice- but in the process, the platform has transitioned from the domain of artists and eccentrics to the khaki-clad GAP-shopping technoratti richass motherfuckers, who have no use for any of the reasons the platform has continued to exist over the past 20 years.
My OS-that-runs-Art doesn't exist anymore. Apple's replaced it with an OS that does everything but Halflife... and to get that, they had to round off some of the edges.