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.
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.
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
Printing - more specifically, Postscript Printing.
This sillyness of having to generate postscript so Ghostscript can generate PCL so you can print is just wrong - empty brained, someone forgot to wake up wrong.
PCL is available on every major printer on the market today - it IS the standard. PostScript is a has-been. Dump it today.
That is what is wrong with *nix and what I would do to fix it is require all software to support PCL printing directly.
Ron Gage - Westland, MI
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.
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
One big thing that's wrong with Unix is SCO.
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.
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.
That is part of the problem right there. All of you are talking about a lot of complex issues that the common user knows absolutely nothing about, and no one has mentioned this. How about making it intuitive and simple enough so that my grandmother could use it. Maybe then you'd see more people using it than Windows...
No one cares what your captcha was
Houston TX, USA
UNIX and the various shells were designed for when every keystroke counted due to memory constraints and the painful experience of working at a teletype.
As a result, we've got upper- and lower-case flags doing completely different operations (-r and -R for "remove" and "restore," for example), we've got case-sentitive filenames which just make it so easy to tell the difference between "Index," "iNdex," "inDex," "indEx" and "indeX."
UNIX was designed when plain text was king and the only nudies you ever saw were ASCII art.
As a result, there's no way from looking at the filename to tell what program the file should be processed with.
UNIX was designed under the guidelines of "do one thing well, do it quickly and get out of memory."
Those design decisions permeate UNIX and the *NIX community even today. When I read the newsgroups, I still see tips on how to do things that involve piping a file through 17 filters to do something that can be done on Windows with four mouse clicks.
So how would I fix these problems?
1) Make filenames and command flags case-insensitive. The few cycles you spend doing case comparisons will quickly pale in comparison to the time savings you experience in tech support situations where a touch typist accidentally hits space too soon and types "emacS."
2) Several files that do not have extensions usually have some information about their default parser in line #1. Either parse it, or start using file extensions in *NIX.
3) Start making UI's that only initially expose the 20% of the UI that 80% of people will use. There's no reason for a CD-burning package to have a checkbox on the main screen about verifying post-gap length for 99% of the people in the world.
Anyway, that's my opinion.
RomSteady - I came, I saw, I tested. GamerTag: RomSteady / http://www.romsteady.net
-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
Friends don't help friends install M$ junk.
For example:
I do believe there are a few problems with you assertions:
/proc/sys/fs/binfmt_misc/register ]; then /sbin/modprobe binfmt_misc /proc/sys/fs/binfmt_misc
/proc/sys/fs/binfmt_misc/register ]; then /proc/sys/fs/binfmt_misc/register ...
:)
"1) Make filenames and command flags case-insensitive. The few cycles you spend doing case comparisons will quickly pale in comparison to the time savings you experience in tech support situations where a touch typist accidentally hits space too soon and types "emacS.""
That problem is so much easier to fix than changing 20+ years of UNIX design.
UNIX is case sensitive for a reason. Do you think you can just go through all the source files, replace strcmp with strncasecmp, and have a system that works the way you want? No, you'd have to work things on multiple levels, regression test countless applications, etc. You could, for example, make internal shell commands case insensitive, but that's not the same thing.
Plus, by making the switches all case insensitive, you've suddenly halved the number of possible arguments for any program unless they use the GNU extension. POSIX args are 1 character only!
PS: "2) Several files that do not have extensions usually have some information about their default parser in line #1. Either parse it, or start using file extensions in *NIX."
This is done already. As long as the file is marked executable, the shell will properly lauch the parser. You can even add BINARY formats to the kernel. Check out this way to make all MONO programs run automagically:
if [ ! -e
mount -t binfmt_misc none
fi
if [ -e
echo ':CLR:M::MZ::/usr/local/bin/mono:' >
else
echo "No binfmt_misc support"
exit 1
fi
Honestly, most people who come up with "problems" in UNIX either fail to understand the reasons for certain design ideas, or aren't aware of pre-existing solutions to their problems. The init scripts and system startup sequence (in general) in UNIX is a much bigger problem, and one of the Gnome guys is making a great replacement for it.
--
Internet Explorer (n): Another bug -- that is, a feature that can't be turned off -- in Windows.
This is your sig. There are thousands more, but this one is yours.
I think most of us on the Unix Haters list were Lisp machine or VMS hackers who were pretty upset that a piece of utter crap was winning the O/S standards wars at the time.
The forward by Dennis is actually an anti-forward, more of a backward. At the time he was working on Plan-9 which takes all the best ideas from UNIX and junks them, leaving only the unrefined crud that is best ignored.
The book is somewhat uneven in its criticisms, I don't think that the gripes abous X-Windows hit the mark as well as when they are explaining the file systems lossage.
Ultimately the problem with Unix is that it is built the way that cars used to be built before Henry Ford, its a computer O/S for folk who like to spend their time tinkering with their system and like endless opportunities for low grade intellectual stimulation because thats an end in itself for them.
Unix still has the same major architectural deficiencies. The inter process communication is not up to much, the concurrency model is weak, the user interface is eratic and there is no consistency. Documentation is a complete joke.
Looking for an Information Security student project suggestion?
Try http://dotcrimeManifesto.com/
It's not only a matter of saving disk/memory space; you also have the question of what to do when a bug is found in the library ... Should you download a new binary of each program that uses that library? And what if the developer is on a vacation when the bug is reported, most of your programs will be fixed, but that one is still vulnerable until he gets back?
...
The same goes for improving algorithms
I'm not speaking of unix specifically, but of Linux. But I hope this enlightens anyone.
./configure-make-make install and recompilation pain, etc etc etc.
Linux isn't friendly for:
* Installing apps
* Guiding the Joe user to a friendly painless installation of the OS itself
* customizing
* configuring
in other words... everything.
As many linux fans that there are here, the only *great* thing that Linux has, is its security and stability. Everything else is more or less, a mess. The apps, they're great! But only AFTER you manage to intall and configure them.
And on the other side, we have a wonderful MS Windows in which everything (BUT security and stability) is great, but security and stability is a mess. I admit it, Linux infrastructure is very well thought... but the rest? The problem is that Linux (or unix for that matter) was made "by nerds, for nerds". Windows was made "by executives, for Joe users". What we need is an OS made "by nerds, for Joe users".
And that means not rejecting as "blasphemy" everything that MS Windows has. There are many good points in windows, but (i'm generalizing, but this is my impression) linuxers are too busy defending their "way of life" against the competition, that they can't improve it. They have formed themselves a mindset saying "Linux is perfect. We don't need no stinking windows thingies. Anyone who says so has been too much in contact with the evil windows, and must be deprogrammed". If someone dares say "but..." he's just rejected as some microsoft borg slave.
And they've repeated this lie so many times that they've ended up believing it. They make this whole bunch of "user-friendliness" *patches* for Linux, so they can believe that it's good the way it is.
Well, guess what. It isn't. Give me a Linux with the user-friendliness of windows (and I DON'T mean the GUI - i mean the versatility, plug-n-play, ability to easily install new apps without the
What I mean is:
Linux (as a whole) is a good set of implementations. What it needs is a good set of standards, and ONLY THEN, develop good implementations of these.
Want an example? We have KDE, QT (is that spelled right?), and I forgot if there was any other.
So there are apps compatible with QT that can't run on KDE, and viceversa.
Maybe you guys haven't still seen the big picture, but what I see of Linux development is more or less this:
a) Some guy makes a good thingy for Linux.
b) Many guys follow him
c) Another guy makes another good thingy that does the same than the first one, but it's incompatible.
d) Many guys follow him.
e) GOTO a)
From a religious perspective, compare with Roman Catholicism and protestantism. Roman Catholicism would be Windows (one pope called Bill Gates who dictates what is true and what isn't) and Linux would be the protestant denominations incompatible with each other. Some survive, some die... etc.
Sociologically, protestant denominations are very similar to Linux implementations. They share one very limited creed (the Bible / the Linux Kernel), but how that applies in their lives (the implementations) vary. SO MUCH that they can't be united (I remember the SCUMMVM team - or was it another? - splitting because a guy liked one editor, and the other guy liked another editor. And they argued so much about this that the whole dev team dissolved.
Linux needs a "pope". Or a government council (like the W3C) which says which way apps will interact with each other, with the kernel, and with the hardware.
Let me rephrase it: Linux needs STANDARDS. Linux needs something like "a W3C" government which publishes a standard, uniformed API of doing things. Like what the w3c did with the DOM (and so we can prevent things like the "browser wars" happening in Linux.
One of the reasons WinXP flourished is that it had a standard way of doing things. Make them compatible with the API (even if its security is as solid as a gruyere cheese), and they r
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
Yours is the most enlightening - novel - suggestion I have seen on this page so far.
If I was google, I would hire you.
I realise 100% you were talking in jest, but you were thinking outside the box, most of the other suggestions have been seen in one form or another before.
liqbase
After choosing a file to be manipulated by an exec'd process, the standard utilities all require a path to the file, instead of leaving the file open and passing the fd number on the commandline. Linux nearly has the infrastructure to handle this correctly with the existing tools and their command line interfaces by abusing /proc.
The shell needs further enhancement to make this clean so it is reasonable to expect people to write multi-process and multi-binary programs securely.
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.
Linux is not Windows
I like Linux. A lot. I use it all the time, and I develop for it as well. I feel that it will not make a lot more inroads into more general acceptance until some of these things are cleaned up. Users don't generally care if there is a D bit in the protections. They generally don't care if the OS has cool things like logical volumes (like those provided the Amiga's "Assign" command) even if they are really neat, and let me forestall some arguments by saying that I agree that they are. Users care if the machine is easy to use, if the tools they want and/or need are available, and if the machine feels fast -- no one likes buying a 3 GHz machine with a couple gigs of ram and watching a minor application take 10 seconds to load.
So mostly, people don't run Linux. And that's what I think is wrong. But fix it, and they will come. IMHO. As for Unix... I really don't care. :)
I've fallen off your lawn, and I can't get up.
So which do you prefer? Unix Man Pages that contain all there is to know about a certain app in a not quite end user refined form or Windows Assistants ("Did you plug in the Cable?" - "Yes" - "Then I can't help you - call your vendor") and cryptic error codes?
I prefer MSDN. Call me when Unix has something that even approaches the ease of use and the amount of readable samples, explanations etc. of key APIs.
And no, the System V paper manuals don't count.
Coming soon - pyrogyra
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.
Hi. I'm an mcse and I'm not a moron (or so I believe). Pleased to meet you.
My false modesty tells me I shouldn't toot my own horn, hence the AC.
I've been managing unix like boxes for several years now.
I got my mcse because my company needed me to (sales purposes, don't ask) and paid for it. I learned a great deal about windows servers/workstation I didn't know about. Most of it positive. I still wouldn't put an unfirewalled windows machine on the internet. Today, I admin a couple of windows servers, plus several solaris, freebsd and linux boxes.
As I said above, it is a selling point (our customers like MS and Cisco certs more than anything else). And if tomorrow I find myself looking for a new job, it probably won't hurt to have them on my resume.
Macs are only cool now, since OSX was released. Before that, there was OS 9, OS 8, etc. Not exactly cool operating systems.
what, what?
Many people are quick to say that if (l)unix 'were more like OSX' it would be better. While I agree that OSX is a nice operating system, has a good set of utilities and built-in programs, and provides a nice, friendly user interface, the same results could not be achieved in (l)unix.
The reason Apple is able to devote time to making the GUI pretty, or creating these great applications is the limited hardware base they support. Mac OSX has nowhere near the hardware support provided by Linux or Windows. Don't get me wrong, the PowerPC architecture is great, however, the lack of other options concerns me. I personally try to avoid vendor lock-in as much as possible.
I personally would like to see better vendor support (Ie ATI ).
Also, while competition is great, it would be nice if the main windowing systems (KDE or Gnome [QT Vs GTK])were more compatible with each other (or we just choose one). Being able to run QT apps in GTK without loading all the extra KDE nonsense would be nice....
Last note, greater standardization would be good too. Choosing *one* package management system that could be deployed across all dristros would be nice (Perhaps incorporate the best of the existing package management systems into one, cross distro system). It would make it easier for developers (only one package to make), admins (got a few different distros? ), and the general public (if more people use this utility, chances are a greater portion of those people will donate money, time, or other resources to the project).
The W3C is an interesting idea, but *it* may not be the best idea. First of all, having a central organization setting standards does *not* mean those settings will be followed. Take, for instance, CSS. The standards are clearly defined by the W3C, however creating CSS documents that look exactly the same across IE and Gecko browsers is not easy. Moreover, people complain that getting features into the kernel takes a long time already, adding bureaucracy will only increase the delays....
Excellent points are made in many of these replies, and what we need is to take the best of everything; the clean GUI of OSX, the standardization provided by a consortium including industry vendors, greater vendor support, and unify some of our efforts.
Competition is good, but only so long as it does not ultimately make the users life more difficult.
- Provide a true serial console solution for x86 hardware that enables everything from BIOS changes to OS install on bare metal - this would bring the X86 platform up to where UNIX was 20 years ago (and don't tell me about IPMI until there's hardware using the 2.0 spec)
/usr/local/ for that. Nowadays, Linux treats everything like it belongs in /usr. What exactly is *not* a system binary or library in a linux distribution?
/sbin and /usr/sbin? - Give me *one* - how about only /usr/sbin so we can keep / with fewer entries?
/bin and /usr/bin? How about only /usr/bin.
/usr/share/foo vs. /usr/lib/foo vs. /etc/foo vs. /var/lib/foo vs. /opt/foo vs /usr/local/share/foo vs. /usr/local/lib/foo vs. /usr/local/etc/foo .... Kill me now, please!
/etc/mailcap if it exists and is properly configured. Write a simple GUI to configure /etc/mailcap and then all mail apps will be happy
- redo the whole privileged port thing. When only root could become UID 0 and start a process on a port under 1024, maybe this meant something. Today, it's a joke
- kill the GNU info format. Could anything possibly be less useful that INFO pages?!? Sheesh. Manpages have become a standard - Everything should have a manpage.
- Manpages must provide at least 5 example command strings for sample usage with description of what those options do.
- In the days of UNIX, we all knew what were system binaries and what was GNU/other. We used
- Central area for Internet-based config files. Try to set web/ftp proxy information in a single location and have it honored by more than one or two programs
- Strict adherence to commonly used environment variables like HTTP_PROXY, NO_PROXY by any internet-enabled app. There should be more like NNTPSERVER, SMTPSERVER, IMAPSERVER, POPSERVER
- Do we really need
- Do we really need
- for application foo, what should go in
- sar was great, but I need a year's worth of data, and I would really like to have some trend analysis automatically done and know that my bottleneck over the past week has been XXX and was due to process YYY
- mail programs should all be able to default to using
- Make X11 session state transportable. I want t o be able to transport my entire X session from one Xserver to another Xserver without losing the state of any apps. (not just a view via VNC... the whole GUI app)
Out of curiosity, what UNIX man page would I go to to learn how to write a GUI "hello world" program in that environment?
Karma: Terrifying (mostly affected by atrocities you've committed)
If you'd spent slightly longer in #debian, you'd know that we're absolutely flooded with people who aren't prepared to learn things, and just want those who already know to do everything for them. When questions are asked by someone who is having troubles which the documentation (which they have read) does not solve, they do generally get helpful and correct answers quickly. I got struck down repeatedly when I first started going there, and was not a complete "n00b" either. However, I'm not so thin-skinned as to take it personally, and now I'm more at home with reading things for myself, which is the right way to be.
In any case, with regard to your grandma, you ought to send her to the Debian Reference instead ;-)
There are four relevant parts to Unix:
When Ransom Love bought Unix on a lark (my IPO was so huge... look, I can buy Unix...), the value of the name except as a trophy dropped to nil.
The public domain code and it's functionality lives on in BSD where some find it useful. Perhaps one day this branch will prove as versatile as Linux, but I doubt it.
The proprietary code and its functionality nobody in their right mind would want, because "The Future is Open(R)(TM)".
The POSIX architecture has been reimplemented in Linux in a more consistent way than using most proprietary *nix wares, and in parallel the technology of operating systems have been advanced to support more advanced concepts.
Before the parts were rent asunder, they ruled the server room. Now they have been broken apart, and like humpty dumpty, they'll not be put together again.
Unix is dead.
Help stamp out iliturcy.
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
Installing software is highly unreliable, non-standard, a maze of twisty little interdependant passages, and deeply obscure.
Really?
For the end-user, it's as simple as an apt-get, rpm or emerge command (or whatever package manager you use).
Ah, you're talking about the developer? About installing software that is not packaged? Well, try that on windos. Come back when you're done, like 2006 or so.
There is no standard "windowing" GUI
Which is a huge advantage.
I happen to hate the XP/windos standard GUI, and there's nothing I can do about it. I tried a few replacements, they all suck, are incomplete, break the system or simply don't work because the friggin GUI is so tied into the OS kernel.
On Unix, you can choose which GUI suits you best. I prefer to choose myself instead of having some marketing monkey in Redmond make my choices for me.
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,
Troll
tom@nox:~$ uptime
10:04:32 up 132 days, 17:49, 3 users, load average: 0.08, 0.06, 0.07
tom@lemuria:~$ uptime
10:00:18 up 156 days, 2:00, 1 user, load average: 0.02, 0.03, 0.00
tom@Mandor:~$ uptime
10:02:44 up 31 days, 21:01, 1 user, load average: 0.02, 0.01, 0.00
All of these are systems that are in constant use as desktop (nox) or servers (lemuria and Mandor). They're very snappy. I've driven one of them (nox) close to the thrashing point once, brought it back and it's been running well ever since, without a reboot.
You, my friend, have fucked up your system, that's all. Don't blame it on the machine.
Oh, and it's a very, very good thing that regular users have no control over cache and swap. If you don't grasp the security and reliability dangers inherent in giving them that control, you should give back your root access.
The GUI, in the user sense, is an afterthought. You have to go to the command line to configure and/or adjust and/or install many things.
Again, this is a strength, not a weakness. When your GUI breaks on windos, OS X or any other GUI-only system, you're fucked. On Linux, I can drop to the commandline and within a minute or two everything is running fine again. Sure, it may not really be faster than a reboot, but if you have stuff running in the background, then you don't really want to reboot.
Assorted stuff I do sometimes: Lemuria.org
Gnu's Not Unix
If you read through the discussions you see a trend where this or that is missing from the core but it is available as an addon. Everything is there and documented but you have first know what you are looking for and then find it and install and configure it.
No one solution is right for everyone so there is much fragmentation and LOTS of features that are completely customizable. That is what is both wrong and right. And then you have the ever increaseing revisions which have an amazing amount of dependancies. Which again is both what is wron and what is right.
You can not have your FOSS and eat it too. It is this way by design.
This would not be a problem if "the file has been deleted" was just another version of the file. The fact that VMS (and also CVS) got this wrong does not mean that there is a difference between write access and delete.