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.
Google called me a wimp for not answering the non-mathematical questions. At MathWorld News,you can see how Eric and I answered all the other questions.
And yet Linux is becoming an increasingly common choice for all sorts of embedded, special-purpose devices.
A lot of people don't really understand what UNIX is. At its heart, it is just a philosophy, not a system. A way of thinking about and solving problems which has remained relevant and useful for decades. All real-world UNIX systems have lots of crap bolted on, out of necessity, but the inherent "UNIX-ness" of the system emanates from the design philosophy, not the implementation or application.
UNIX is a How, not a What.
I know that a lot of people think it is a great thing, but it is really problematic. It makes great sense on systems that have fixed disks, but once you start having transient filesystems (network filesystems or removable drives) it becomes a real problem. If a filesystem is removed then programs may segfault since the mapping disappears. All other entry points for this sort of thing fail at a system call (read or write) which allows for graceful recovery. Conceivably the OS could inform the user or insert a zero filled backing, but that could lead to data corruption.
This is a particularly bad problem for desktop systems, where the users are not experts. For server or cluster systems it is not an issue.
I second that, world could be so much easier already if we just had wildchard support in PATH and other environment variables.
PATH=$PATH:/opt/*/bin/
or something along the lines could make life much easier.
The throuble is really that the current filehierachie was designed to only contain a basic unix system, (ls, rm, libc, etc.) not a fullblown multimedia desktop, as what most linux are today.
Stuff like the LHS don't even try to fix the mess, they just standardize it. Most likly we will be stuck with the current mess of a file hierachie for long time to come and hardcompiled paths in a bunch of binaries don't make it much easier to get rid of it either.
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.
While Apple has done a great job for the casual desktop user mac os x has a long way to go before it can be considered a reliable server platform.
Hopefully they will have a decent port/package system for tiger, hopefully not every update will require a reboot, hopefully updates will not require to agree to EULAS, hopefully their GUI helpers will not clobber your carefully crafted conf files.
I keep hoping anyway. Till then I have chosen to go back to freebsd for my sever needs. The xserves are now for java based services only and only if the code does not require 1.5.
evil is as evil does
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
Ummmm, well how about this?
There is nothing that I talked about in my post that did not take serving up web pages into account. In fact, the standard OS X is robust enough to withstand a Slashdotting on even low end hardware. Witness a little old G3 iMac hosting a vision education resource we have here. This little iMac is running a standard OS X license (not server) and hosts upwards of 45,000 hits per day from all over the world. Not huge traffic, but pretty impressive for a desktop OS and a 400 Mhz G3.
So, what is it you are talking about specifically?
Visit Jonesblog and say hello.
It will not run well on the first computer I slaved away for. DELL Service Code: 696ML
? fuse=71
GNU all the way baby.
Revenge
http://www.legaltorrents.com/index.php
Exploding? Do you have a citation somewhere?
Remember a huge percentage increase off a small installed base is still a small installed base. i.e., if you atart with 1 computer, a 10000% increase is adding 100 machines.
"I'd rather be a lightning rod than a seismometer." -Ken Kesey
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!
If you have 1000 files on a unix system, and they are all 90% similar, the system should be able to figure out how to store 90% of those blocks in the same space. And manage them so that none are deleted until all references to them are deleted. See Venti.
there's no way from looking at the filename to tell what program the file should be processed with. And there shouldn't be! File extensions is an ugly hack that MS stole from CP/M. The problem is, there is no mechanism to guarantee that two different pieces of software are not using the same extension, meaning you get the wrong default parser! That's what MIME was designed for; why not simply associate a MIME type with every file? Even Microsoft is backing away from the use of extensions now, and switching to GUIDs registered in the registry, which at least are PROBABLY unique.
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.
If you build anything from source on any RPM based box, CREATE AN RPM FOR THAT INSTALL. It is VERY easy to do if you take 30 minutes to figure out how to write a spec file.
Then ALL the files in that installer are referenced in the final RPM, and to remove all the stuff you simply remove it using the rpm tool.
On debian it's much the same but with a deb instead of an rpm.
To install a deb file, just do "dpkg -i filename". Seems a lot like rpm, doesn't it.
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.
kernel: The semantics of setuid class of calls is very confusing. Worse, it varies from from one flavour of Unix to another.
Look at David Wagner's "Setuid Demystified" paper The graphs in pages 9, 10 and 11 are scary.
user level programs:
I use Microsoft Windows sometimes and I find the "system restore" to be a nice feature. It is just convenient to press a button than worry about depdencies when you screwed up etc. Especially useful is you are sending a laptop to your computer illiterate mother in India and expect that she is probably going to try and install some random programs. If something goes wrong, I can ask her to turn the clock back, sitting in the other side of the world.
Sudhakar
No discussion about the flaws of Unix is complete without a reference to the Unix Haters Handbook. (Ignore the URL - Microsoft had nothing to do with it) It might be getting a bit dated, but some of the points are still relevant, and it is very very funny.
Part of the problem is definition: exactly what from each current OS paradigm (each one of which reached its current form for a reason) should this ideal Unix take, and what should it leave? As soon as one gets into the gritty parts of the answer, no one can agree, people splinter their OS, developers don't know which OS to target and users are confused. I don't remember where I read it (Daring Fireball, possibly), but someone pointed out that creating a new standard from two conflicting standards often simply creates three conflicting standards. And these days there seem to be Standard^N standards. The problem is that no standard will leave 100% satisfaction because no single person's needs are identical to another person's.
In addition, there's the massive Windows install base that gets so much vendor, developer and other support that inertia works against the large-scale -- and by large scale I mean more than 10,000,000 people -- end-user machines. That means developers/users/vendors can target a myriad of smaller *nix OSes or the giant OS.
Furthermore, although I agree with your problem list above, I'd add the lack of a standard API. If one wants to develop for Windows, there is a more-or-less monolithic API. For OS X, there is Cocoa or Carbon. For Unix and Linux, I don't even understand the situation sufficiently to name all the possible API permutations. Each permutation has its reason for existance. Which brings me back to my first paragraph, which is that each splinter of *nix has its reason for existance. This makes writing high-quality GUI software for heterogeneous deployment difficult. To solve that problem, maybe someone will create The One Distribution, but then someone else will dislike something about it and fork it or write their own One Distribution, which will have problems of its own (like adoption and incompatibility with other standards).
Before someone accuses me of describing the problem rather than solving it, allow me to plead guilty. Much as I don't know how to solve the seemingly impossible muddle in the Middle East, I don't know how to solve the *nix problem. I use OS X, which solves all the bulleted points of the parent poster (or at least solves them well enough for my purposes), but the OS X entry cost is also relatively high. I'd love to see a low-cost *nix match or surpass OS X, but I cannot forsee that happening in the near (next three years) future.
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
You are a bit misstaken.
In fact, the gap between host cpus and printer cpus has never been wider.
Back in 486 days, those printers had i960 or other cpus inside who could do some tasks faster than the host cpus.
Those got faster and faster while the dedicated rasterization engines of printers crawled forward. If you buy a 2-3000$ laser printer, what do you get? At most a 300Mhz PowerPc 603 or something like that that isnt 1/10th as fast as any 500$ budget pc.
The only reason PCL printers are often slower than PS native printers is the amount of data generated while rastering high res pages that have to squeeze over usb...
Of course, there are tons of PRACTIAL advantages, but not really technical ones.
HI O WISE PRINCE. WHT TOOK U SO DAM LONG?
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,
Or unless you value your time, perhaps.
I include the "perhaps" because it's unwise to make an absolute statement regarding operating systems unless one knows a great deal about a particular situations.
Yes and no. For workstations, laptops, etc., yes, ease of use is very desirable. For servers, especially mission-critical ones, ease of use takes a backseat to reliability. It may take me a little longer to get my Solaris, AIX, or Tru64 machines ready for "prime time," but I know that they'll be solid workhorses when I'm done.
Don't take this as a slam again Linux, *BSD, etc. as server OSes. They're more than capable and very reliable, they're just not currently tuned to utilize the horsepower of an E12k, a p690, or a GS320 cluster.
"It's too bad stupidity isn't painful." - A. S. LaVey
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.
... er ok it's performance isn't fabulous. NT is sorta a microkernel (with a lot of rules broken), and its I/O still spanks everyone else (owing to its VMS-inspired design). Plan9 is a microkernel.
BeOS is a microkernel. OSX is a microkernel
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.
Linus, to put it mildly, doesn't know a fucking thing about microkernels, yet feels qualified to spout off on them every chance he gets. Thankfully, most microkernels are written by people who are at least pretty close to being actual programming geniuses, and astonishingly enough aren't a bunch of shell scripts cobbled together with pipes. Go put down the Mach book and try taking a look at L4 sometime.
I am no longer wasting my time with slashdot
The main problem I see with my preferred brand of Unix on the desktop is I have to run it on a Mac to get the pretty widgets/gadgets.
.app bundles are cool. code/library/config/resources scattered all over the hard drive is not..
Give me OS X/ X86 or I'm gonna club this here baby seal!
Not having to muck around with getting X11 is cool. Hats off to folks like Knoppix who manage to make a setup that works out of the box with most systems..
Printing.. Printing needs to get sorted out a bit better. Too many people have problems printing or find themselves buying a postscript printer just to have it work somewhat well.
Configuration: Preference panels to hande configuration are nice. editing config files with vi/emacs/joe/etc is not all that nice. It's nice to be able to do either, though..
I honestly don't really care how it all works underneath, just that it does.
Simple UI's.. So many group are making desktop environmentst that look like and work like windows.
Simple is good. Windows UI is only simple because you use it for years..
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.
the allmighty root (single largest security risk)
:wq to write and quit in vi) once you learn it. I'm not sure what you mean by "incosequent".
How do you propose this be fixed? I think it's important that there be a user with the ability to do anything. This includes the ability to create users with only some administrative-level permissions, or even the ability to delete the root account entirely.
bad historically grown naming ("home", "usr", "var", etc.) and incosequent File System Herarchy Standard
This is one of those systems that's entirely arbitrary to someone new to *nix, and yet it seems entirely intuitive (much like [Esc]
histrically grown elitist utility naming (large anoyance)
I think part of this is backwards-compatability related. dd could be renamed to "DiskDuplicate", and cp could be "Copy," with "rm" renamed to "Delete". But then absolutely, positively everything that uses these commands would explode, and current *nix admins would be entirely confused. I'd like to think that the utilities will keep their names; you can always symlink them to a clearer name if needed. (Some systems try to be friendly to ex-DOS users, by creating, for example, "dir" as a symlink to "ls")
More and more often, though, GUIs are taking the place (for people who aren't hardcore shell users) of cryptically-named commands.
BTW, when you talk about Debian's installation system, do you mean package management (apt-get), or the initial installation of the OS? apt-get was very easy to use, the installation of Debian itself, though, was a nightmare when I tried several years ago.
________________________________________________
suwain_2
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.
Having done some OSX server work, I like some things in it (compared to Solaris, Linux, HP-UX, NetBSD and OpenBSD) but I get thrown off when things don't work as expected.
Case in point: using OSX as a file server for Appleshare (mac clients). I need to move files from one directory to another.
On the server, I use the GUI to drag 'em. Ownership & permissions are not preserved. Rats. Plus I have to sit there like a trainned monkey for the error message & to fix things if they don't go right.
Ok, I have lots of files so I want to script it anyways. I use cp -r or mv or tar cpf - | (cd blah;tar xpf -). Permissions & ownerships are right, but all the icons are wrong. Mac files have a data and a resource fork. The unix command above only works on the data fork so you lose the resource bits.
The solution is a modified version of rsync (rsyncX) or a program called ditto that comes w/ MacOSX. Intuitivly obvious 'eh?
Try performing file-system-level backups of a Unix system without being superuser. You can't -- there's no way to set up a user that has read/execute access to everything but write access to nothing.
Managers need to be able to list, create, delete, read, write, and change permissions. [etc]
Writing should also be split into overwriting, appending, and truncating - with having all equivalent to write permission.
For instance: Append without the ability to overwrite or read lets someone leave a message or data without examining or damaging what's already there. Think "mailbox". Overwriting without appending prevents arbitrary expansion of the file, and so on.
Permissions also need to be not just in terms of users, but in terms of users, applications, or combinations of them. For instance: Jerry can use this set of tools to write-append to this mailbox, and that set (but no other) to examine and modify the bug database.
Bantam Dominique roosters crow a four-note song. Once you've heard it as "Happy BIRTHday" you can't NOT hear it that way
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...
The Linux kernel actually implements a good compromise, which is to allow kernel modules to be plugged in and out, which is one of ideas behind microkernels. However, there are still user-facing problems with this approach that could be cured without going the microkernel route.
For example, Linux does not provide stable binary interfaces between the kernel and modules, so you can't just plug in any driver -- it has to be compiled against your kernel. This is a political decision; Linus does not want binary drivers. A solution would be something like a source driver package that the driver manager GUI could access and transparently compile; but this, or any other solution, would require the Linux developers to put some thought into kernel user-friendliness, and that is not their strong suit by any means.
The other issue is that of security. At the moment, device driver loading and file-system mounting are superuser operations, but they shouldn't need to be. (User-friendly security in general is one of Linux/Unix' weakest points.)
Btw, I believe the argument that microkernels are inherently slow has been shot down.
This much is solved fairly easily by installing CUPS.
Most UNIXes still come with lp or lpr printing solutions, which were great when you had an honest-to-God line printer -- a printer that just printed line after line of straight text -- but are woefully inadequate for modern page printers with their page description languages.
There are all sorts of hacks to get around this. There are filters, once designed to massage ASCII text, now used to try and re-encode stuff into appropriate PDLs. There are things like JetDirect (eew).
CUPS does a much better job of making printing transparent. By converting everything to one PDL (PostScript), and then converting it to the printer's native language if required, everything gets treated evenly. There are lots of drivers. I find it far, far easier to administrate than lp and lpr.
I find it useful to monitor which technologies Apple integrates into Mac OS X, and then try installing them on my other UNIX systems. That's how I discovered CUPS. Apple has cherry-picked best-of-breed open source for OS X.
Look, folks, you're mainly bitching about poor documentation or poor file system organization, with some change left over for not liking the setuid/gid thing which seems like a hack now, but was way cool back in the day.
/etc/passwd to a gdb database indexed on username might be something like /etc/passwd |(gdb) application.
Back many years ago I was proposing something called NERU "a New Enviornment Rationalizing UNIX". Here were some things that I was really interested in doing then:
- uniform addressing schemes that make memory and the file system look more homogeneous.
- typed entities replacing files what carried along their pointers to their own operations. Think of it as an "object oriented file system".
- shell or scripting mechanisms with type casts; say, transforming
cat
- uniform versioning based on copy-on-write: any time you touch a named entity, it automatically has a current version and an old one.
That was 20 years ago (and some of the ideas weren't all that new then the uniform homogeneous model for storage was part of IBM System/38 and is now part of AS/400.)
If you really want to "fix" UNIX, you need something more than fiddling with the file hierarchy organization.
The filesystem permissions are stored on the filesystem... The entities that have permissions - users, groups, roles, containers, etc, etc, etc - are in NDS. NWAdmin/ConsoleOne definitly makes it appear that it is seamless and all in NDS, but it is not.
Netware definitly has more permissions, but POSIX ACLs do add a lot. It is realy a matter of effective, easy, consistant tools.
For the record, Novell Open Enterprise Server (Think Netware 7, with either a Netware or Linux/SuSE core), is in public beta. With it, you can run NSS volumes under Linux quite happiliy. There are some things that Linux NSS does not yet support, but to some degree, with OES the "OS" doesnt matter -- Netware and Linux can be in the same cluster, use the same NSS volumes, and offer the same services.
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.
they don't keep whittling toothpicks out of redwoods because it makes them look like skilled carpenters. The cotton gin would never have been invented by a person such as you describe. They'd find great intellectual pride in doing the job by hand.
I'd think the person a complete fool.
Work Safe Porn
..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.
I've had the same experience with Firefox and plug-in installs (under MEPIS Linux), finally got a work-around by linking from the Firefox plug-in directory to the Mozilla plug-in directory where the installers were actually putting things. Would be better if the installers were Firefox aware. Then, I "apt-get upgrade"d my system into oblivion, and had to reinstall from scratch, actually went fairly smoothly, my home drive was preserved perfectly - but I lost all my plugin links and custom installed libraries I need - at least the Firefox bookmarks are in home, they were saved.
Back off the tangent to the thread - the eliteist attitude of *nix shows in so many ways, and it hurts widespread adoption, which is to its ultimate detriment. Auntie M may think a boot screen that says "GRUB" in plain text is funny, and slightly disturbing - leading her to choose the more "normal" operating system. Try selling your mainstream boss a development environment supported by some Scandanavian guys who call themselves Trolltech... all these little attitude statements add up to keep the rebels on the fringes of the galaxy.
Of course, if you like living on the ragged edge, just keep putting out seriously good software with dorky icons and queer names - it won't bother the people "who actually have a clue."
Clue: 90% of the population doesn't have a clue, but with numbers like that the clueless are an important force to be reckoned with - especially if you're trying to earn a living.
ACLs suck for system data. Here's why --
;))
you can't audit your system easily. If I want to verify that my permissions are in order in Linux, I do ls -l and can see easily. ACLs blow that idea to smitherenes. Then, when applications don't run, it's usually not obvious which combinations of ACLs need to be changed, so you wind up completely compromising your system just to get one COM application to run.
ACLs for user data? Sure. Makes sense, and Linux has them. ACLs for system data? Shouldn't even be allowed. If I weren't lazy, I'd even use different filesystems for user and system data -- they have completely different access patterns, organization, and security needs. (Of course, on Linux, you _can_ set different partitions to be different filesystems
"UNIX needs proper application packaging with proper self-contained application packages."
Exactly. We all need to steal Mac OS X's design here.
"but a proper message/event marsheling system would eclipse them all."
CORBA is already pervasive in GNOME.
Engineering and the Ultimate
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.
Actually, you would be amazed at how snobby and particular artists are about
their tools. I've seen flamewars (only in person, not via computer) ranging
from which is better, white sable or sable to who makes a better technical
pencil, Berol or Koh-i-noor. Don't even get started on airbrushes. So,
having a fight start over being called a BIC person isn't as farfetched as it
sounds.
SealBeater
-- Its survival of the fittest...and we got the fucking guns!!!
No... you shouldn't need to know how every layer of a system works to use the top layer. But, every layer should be independent, and be standardized.
Of course, this makes things inefficient. But, let the hackers do things more efficiently. Most people have money and time to burn.
In order to use a computer, you should only need to know some sort of standard top level, which can be built on an underlying general system administration level, which sits on top of process management, on top of hardware management, on top of a hardware/software interface, on top of on top of hardware-level communication and negotiation, which sits on top of fine-level control of the hardware, which sits on top of the hardware itself, which sits on top of the system busses and circuitry, which sit on top of the electrical system, which sits on top of the power grid. Obviously, most of this works pretty well, already, because you don't need to know that current and voltage are 90 degrees out of phase in AC to download dirty movies, for example.
But, to make this kind of interoperability possible, EVERYTHING between a given two layers needs to be proprietary (the mac camp) or EVERYTHING between a given two layers needs to be open (the OSS camp). If intel wants to keep their secrets to themselves, fine, but the instruction set, chip timings, electrical characteristics, and ANYTHING else anyone might possibly need to know better be available in full detail.
"Undocumented" is the devil incarnate. (Note to Microsoft: please publish your whole API. Not just "almost all" of it.)
How is this not better than the current Unix way of doing things?
One, you lose the benefit of shared libraries.
Two, you don't get the app categorized in your program menus. (Throwing every app imaginable into an application folder is horrible management)
Three, not every app does it this way, they also use the installer, for which I have yet to find a way to uninstall apps installed with the installer.
Finally, the apps will still walk all over your Library directory when you run them, and they won't clean up after themselves after you drag them to the trash.
(1) Linux is not user friendly.
.EXEs and turning my PC into a spam zombie. Configuration was done automatically, not requiring me to download and install drivers that bloat the system tray into incoherence.
How friendly is formatting your disk every few months when the latest windows virus clobbers your system? I know many windows users who have this problem constantly, I don't see how anyone can find that user experience friendly.
If you use a sane distribution, adding and removing applications is far easier than in Windows. In the distribution I use, Ubuntu Linux, I have thousands of applications available to install from a convenient interface, no need to download
The only excuse you have for saying Windows is easier is if you buy hardware that is designed to only work with Windows. Well fuck, if you buy Phillips screws it's your own damn fault you are stuck with Phillips screwdrivers, hard to blame Robertson screwdrivers for not being easy to use.
(2) Duplication is Bad
There are many examples of duplication of effort, you listed one of the prominent ones. But you neglect to consider that rational people can have different preferences. I prefer a slick desktop that is simple and Just Works, and I am very happy with my Gnome desktop. Others prefer a powerfully configurable and animated system that is great for the latest eye candy, and they are very pleased with the KDE desktops. Others sacrfice some of the features of those projects and go with XFCE or other cut-down DEs that suit their preferences.
Get it? It's not bad that people have different ideas on how to get things done. The major desktops all share a system tray standard, work together on freedesktop.org, and are soon scheduled to share the underlying media platform. Indeed, because of the rivalry Gnome is pushing to add new features, and KDE is pushing to make their interfaces more friendly and consistant... and both projects will benefit as a result.
(3) Linux standards don't exist
Yeah, it would be great if there was a group that set such standards. It could be called the Base of Linux Standards, or the Linux Standards Base, or something like that. Anyhow, I'm sure they'd work out a name, but on behalf of Linux users everywhere I thank you for your brilliant and fact-checked suggestion.
501 Not Implemented
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.
Nonsense. If you write the code that links hardware to software, you need a language that extends fully both ways.
C may not be the best choice for applications anymore, I certainly agree. But for the OS core, there's simply no contender. The various proof-of-concept attempts to write an entire OS in C++ or Java, for example, are solid failures.
Assorted stuff I do sometimes: Lemuria.org
I'll just mention that these same issues were handled quite well in NeXTSTEP.
-jcr
The only title of honor that a tyrant can grant is "Enemy of the State."
Don't forget that you can't just set the default install path to C:\Program Files\YourApp when developing an app either, as a lot of non-english windows versions use a different dir for this, quite annoying how they try to hide the "real" filesystem layout from the user yet translate it to your native language so it's harder for an admin from one country to work on a computer from another...
/Mikael (from .se where it's C:\Program\, no " files" here..)
Greylisting is to SMTP as NAT is to IPv4
Well, maybe that's because you:
Or, the greatest mortal sin of all time:
But no, we're the bad guys if we tell you to read "man ls" instead of taking 5 minutes to type out part of the man page for you and explain it to you like we would to a pre-schooler.
WTH does that even mean?
Now before I get modded down, I be to remind whoever might read this that what I am saying is FACT. - bogaboga
According to various people, the ACLs on different Unix implementations are not all the same. FreeBSD varies from Solaris varies from Linux, and Linux's may be based on a draft that was withdrawn (there seem to be differing viewpoints on this). The ACL implementations are all somewhat similar, but are different enough that they don't really work well together. Even on Linux, ACLs are implemented at different levels -- some at the application level (certain FTP daemons), and others at the filesystem level. Even there, the implementations may vary.
Until such time as ACLs can be universally implemented, this is going to be seen as an impediment.
You can never go home again... but I guess you can shop there.
To some extent this is because people are too reverent towards the core of Unix -- it's as if the stat and inode structures are sacred relics which mustn't be touched. But that's nonsense: Unix is a hacker's system, so if those structures need to be augmented, they should be!
There's work being done in this area, of course, but someone needs to step forward and put a big stick in the ground saying "this is an attribute filesystem and API to it that everyone can and ought to use to centralize file-related metainfo."