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?'"
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.
I'm used to reading my system text as a white font on a blue background.
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.
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 */
The first thing to change should be how programs get installed.
/usr, without a directory, because everybody is too lazy to have /usr/foo/bin and /usr/foo/lib in their respective environment variables, because it's too much of a "pain" to put them in there on software installation, and it makes library linking more difficult.
/usr/lib, /usr/bin, /usr/share, et al.) and there's no good way to do it.
/usr/lib/foo.so -> /usr/local/foo/lib/foo.so, maybe something else, I don't care) to make it so program installation/uninstallation makes more sense.
EVERYTHING right now goes in
Right now, if I want to uninstall a program, I have to remove it from about 10 different places, many of which aren't obvious (/etc,
Find a way (maybe symlinks
//FIXME: Bad
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.
While I agree that the core OS has not moved much in decades, I also see very little motivation for this as much of the required functionality has moved up the stack to the application layer.
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
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
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).
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.
Not everyone's running it.
Laugh.
It's a joke.
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.
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.
-the allmighty root (single largest security risk)
-ancient directory organization which doesn't take modern computer usage into account (more powerfull single workstations)
-bad historically grown naming ("home", "usr", "var", etc.) and incosequent File System Herarchy Standard
-crappy vendor support
-unix printing still sucks big time (see 'vendor support')
-grafics system and font handling
-inconsistent standards of configration
-histrically grown elitist utility naming (large anoyance)
That's all I can come up with right now. Note that some of these are dealt with by certain unix variants. Printing and pretty much everything else is a breeze on OS X for instance. Configuraion and installation with Debian Linux is very smooth and goes great length to keep those countless OSS utilities manageable. And Solaris 10 seems to have the one or other card up its sleve to deal with security risks that result in the allmighty root.
Coming to think of it: Can't we just have an OS with OS X ease of use, Debians installation system, Solaris 10 low-level features and Windows Vendor support? We'd all be set and 100% satisfied.
We suffer more in our imagination than in reality. - Seneca
>
>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.
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
OK, you know about Darwin, but if you go to the Apple site you can look at the code for WebCore, OpenDirectory, Apple's Kerberos implementation, Darwin Streaming Server, Apple's drivers for their hardware, their mods to CUPS, Samba, ZeroConf, GCC, Apache, and a whole SLEW of other stuff.
The only stuff they don't give you is the source code to Aqua and their in-aqua userland apps, which makes sense, because giving that stuff away would be business suicide.
When Apple said they were going 'open source' it didn't say they were going to release the source to their core apps, like the Finder and iPhoto, but they've been very generous about contributing the code they borrowed and modified back to the community.
It should also be noted that Apple gives back to the projects they work on, GCC has come quite a way on the PowerPC since 3.0 thanks to Apple.
In my opinion, Apple's strategy is one I'd like to see some vendor take with Linux, you take the kernel and mod it for high-performance desktop apps, get GTK+ running on an accelerated OpenGL framebuffer, tweak and simplify a slew of apps and SELL it. As long as the mods to existing software make it back to the community, it's a net gain for all of us.
"Sometimes, I think Trent just needs a cup of hot chocolate and a blankie." -Tori Amos on Nine Inch Nails
Here are the general problems I have with Unix and Unix-like operating systems:
(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).
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.
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.
Development for apps for "all" linuxs is right out, which means big commercial closed source players aren't interested, which in turn means we have to keep Windows machines around to get some kinds of work done, which sucks.
Actually there are a number of examples which put the lie to your charge, apart from the obvious case where a linux admin doesn't even install a GUI. (linux gives you that flexibility) But a number of commercial vendors provide programs which run on any modern linux distro with X windows, e.g. netscape - but in practical terms, any modern linux distro ships with both qt and gtk apps. So any app built on either native xlib, qt or gtk will run on any modern linux system.
Linux has a pretty poor cache and swap system, combined with zero user level control over cache and swap. As a result, over time, the OS runs slower, and s l o w e r and s... l.... o..... w...... r....... until you restart, and then it's back to being fairly snappy until it fills up memory again with things it shouldn't be caching,
LOL, mod parent up funny - linux memory management is actually pretty decent. I don't buy into the hype about running slower and slower and finally needing a reboot, that sounds like too much microsoft thinking. Our mail servers which are currently on a 700+ day uptime are processing messages just as fast as they were when first booted.
Sorry, your story just doesn't hold up.
Heh. For a really good time, try going into #debian on freenode and asking any question, no matter how esoteric. You're bound to get about three or four RTFMs, and one guy who will pmsg you with more helpful information. Note: I just switched to deb after several years of RPM-based distros, and am not a complete n00b here, so the attitude I encountered was offputting to say the least. Imagine sending your grandma in there for help - she'd probably smack you with her purse the next time she saw you!
political_news.c: warning: comparison is always true due to limited range of data type
You don't ask a question directly; rather, you write something like "Linux sucks because it can't do X but Windows can.".
To use your USB mouse example, you probably went on a board or IRC somewhere and wrote:Note that you asked a reasonable question and thanked people in advance for their help.
This is a recipe for disaster.
The board gurus will pounce on you like a
Instead, you should have written something like:You will have Linux gurus crawling out of the woodwork to show you that, yes, Linux does support a USB mouse, and the reason you couldn't get it to work was probably one of the following: X, Y, or Z, and here is how to work around or fix the problem, and here is where you can find additional information, and here is where you can get drivers or other needed software, or a more user-friendly front end, etc., etc.
Note that their attitude will be as snotty (or snottier) as with the nice method of asking, but you will get the information that you require.
Note to mods: The above may appear to be flamebait or an attempt at humor, but this method actually works.
Try it!
Those who sacrifice security to condemn liberty deserve to repeat history or something. - Benjamin Santayana