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

Comments

Several frustrating points

[SIGALRM]

What's wrong with UNIX? Depends on which perspective you start...

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.

Re:Several frustrating points

[XaviorPenguin]

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.

Re:Several frustrating points

[Anonymous Coward]

In addition:

1. Crappy filesystem. Resier4 or XFS is what UNIX should have started with and even now we don't have file versioning.
2. POSIX permisions suck. The suid bit sucks even more. ACL's make more sense, and UNIX should have had them from the start. If we're doing it now, capabilities would be even better.
3. IPC primitives are poor. SySV shared memory goes some way to helping, and UNIX domain sockets are O.K, but a proper message/event marsheling system would eclipse them all.
4. The filesystem hierachy is an awful mess. Non-standard across all unices and poorly evolved to cope with modern systems. /etc was a horrible copout and it shows. UNIX needs proper application packaging with proper self-contained application packages.
5. Providing lots of little applications to do specific tasks was the best idea ever, but not providing a decent scripting language to bind them together was a bone-headed mistake. Likewise not standardising some basic data-interchange formats (Even it was just pre-formated ASCII) just makes piping all those little tools together to do anything useful a pain.

Re:Several frustrating points

[Anonymous Coward]

Let's make UNIX not suck by Miguel de Icaza. Answers this exact question in quite a lot of detail! Try out the UNIX Haters handbook [warning: big PDF] for a more humourous take on things!

Re:Several frustrating points

[vadim_t]

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.

Re:Several frustrating points

[Anonymous Coward]

I'll make you a deal; you go back to reading comics and the rest of us will continue to use UNIX. Let me point out your mistakes, as they are many.

No decent scripting language? In Unix?

In UNIX, sure. Show me the default scripting language in UNIX v6. Bourne Shell is the closest thing you get.

/etc is ugly?

Yes. It literally means "etcetera". It is intended to hold all the junk that didn't fit anywhere else. It was a sloppy solution; instead of finding a place for all those scripts, binaries and conifguration files they all get dumped in /etc. With different file formats.

Oh and you're the only one talking about the Window registry.

How is message passing IPC better than sockets or shared memory or named pipes?

1) The sending and recieving process don't need to know about each other before hand 2) You can easily broadcast events to all listeners 3) Much easier to send arbitary data 4) Much easier to manage; no need to mess with sockets APIs 5) Much safer; no need to share memory between process.

ACLs are coming, but I believe that POSIX permissions make privilege management very simple, very straightforward, and very effective. ACLs may provide finer-grained permissions, but nothing that cannot be done via groups and permissions.

You can believe what you like about POSIX permisions but those of us who have to deal with big systems know that they suck. They suck big, coarse grained, poorly thought out rocks through straws. The are very simple, very straighforward, but that makes them useless for proper security because they're too simple. If you think that ACL's have no advantage over POSIX permisions you're wrong a second time on this.

The SUID is still a horrible solution, and come to that so is the "All or nothing" attitude of the All Mighty UID 0. ACL's solve all of that.

Re:Several frustrating points

[eliza_effect]

Maybe he got BSD because he doesn't want to be a "Windows Person" anymore..

Re:Several frustrating points

[jargoone]

Add another thing that's wrong with Unix: the elitist attitude towards outsiders.

Re:Several frustrating points

[Anonymous Coward]

etc is ugly? Yes. It literally means "etcetera".

Common misconception. Actually it stands for "everything configurable".

Re:Several frustrating points

[Anonymous Coward]

I wanted to say nu-huh but I can't find any reference to /etc being "etcetera" nor "Everything configurable" (Although I find some non-reliable sources for it being "etcetera". My BS detector is screaming "Backronym" at me though, even more than it usuaully pings for "Unix System Resource" for /usr. So I still side with it being "etcetera", just because.

Re:Several frustrating points

[snorklewacker]

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.

BeOS is a microkernel. OSX is a microkernel ... 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.

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.

Re:Several frustrating points

[Martin Blank]

Five different groups need different abilities on a single directory.

• Managers need to be able to list, create, delete, read, write, and change permissions.
  
• Secretaries should be able to list, create, read, and write.
  
• Technicians should be able to list, create, delete, read, and write.
  
• Sales should be able to list and read.
  
• Certain miscellaneous people should be able to only read, so they can be given a link to a file but not see the other files in the directory.

Now, how exactly is this done with POSIX permissions in a simple, straightforward, and very effective way? I can't see how it can be effectively done without ACLs. The lack of ACLs is a major impediment to uptake of Linux in the business community.

Re:Several frustrating points

[insert_username_here]

Mod parent up!!

I've been happily using Linux on my home PC for about 4 years, but the filesystem layout has always been an annoyance.

Without a package manager, it's practically impossible to remove a program; even with a package manager, you can't even determine how big a given package is! (if you know how to with Portage, I'd like to know). A better filesystem layout (perhaps the way MacOSX, GoboLinux or RoX does it) would make package managers obsolete.

A lack of standard configuration layout is another thing: why should people have to learn hundreds of config file formats? Yes, comments help, but it'd be nice if they weren't needed. Why not come up with one standard text-based config format/filesystem layout and get everyone to use it? This would also save programming time, as you could create a library (with a name like libconfig or something similar) and not have to worry about parsing configuration settings. The Windows Registry Hell can be avoided by using a text-based format(e.g. like Java properties files or XML).

A standard configuration layout (with suitable metadata) would also go a long way to allowing a standard graphical system configuration utility (Whatever happened to linuxconf? I loved that app!), making Unix/Linux that much more accessible to ordinary people.

Replies, flames, etc.

Re:Several frustrating points

[vadim_t]

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.

Re:Several frustrating points

[MarkByers]

even with a package manager, you can't even determine how big a given package is! (if you know how to with Portage, I'd like to know)

equery size package

equery is part of gentoolkit

Re:Several frustrating points

[kantai]

You are even more correct than the parent! My God. The thing broken with Unix is standardization. For a group of people always whining about standards... how about if all the information for applications went into a certain directory, lets call it /apps, or /opt/apps for user installed applications or how about ALL config files being in the same directory? I know (not Unix) Debian does this (ALL system-wide configs are in /etc/foo), but it is the only one doing it.

Re:Several frustrating points

[Randy Wang]

Given the skill and experience that it takes, in my experience, to be able to run Unix as naturally as some people do... perhaps they've earned that attitude.

The installation process alone, as one of the parents said, can sometimes be nothing short of excruciating, and after that a newbie still has to learn to get around a completely unfamiliar system, and use it normally. Finally, to be able to customise your lovely little Unix box to bend to your will at the slightest command - anything from adjusting your desktop environment (or lack thereof) to tweaking the kernel For Great Justice - you've shown yourself to be considerably more skilled with your OS of choice than the majority of computer users.

So maybe some Unix devotees really do deserve to have an elitist attitude. I'm not saying they should, just that some people have something to show for it.

Re:Several frustrating points

[logicnazi]

No, quite frankly most microkernels are written as CS Ph.D student thesis where they only need theoretical appeal. At best they are usually implemented in a small theoretical setting where they need not deal with the messy interfaces and hardware present in the real world. Of course there have been some real world exceptions and BeOS might be one of them.

Certainly microkernal design has some compelling advantages. The same advantages any layer of abstraction adds, greater code reuse and easier code maintenance. Effectively we get the same benefits from keep a consistant binary format/software interface. However, the benefits of abstraction often come with performance penalties, and often inhibit innovation if they are not designed perfectly the first time.

The issue is as much one of programer organization as it is of engineering superiority. Micro-kernels or monolithic kernels can all accomplish the same things but they work better in differnt organizations. A corporation which often has sharp organizational distinctions between groups coding differnt sections, the money to invest in R&D to define an efficent and extensible interface and often lacking the flexibility to allow one individual to dictate his coding styles a microkernel is quite appealing. In contrast for an open source project, which often lacks expertise when they first begin coding a solution, the explicit interfaces in the microkernel would strangle them with all their bad design choices. Moreover, enthusiasm and many eyes allows them to both handle the extra code maintenance and ensure consistant coding style without rigidity.

Finally I just don't understand the point of your argument. Linux is bad because Linus is not personally an expert on microkernel vs. monolithic kernels? Can I equally well say your post is bad because you are not an expert either but simply relying on what others say.

Religious battles in coding are just stupid. Despite what many CS professors want to believe deciding between differnt design models is more about psychology than engineering. It is difficult for even one person to hold all the code they wrote clearly in their mind and impossible for a group project, so we evolve tools like microkernels to compartmentalize our programs and help us solve the organizational problems of programming. Howwever, it is just downright silly to forget that the ultimate goal is to solve the psychological problem of getting people to create a large project. Clearly Linus has managed to overcome this problem and if you think better why not go do it yourself.

It is plain stupid to value theory over results.

Re:Several frustrating points

[cicadia]

Except that writing an empty file is not the same thing as deleting the file. In one case, the file exists, can be opened and read (with appropriate permissions,) and has size 0. In the other, the file no longer exists, cannot be opened for reading at all, and has no defined size (or any other metadata).

Deleting a file in Unix simply means removing the file's entry from it's containing directory. This is why deleting a file in Unix requires write permission on the parent directory, and has nothing to do with the permissions on the file itself.

Re:Several frustrating points

[linguae]

I strongly agree. Snide comments such as "BSD isn't for you," especially if the person trying to install it seems interested in learning about it, isn't going to help the Unix installed base grow. Such trolls hurt the *nix community in general because they are turning away prospective users.

If anything, us Unix users should be trying to convert as many people as we can to our OS, not turning them off and turning them away.

Re:Several frustrating points

[mrroach]

> The lack of ACLs is a major impediment to uptake
> of Linux in the business community.

This is not at all insightful. It is uninformed at best. Posix ACLs exist on ext2/3,xfs,reiser,jfs. These ACLs are also completely supported by Samba (and have been for many years).

-Mark

Re:Several frustrating points

[antoy]

Given the skill and experience that it takes, in my experience, to be able to run Unix as naturally as some people do... perhaps they've earned that attitude.

That's complete nonsense. Installing and running Unix hardly counts as one of the more difficult intellectual tasks. It's hard, sure, if you're used to something different, but the description 'windows people' includes novelists, artists and nuclear scientists who just don't give a damn about the stupid OS their computer runs.

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.

Re:Several frustrating points

[Earlybird]

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

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.

Re:Several frustrating points

[Mordanthanus]

Not to mention that that this is the whole reason why linux will never be a mainstream desktop operating system... people that like the idea of an open source operating system, can do some minor programming and want to use something a little "out of the ordinary" and a bit more powerful than the "standard" OS (I'm talking about me here) can't seem to get simple little things to work like sound, a USB mouse or the extras in my docking station. And I like Gentoo. The OS seems fantastic. But god forbid I ask a question on IRC or anywhere that someone knows anything about linux. I have been flamed and ridiculed tirelessly over "n00b" questions.

You know what? I will figure this stuff out. And yeah, I probably will have an elitist attitude when I'm through... but guess what. It will be against all the inconsiderate pricks that wouldn't take the time to help me with some "n00b" questions that I am sure they had at one time too.

And back to my original point... if someone just coming into linux gets attitude from "the gang", they will probably get tired of it and switch back to what everyone else is using... cause I don't know about you guys, but who the hell needs another hassle in their life than to learn all of this stuff when all they want to do is just USE THE COMPUTER.

Re:Several frustrating points

[crmartin]

It's clearly time for my periodic "you young pups don't know your history" posts.

1. Reiserfs etc are the results of 30 years of research that, well, hadn't happened 30 years ago. the i-node/u-node business was the best there was. Then.
2. Multics had general, configurable, role-based, magic ACLs; UNIX lost them on purpose becuse it wasn't well suited to a big games system and word-processor, which is what UNIX was meant for originally.
3. When I was a kid we hardly HAD processes, much less IPC. Having named pipes was a helluvan innovation.
4. That's not the operating system, that's book-keeping.
5. /bin/sh WAS the coolest scripting language ever. They've gotten better. text files with field seperators (that all passwd(5) is, after all) were the uniform data representation.

If you were to go back to System 3 UNIX, you'd have most everything you're asking for here. It wouldn't be as powerful, but it'd be uniform.

Re:Several frustrating points

[T-Ranger]

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.

Re:Several frustrating points

[X]

Responding point by point:

1. It's easy in hindsight to critique filesystems. While the original SysV filesystem was pretty bad, the Berkeley Fast Filesystem was already pretty good for it's time. The simplicity of the Unix filesystem has actually been a key aspect of Unix's success. Even on platforms with more complex filesystem API's, you don't see much in the way of applications taking advantage of them.
2. POSIX ACL's have been around for a long time at this point. The relatively pathetic rate at which they've been adopted and taken advantage of should be a clue to their shortcomings. Several security experts have pointed out that while ACL's are great on paper, in reality they increase the complexity of the security model, which in practice is more of a liability.
3. SysV has message queues for IPC. Everything you could want and... not a lot of people use them. ;-) ONC RPC also prvides a pretty decent message/event marshalling mechanism, and you don't see a lot of new apps being written to use that either. Think about why. I would say though it'd be nice if there was a better standard model for kernel events beyond signals.
4. I honestly still find advantages to the traditional Unix FSH, particularly for administrators. It certainly beats the crazy structures on Windows or OS X. End users increasingly care less about where program files are located on their system, so this seems like the wrong area to work on things.
5. Unix did include decent scripting languages, and more importantly provided for additional ones to be added to the system (witness the rise of ksh, perl, python, etc.). If there had been any kind of data-interchange format that was remotely useful, it surely would have dictated how Unix tools work with those data formats. Unfortunately, there were weren't (and aren't). Consequently, dictating standards wouldn't have solved the problem you're describing, as you'd still have to translate non-standard formats into the standard formats and back again. Letting tools like sed/awk/perl evolve to solve the problem seems like a far more practical approach if you ask me.

Re:Several frustrating points

[Eravnrekaree]

Yes, I certianly agree. We should try to make Unix-type systems more avialable to everyone and that means some good GUI configuration tools.

The big problem with Linux, BSD, etc, is few are being paid to develop for these platforms, thus we dont have a lot of people who can work full time to improve things. We need to find a way to pay developers of open source projects so they can work full time on these projects. With that I think we would see an increase in quality including lots of nice GUI tools for non-techie users.

I think furthermore techie and non-techie users can both share the same system and techies can have full control and low level access to the system well non-techies can have the easy to use GUIs at the same time. GUI configurators can be made to automatically produce the human readable config files, thus we can have both config files, GUI tools, and a rich command line environment.

As far as Unix itself, I think overall the system is very good and no changes should to the core concepts should be made, the directory layout is good, the basic concepts are good, X WIndows is good. I have heard people say that the X Windows API is prehistoric. Nonsense, its just a low level API and its designers didnt make the mistake of just offering a bunch of high level widgets but created an API providing graphical primitives high level widgets can be created with. X API is designed for widget construction, not for direct use by applications.

Basically what is needed is more full time developers, including for the GUI tools.

Re:Several frustrating points

[AmberBlackCat]

The installation process alone, as one of the parents said, can sometimes be nothing short of excruciating, and after that a newbie still has to learn to get around a completely unfamiliar system, and use it normally. Finally, to be able to customise your lovely little Unix box to bend to your will at the slightest command - anything from adjusting your desktop environment (or lack thereof) to tweaking the kernel For Great Justice - you've shown yourself to be considerably more skilled with your OS of choice than the majority of computer users.

I think your post also provides a pretty good answer to the original question. What good is an operating system to average computer users if you have to be more skilled than the average computer user to do anything with it?

Re:Several frustrating points

[johnnyb]

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.

Re:Several frustrating points

[DeputySpade]

If anything, us Unix users should be trying to convert as many people as we can to our OS

Why?

To what end? As a *BSD person, what do you really care how many people run NetBSD instead of Windows 2000? Does it matter? Does it affect your life somehow? What, in the proverbial nutshell, do you bloody care? If I was a windows user and you came along with your attitude that you "should be trying to convert" me, I'd want to smack you.

In many cases the response "Slackware isn't for you" may be perfectly true. Maybe that person should cut his teeth on Fedora or Gentoo or one of the other easy distros where things are done for you rather than one where you have to already be a genius to get it working. That's fine. If starting out at moderate complexity is too overwhelming, then maybe that user should start out with something easier.

A lot of times, however, the situation is even more simple than that. As someone who spent 4 good years of my life on a #linux helping people get off the ground with all variations of that particular OS, I can tell you there are some people who just simply should stay with the Redmond distribution. Some people want you do actually do it for them. I'm not exagerating. Some people literally ask if they can give you a root shell to configure X for them. Look... Learning to use a new OS and being stumped by the new paradigm is one thing. Being a lazy (l)user is another altogether.

Based on my personal experience, 2 out of 10 times the "X just isn't for you." means "pick something a little less complicated to cut your teeth on. The other 8/10 it means "No... I'm not going to spoon feed you your applesauce. When you're willing to actually _LEARN_ something, then you can try something other than that which you know by heart, but until then, go away."

Re:Several frustrating points

[SealBeater]

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

Re:Several frustrating points

[cbreaker]

What you fail to realize is that Linux doesn't exist for newbies to switch off of Windows. It's not there to "Fight The Power."

It's an Operating System. Some people enjoy using it. I do; I love the things I can do with my unix boxes so easily that come so difficult on other systems (Windows.)

You can use it if you want to. There's so many great people working on making it better, easier, etc, that in the end it MAY very well be just as easy to handle as Windows. It's not there yet. What's the rush? So you can install it easier before you know the system?

You're inexperienced in the Internet world if you think that the Linux userbase is a bunch of "inconsiderate pricks." You should see some of the Windows help forums, or the help forums of... anything else, really. There's a lot of pricks out there, you can't avoid that. I have not found this to be any greater with Linuxish forums, mailing lists, etc. In fact, I find that Linux help groups are a lot BETTER then most; there's usually quite a few people that are really knowledgable and willing to help.

Your experience with being called a n00b could be due to the fact that you've been asking the same tired old questions, without reading any of the redily available information online or using the search function on forums. There's a lot of people that WANT to help you - even though you're a complete stranger - but these same people don't want to trudge through the same questions they've already answered a hundred times over.

If you just want to "USE THE COMPUTER" then just USE WHAT YOU KNOW HOW TO USE. Nobody is forcing you to use it. You get to justify the reasons all by yourself, and if you can't justify the learning curve to the benefits, then why do it?

Really, it doesn't matter. I'm not trying to get everyone to use Linux. I'm not telling my sister to install it. Neither is anyone else, really. You might hear from someone how great they think their Linux system is, and even say "you should give it a shot!" but it doesn't matter if you use it or not. Moving forward, when all the peices fall into place and your Linux distribution of choice is at the right level of comfort for you, we won't even have this discussion.

So relax; let the people developing this great system do their thing. When the state of the system is right for you, you'll know it. It'll happen, and until then do yourself a favor and don't worry about it.

Quote from you: " Not to mention that that this is the whole reason why linux will never be a mainstream desktop operating system..."

You really should add "today." at the end of that. Tomorrow, who knows?

Re:Several frustrating points

[Cap'n Steve]

"Would you like it if an artist made fun of your pens and call you and your friends BIC people?"

Spoken like a true Papermate dork.

Re:Several frustrating points

[forrestt]

I think part of the problem is WHERE you are looking for answers. I have been using Unix since the late 80's and I have been tinkering with Linux since the early 90's. I have been using nothing but Linux since about 98 (except for the occasional Solaris or Irix box I administer). I am a lead systems administrator at NASA, and have been working there since 1996. I am 34 years old and have spent most of my life (since I was 10) fiddle-farting with computers for fun and profit. Lets just say, I know and love what I'm doing. But I hardly ever use IRC because of the attitude that you describe. I would like to point out that it isn't Linux users who are elitist pricks. It is IRC users who are elitist pricks. They get on an IRC channel where everyone knows each other, and get off by bad mouthing everyone else. (If you need a question answered, a better place is linuxquestions.org.) I don't think the people on IRC get what it means to be a part of the "Linux Community".

I look at it like this. I have written very little of the code that I use on a daily basis. I have paid VERY little money for it (I have made financial contributions to some projects). The thing I can do to "pay" for the software I use is to help other people when they have a problem. However, whenever I have tried to go on IRC to help people, I am treated with the same attitude that you describe. "Nice" people don't hang out there because all they get is a bad attitude that they don't need or deserve. Therefore, you aren't likely to find "nice" people to help you on IRC.

It is a shame that these people tarnish the name of Linux for anyone, especially since most of them are of the oppinion that it is a superior OS.

Re:Several frustrating points

[AndyElf]

I dunno, maybe you're just trolling (and a number of replies that follow would qualify you as a good troll), but I'd say that installing FreeBSD is not any more difficult than, say, Slackware or Debian. It is more challenging than your Mandrake or RH install, I think (have not had a chance in the last 3-4 years to try either).

That said, with enough preparation and a chapter from the Handbook printed out and within a reach installing stock FreeBSD should not be a problem at all.

The question you should, however, ask yourself is Why do I want to try FreeBSD? If it is just because you've heard it's cool -- you may be much better off trying a http://www.freesbie.org/ instead. It's a live FreeBSD ssytem, sort of like Knoppix.

If you want to give FreeBSD a spin because you want to understand UNIX-land better or have needs for the stability of the platform, then rough starts should not be anything to discourage you.

In either case -- all the best and have fun!

Re:Several frustrating points

[mikael_j]

At least under windows there's a Program Files where things are installed. Ideally. Except for windows components. And only if it's on C:. And that's not counting in the registry. Sigh.

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

Re:Several frustrating points

[lahi]

Permissions are associated with directory entries, and NOT inodes. A specific inode may have as many directory entries (hard links) as you want, and each of these can have different permissions.

Wrong. Permissions and other file metadata relate to the inode not the directory entry.

I suppose the reason noone else has bothered to point this out already is that it is trivial. But perhaps it'd better be stated explicitly.

-Lasse

Re:Several frustrating points

[kbmccarty]

Without a package manager, it's practically impossible to remove a program; even with a package manager, you can't even determine how big a given package is! (if you know how to with Portage, I'd like to know).

If the program in question was originally installed with a package manager, why would you try to remove it without using the package manager? If you are installing from source, on the other hand, I think what you are looking for is GNU stow. With stow, you install a program (say it's called foo) like this:

• cd foo-0.0.1 && ./configure && make
• sudo make prefix=/usr/local/stow/foo-0.0.1 install
• cd /usr/local/stow && sudo stow foo-0.0.1

All that the "stow foo" step does is create symlinks from the normal dirs in /usr/local into the foo subdirectory, so you don't need to fuss with $PATH, $LD_LIBRARY_PATH, etc. to run the program. Upgrading or uninstalling foo later becomes trivial because all you have to do is run "stow -D" on the subdirectory (to remove the symlinks), recursively delete it, and (if desired) repeat the above set of commands to install the new version of foo. And to find the installed size: du -sk /usr/local/stow/foo-0.0.1

A better filesystem layout (perhaps the way MacOSX, GoboLinux or RoX does it) would make package managers obsolete.

Not true: in addition to file layout (which is arguably the easiest job for a package manager to handle), they deal with dependencies, post-installation setup scripts, config file handling, etc.

Re:Several frustrating points

[Martin Blank]

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.

Re:Several frustrating points

[leshert]

Actually, he's correct. The existence of early adopters doesn't mean that making changes to the system wouldn't help attract the laggards.

For a good introduction to this concept, see the book Crossing the Chasm.

Re:Several frustrating points

[ChaosDiscord]

The lack of ACLs is a major impediment to uptake of Linux in the business community.

"The business community" finds file systems confusing, so they stick everything into one giant directory with nearly worthless filenames. When they want to share a file with someone else they stumble around until they figure out how to turn on sharing and disable any sort of security.

ACLs are great, but most users, including most businesses, wouldn't know what to do with them. Clueful users are the exception, not the rule. Furthermore, anyone with enough of a clue to 1. seriously consider Linux and 2. understand and desire ACLs certainly has enough of a clue to discover that Linux has ACLs.

Screen is too black...

[raile]

I'm used to reading my system text as a white font on a blue background.

Re:Screen is too black...

[deathazre]

STOP ERROR 0x0000073A: SLASHDOT_MODS_DO_NOT_UNDERSTAND_SUBTLE_HUMOR //watch me get modded down for this...

OS X

[BWJones]

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.

Re:OS X

[ducomputergeek]

I generally have to agree. I had used solaris, Linux, FreeBSD, and OpenBSD systems before switching to OSX about 2.5 years ago. Granted I'm still running on my G3 iBook so the great power of the G5 chips are of little conquence, I've been developing for *iux web systems for 2 years now on Mac.

That coupled with the ablity to stay connected to the rest of the business world via MS Office for Mac and Adobe tools along with fine opensource apps such as Blender, and Apple only software like Final Cut Pro has been great.

What has happened to Unix is that Apple has developed the better *iux desktop system that coupled with the new G5's has been the final death nail into SGI coffin and put the hurt on SUN. Back in the days at McDonnell Douglas (now boeing), much of the engineering development was done on extremely expensive Sun workstations that could easily run $20k a peice. Today, a lot of development and code is being written on $3000 - $4000 PowerMac G5's.

While Apple remains expensive for many consumer users, in engineering and scientific fields, the PowerMacs with OSX are extremely inexpensive. Many of my friends in scientific fields have flocked to Macs with OS X in the past three years.

Re:OS X

[hey]

Lots of people agree that OS X is the best Unix going. So now us Linux fans has something to copy. Lets get started.

Re:OS X

[killjoe]

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.

Re:OS X

[BWJones]

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?

Re:OS X

[winkydink]

The numbers of Macs involved in secure and classified work in the Federal government have been exploding

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.

Re:OS X

[ThousandStars]

You'd be better off running *nix on a custom amd64 system, unless your filthy rich.

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.

Re:OS X

[Metzli]

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.

Re:OS X

[tbuskey]

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?

Re:OS X

[edesjard]

This is actually a really good point. My biggest complaint about Linux has always been that it constantly tries to copy WINDOWS which I have been totally disgusted by and why I love my Mac. I keep hearing that everyone wants OS X on x86 hardware. Why hasn't Linux, which appears to be floundering aimlessly, focused its efforts on being more like OS X than Windows? Isn't it what will REALLY motivate people to give Linux a try?

Re:OS X

[Lord Flipper]

hopefully not every update will require a reboot,... read the info on updates and patches, and reboot only the affected sub-systems. There are up-to-date Xserves out there that haven't rebooted in many a month.

Re:OS X

[herwighenseler]

/Developer/Tools/CpMac and /Developer/Tools/MvMac does the job you want.

Unintuitively, nonetheless.

needs some VMS stuff

[nocomment]

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

Re:needs some VMS stuff

[pclminion]

My point was, why protect against somebody "deleting" a file when they can just overwrite it with zeros? It's the same thing, right?

If you really want the kind of behavior you are talking about (although I can't imagine why), you can do it by making a hard link to the file in question into a directory which is "safe" from the user you are protecting against. They are still able to move the file around, modify it, etc. But if they delete it, the second hard link still remains, so the file is not actually deleted.

Re:needs some VMS stuff

[anum]

How about a versioning file system?

Re:needs some VMS stuff

[tntguy]

I can't count the number of times I've dragged a file to the "Overwrite With Nuls" icon on the desktop. This wouldn't help at all!

Re:needs some VMS stuff

[nocomment]

Well to work properly it would also need to have the versioned filesystem of VMS. So if someone were to say overwrite it with zero's then you just revert back to the previous version that wasn't zero's. You see? If the file is deleted the file is gone, but if someone changes the file to be useless, then I could jsut revert it. Make sense? There's no way anyone with only write permission could destroy any part of the system permanently. It's just a one command restore.

Re:needs some VMS stuff

[ComputerSlicer23]

Huh? Unless I'm misunderstanding my UNIX permission semantics (which is likely the case), if I can write to the file, I can destroy all of it's contents. However, the file still exists.

If I have write permission to the directory, then I can actually call "unlink" (UNIX system call which will delete a file).

Lacking write permission to the directory, I can't delete a file (or create a file). If I have permission to write to the file, I can destroy it's contents, but I can't stop the file from existing.

However, I believe in most modern UNIX filesystems you can set the "APPEND ONLY" attribute, which is handy for some things (log files), I want you to be able to write a the end of the file, but the prior contents must always exist.

Kirby

Re:needs some VMS stuff

[nocomment]

no, not journaled, versioned. Very very different. Journaled keeps a log of what the disk was doing so that that particular state can be restored in the event of a crash. That's how the a system running ext3 (or any of the others) don't have to fsck if you hit the power button. Versioned creates seperate version of individual files. So no, those options are NOT guaranteed by sane options, because those options don't exist in most filesystems.

Re:needs some VMS stuff

[lophophore]

Hmmm. I'll vite for that.

How about some ACL-based protection mechanisms!

And VMS-style "logical names" that allow a virtual "file system" location to point at multiple real file system locations...

And while we are at it, let's add real clustering, and DCL for good measure.

(Did anybody else use Posix services on VMS? That was some cool stuff. Unix interfaces on a modern OS...)

Re:needs some VMS stuff

[spitzak]

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.

Program Installation Locations

[ShortSpecialBus]

The first thing to change should be how programs get installed.

EVERYTHING right now goes in /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.

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, /usr/lib, /usr/bin, /usr/share, et al.) and there's no good way to do it.

Find a way (maybe symlinks /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.

Re:Program Installation Locations

[Anonymous Coward]

Speak for yourself - for years, I've installed packages in "/usr/local/packages".
Package "foo", version "N" goes in "/usr/local/packages/foo-N".
The current version of "foo" has a symlink to it from "/usr/local/packages/foo".
"/usr/local/bin" contains symlinks to the appropriate files in "/usr/local/packages/*/bin"
Upgrades (and downgrades) are trivial.

Re:Program Installation Locations

[Phleg]

Somebody find this man a package manager.

Re:Program Installation Locations

[grumbel]

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.

Re:Program Installation Locations

[plover]

Are you suggesting that an installation process more like Windows Installers would leave easier-to-clean-up-code? Because if so, I've got this real nice bridge to sell you.

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

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

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

Re:Program Installation Locations

[umrk]

./configure --prefix=/usr/local/stow/foo-1.2
make
sudo make install
sudo stow /usr/local/stow/foo-1.2

Done.

Re:Program Installation Locations

[Krunch]

You might be interested in Stow. The idea is to install each program in its own directory then create symlinks in /usr/(local/)?(bin|lib|share|whatever)/. When you want to remove a package, just remove its directory then remove broken symlinks.

Re:Program Installation Locations

[mandos]

This is basically what Gobo Linux is trying to accomplish. From their FAQ:

• 
  GoboLinux is a Linux distribution that breaks with the historical Unix directory hierarchy. Basically, this means that there are no directories such as /usr and /etc. The main idea of the alternative hierarchy is to store all files belonging to an application in its own separate subtree; therefore we have directories such as /Programs/GCC/2.95.3/lib.
  
  To allow the system to find these files, they are logically grouped in directories such as /System/Links/Executables, which, you guessed it, contains symbolic links to all executable files inside the Programs hierarchy.
  
  To maintain backwards compatibility with traditional Unix/Linux apps, there are symbolic links that mimic the Unix tree, such as "/usr/bin -> /System/Links/Executables", and "/sbin -> /System/Links/Executables" (this example shows that arbitrary differentiations between files of the same category were also removed).
  
  www.gobolinux.org
  

Re:Program Installation Locations

[killjoe]

In windows files may go to program files, common files, system, windows directories. Plus the really important stuff goes to the registry.

Deleting the install directory doesn't do jack.

That's why windows has uninstallers.

How long did you say you used windows? Seems like you ought to know this by now.

Re:Program Installation Locations

[Epistax]

Right, because everything's available in a single repo.

or...

On my Fedora box I have rpms made for Red Hat, rpms made not for Red Hat (go figure), source installs with configuration scripts, source installs with instructions, source installs with nothing whatsoever, programs with install scripts that install to the directory tree how they see fit, programs with install scripts that install nowhere (./), and python sources that just sit there coming straight out of a tar. Meanwhile I have nethack sitting around in /usr/game/nethack and has "libraries" in /usr/games/lib (note that nethack is the only game to use these folders). I guess I'm just lucky I haven't had to figure out how to use a Debian (.deb) install file yet.

Re:Program Installation Locations

[batkiwi]

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.

Re:Program Installation Locations

[mepperpint]

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.

Re:Program Installation Locations

[Tet]

Look at windows: you clearly specify the installatino directory, and then *all* the files go there.

I can't work out if you're trolling or just genuinely ignorant. Under Windows, everything goes in your selected installation directory... except for the bits that don't. Some have to go in the system directories and there are usually registry entries made. In contrast, if you tell a Unix application to install in a given directory, it generally does, and doesn't pollute the file heirarchy outside of your chosen location. If you're installing it from an RPM or dpkg, then it usually does the same, but it's effectively using a shared install directory between multiple apps. But why do you care where it puts the files? Use the package manager to tell you which files came with which package, and to remove the package if you're done with it.

Re:Program Installation Locations

[angedinoir]

If I'm having problems, I open a single folder and 99% of the time I can handle the issue from that folder (or at CLI, from a single directory).

This is, of course, is false. When you install a program, shared system libraries go into the \windows or \winnt directory. Program related files and executables go into \Program Files. Settings specific to a particular user go into \Documents and Settings\<user>\Application Data.

Not to mention the registry, but not going there today.

I totally agree, it would be nice to have everything located in a simple manner, shared libraries go into a shared directory, everything else goes into /usr/bin/<program name>/ A link is created in wherever, and that's it.

Re:Program Installation Locations

[acd294]

"/usr/bin -> /System/Links/Executables", and "/sbin -> /System/Links/Executables" (this example shows that arbitrary differentiations between files of the same category were also removed).

Actually, there is a difference between /bin (or /usr/bin) and /sbin. /sbin stands for stand alone binaries. (As opposed to /bin, which is just binaries) In sbin, you will find statically linked executables that you just may want to use if your system is hosed (ie the slice with the dynamic libraries goes down and you want to fsck it). They dont absolutely need to be in separate directories, but there is definitely a difference.

Re:Program Installation Locations

[Slack3r78]

It doesn't even have to be an installer. Ever used OS X? To install software on X, you simply drag a .APP container file into your Applications directory. To uninstall, you drag it to the trash.

How is this not better than the current Unix way of doing things?

Re:Program Installation Locations

[Tyler Eaves]

The best approach I've seen to this is Mac OS X's "App bundles". Basically these are directories with a name that ends in .app, with a certain internal layout. To the user in the file manager, it looks and acts like a file. If you click on it it launches the app. Easy drag-and-drop installation/removal, and the program can include as many support files as it needs, without even NEEDING an installer.

Re:Program Installation Locations

[diegocgteleline.es]

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

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

Re:Program Installation Locations

[forkazoo]

OS X also has a package manager, which IMHO, is much more trustworthy than an executable installer. My only real complaint is that so many MAc OS X packages insist on being installed on the main drive. That makes me sad.

Re:Program Installation Locations

[mce]

Before you make statements about how things are installed on UNIX, you should understand that what you seem to know is a personal Linux box on which you can do everything you please and of which you don't understand the package management. It is not the UNIX way.

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

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

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

Re:Program Installation Locations

[i am fishhead]

Well, it depends on what you want to do. Until I started to admin a linux cluster, I didn't really understand why this was done either.

1) Most of the folders have a PURPOSE. /bin has vital system binaries (sh, login, and so on), /sbin has binaries and daemons vital to starting up the system, /etc has files containing startup and default settings, /var has variable information (like logs), /tmp is for temporary files, and so on.

Why is this powerful? Well ...

- Want your machines to behave similarly on startup? Replicate /etc on these machines or have them mount a shared /etc on top of the original early in the boot process.
- Want to have faster access to temporary files? Make /tmp be on a ramdisk.
- Want to limit log sizes so they don't fill up the disk? Make a seperate partition for /var
- Want to shared data across a bunch of *nix boxen? Make /usr/share and friends NFS shares.
In general, You can do interesting things by combining the fact that directories are usually per-purpose rathar than per-program. Granted, in the desktop world, this isn't so much useful, but it makes cluster management and system maintainence SO much easier.

2) The issue you complain about can be taken care of by a package management system or some arangement of symlinks.

Re:Program Installation Locations

[Herr_Nightingale]

For the last 5 years Windows 2000 has had WFP to protect against core files being overwritten. I've not had a single "DLL hell" experience yet in ~15 years of using Windows.
However I've installed Firefox on ten different distros (probably more now) and never once seen an icon for it appear automatically in my GNOME menu. Why is this so broken? APT, Synaptic, RPM, yum, etc. are all basically broken from my point of view, but we put up with them because it's worth the fuss. Millions of computer users can't even find a new icon on the DESKTOP, much less dink around with non-standard filesystem heirarchies (which distro do you use?) and symlinks.
Pet peeve of the day (which happens to be relevant to this thread) : Windows downloads are only a fraction the size of equivalent Linux apps. Try OO.o, Firefox, etc. My Xandros 3 install had to download 40MB (using the lovely APT) which doesn't compare well to a 4MB download for Windows.
Seriously, you should look into using something more current than Windows 3.11.

To compare apples to apples:
OO.o:
Windows - 45MB
Linux - 77MB

Firefox (with installer):
Windows - 4803KB
Linux - 8422 KB

Thunderbird:
Windows - 5877 KB
Linux - 10113 KB

I've heard enough about bloody shared libraries that evidently NEVER get shared, and instead I end up with five different incompatible versions of glibc/GTK/whatever and it's also annoying to wait while APT downloads an EXTRA 300% of the listed download size. If making *NIX installers like Windows means that I'll have all the advantages, and all of the downfalls, then I'll take it thank you very much. It's a great deal better than what we've got now.

Re:Program Installation Locations

[cosmol]

How is this not better than the current Unix way of doing things?
umm, you have to use a mouse?

Re:Program Installation Locations

[SewersOfRivendell]

OS X also has a package manager

No, it doesn't. The installer framework does record the installed files in package 'receipt' files, but there's no standard way to uninstall a package.

Re:Program Installation Locations

[prockcore]

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.

configuration

[meshko]

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.

Re:configuration

[Mr.Ned]

"Even simple programs that require very simple configuraiton store it in random places and formats."

I disagree. Most programs I encounter have systemwide configuration files and per-user configuration files. The systemwide ones live in /etc, and the per-user ones live as dotfiles (or dotdirectories) in the user's home directory. There's nothing random about that.

"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 don't think it would help. Choosing a standard syntax doesn't help writing modelines or virtual hosts. Well-commented example configurations do - apache and sendmail both come with them. Better yet is the autoconfiguration of X - seriously, when's the last time you had to manually write out an XF86Config or xorg.conf?

Re:configuration

[killjoe]

Ideally all confi files would follow the same format and syntax (god no please don't say XML).

Ideally there would be a uniform way for programs to retrieve configuration information from a centrallized location.

Ideally local users and machines would be able to merge their prefs and config with the master to override certain prefs.

Ideally the hierarcy of administrators would be able to prevent entitities under them from overriding certain configuration options.

Ideally all of that could be done with plain text files which are automatically checked into a version control repository so you can roll back any change in a jiffy.

Re:configuration

[mrroach]

You have just (mostly) described gconf. While the current backend does use XML, there's no reason why it couldn't use some other setup (ldap support has been partially implemented). The problem is that people have inacurately painted it as a windows registry clone or fail to see that a billion little configuration languages and parsers for every application is less than ideal :-/

-Mark

my answer

[ubiquitin]

Q. What's wrong with Unix?
A. All those slashes and dots.

Q. How you would fix it?
A. um, slashdot

Of course!

Re:you mean those guys that had their things cut o

[Devil's BSD]

no, those are eunuchs

The MathWorld Answers

[Ed Pegg]

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.

In a word...

[rongage]

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.

Re:In a word...

[Anonymous Coward]

Every modern systems has a native printing language, and each uses the native language to abstract multiple end-languages.

Postscript is an intelligent way to abstract non-Postscript printing. Postscript is well documented, and is in itself a useful print language.

Otherwise we'd be back in MS-DOS. Do you remember when each application had its own audio, video, and print drivers?

ahz

Re:In a word...

[Libor Vanek]

No PCL!!!! Reasons:

- PS you can very easily convert to PDF - none for PCL!
- there tons of tools which enables you "4 pages in 1", accounting quotas etc. etc. - none for PCL!
- try to display PCL file
- WHICH PCL? PCL5? PCL3?...

There is simply NO reason to give up - tell me one single argument (except VERY slight speed-up) which will balance the loosen flexibility and necessary to rewrite all existing tools (CUPS, print drivers etc.)

Re:In a word...

[Tackhead]

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

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.

Re:In a word...

[imsabbel]

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.

Re:In a word...

[Geoffreyerffoeg]

Whatever the case may be with prices and design and requirements, the simple fact is that most consumer printers are PCL, and very few are PostScript. Therefore applications should support PCL as the de-facto standard, and allow for a convertor from PCL to PostScript (or a separate renderer) for the few cases that require this.

You are Linux. You are a small, free OS that has only a few percent of the market. You don't control how the printing industry designs their products; you obey their decisions.

Does it reliably enable true modern computing?

[Ars-Fartsica]

Does unix enable people to build clusters, serve multimedia content, create sustainable high-throughput networks etc etc? Yes. Most implementations also provide for these true modern computing environments reliably and cheaply. What else do you want an OS to do? If an OS can reliably enable the modern application layer, to me it has satisfied the criteria of an OS.

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.

Plan9 is what's right with UNIX

[andrewzx1]

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

cynical view

[Keitopsis]

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

Re:cynical view

[pclminion]

If someone is only looking for a single application, it is hard to shove such a versitile system down their throat.

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.

Re:cynical view

[OrangeTide]

Who just wants a word processor? Those word processors "appliances" were never very popular. I don't think anyone even makes them anymore.

I've never met a computer that was really "plug and play". They always seem to have issues, at least for me. About the only thing that worked right away was my microwave. Even new cars don't seem to work perfectly from the start. We all might want something that you plug it in and it works, but the popularity of cheap digital cameras that are notoriously unreliable seems to prove that ease of use and reliability is not a consumer's primary criteria for a purchase.

Has to be said

[aendeuryu]

One big thing that's wrong with Unix is SCO.

GNU Stow

[Anonymous Coward]

That is why distributions have package management systems for GNU/Linux. A single command is sufficient to install/remove a package.

However, I understand your problem, when it comes to manual installation. There is a project GNU Stow to handle what you are talking about.

KSpaceDuel

[jkauzlar]

Certainly this component of Linux needs rewritten. Firstly, it is far too difficult to maneuver your ship with the gravity the way it is, and secondly, the bullets go too slowly. Thirdly, it isn't intuitive what the different colored blobs are; its easy to forget what is energy and what is a mine, or something like that.

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

Re:KSpaceDuel

[LiquidCoooled]

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.

Easy!

[Telastyn]

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.

Unix is too powerful

[Anonymous Coward]

I know it sounds silly, but it's like asking a consumer to operate a bradley armoured figting vehicle, it wasn't built for consumer use, its got hundreds of knobs and options and configurations, and if you don't get it set up right the first time it is a tremendous headache to fix it. Consumers want a gas pedal and a brake, windshield wipers are fine, but when you put on a .50cal machine gun mount, even if its "turned off", it scares people away.

It's a canonical example of something that tries to be everything to everybody, but ends up being too hard for anyone to use.

There's only one thing wrong with UNIX:

[gellenburg]

Not everyone's running it.

Laugh.

It's a joke.

The C language

[lazy_arabica]

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.

Re:The C language

[Tom]

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.

Whats broken with unix?

[mgv]

Its hard to pinpoint anything specific that is broken with unix as a whole.

But there are lots of subsystems that aren't exactly perfect.

Examples that come to mind:
*File permissions only go to user/group/others rather than individuals, and poor record locking on network shares. Lack of automounting as an intrinsic feature of the operating system.

*Windowing subsystems that network, but cant handle 3d networked graphics effectively, or support the more advanced hardware features of graphics chips locally particulaly well.

*Software packaging systems that develop conflicts. (Probably more of a linux problem, actually)

- I am aware that all of these have workarounds or are being worked on -

The kernel of most unix's (and, for that matter linux) are fairly well tuned to a variety of things, although they are subject to a number of internal revisions to try and do better multi tasking & multiple processor scaling, for example.

Where these systems will probably fail the most is when the underlying hardware changes alot - for example handling larger memory spaces and file systems, or perhaps even moving to whole new processes (eg., code morphing cpu's such as transmeta's, asynchronous cpu's). These designs are quite radically different and we have developed down a specific cpu/memory/harddrive model so far that its quite difficult to look at major changes, as they aren't as easily supported by the operating systems.

Just my 2c, and from a fairly casual observer status - it would be interesting to hear what the main developers think on all of this.

Michael

mmap

[blaster]

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.

Re:mmap

[pclminion]

Why can't you gracefully recover from a lost mmap? Set a handler for SIGSEGV. If you get a fault, check the faulting address. If the address is within an mmap'd region, longjmp() to a recovery point. This can be made quite clean.

I don't think the solution is to start removing functionality. The solution is to use that functionality in the correct way. A program can receive a signal at any time. This is a cold, hard fact. If your program uses operating system features that could lead to exception conditions and signals, you should handle those signals appropriately.

User Friendly

[DaFallus]

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

Re:User Friendly

[millahtime]

It already exists and is called OS X

Simple...

[andreMA]

PROBLEM: SCO exists
SOLUTION: 2 MT airburst over Lindon, UT

Oh, with UNIX, not for UNIX. Never mind.

As you were.

Here's a start:

[Slack3r78]

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.

Re:Here's a start:

[Zeinfeld]

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.

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.

Re:Here's a start:

[Taladar]

Documentation is a complete joke.

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?

Re:Here's a start:

[FuzzyBad-Mofo]

That reminds me of my favorite Windows error message:
Windows - Application Error
The instruction at "0x00403759" referenced memory at "0x202c7971". The memory could not be "read".
Click OK to terminate the program.

The quotes around "read" are what really cracks me up. What can I say, I'm easily amused. Bring on the guru meditation, baby! ;)

Re:Here's a start:

[spectecjr]

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.

Re:Here's a start:

[Yosho]

Out of curiosity, what UNIX man page would I go to to learn how to write a GUI "hello world" program in that environment?

Re:Here's a start:

[spectecjr]

Call *me* when MSDN can put up some simple information on how to do a "hello world" program in Windows. God forbid you want to use multiple windows which are tabbed or something.

Sure. In fact here's two.

Generic Windows Hello World program (in C)

Alternatively, how about this one... Hello World for Win32

There you go.

Please take this person's notion that MSDN is world's above what Linux or some other UNIX has with a grain of salt. Also, docs.sun.com and sunsolve.sun.com have always worked adequately for me.

While you're at it, you might also want to question the person I'm responding to, who apparently can't search their way out of a paper bag.

8-bit UI unusable in a 32-bit world

[RomSteady]

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.

In no specific order:

[Qbertino]

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

Re:In no specific order:

[ThousandStars]

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.

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.

Re:In no specific order:

[suwain_2]

the allmighty root (single largest security risk)

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] :wq to write and quit in vi) once you learn it. I'm not sure what you mean by "incosequent".

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.

Re:In no specific order:

[bnenning]

I think it's important that there be a user with the ability to do anything.

Agreed, but there's no reason I should have to become that user if all I want to do is listen on port 80.

Re:In no specific order:

[macwhiz]

- unix printing still sucks big time (see 'vendor support')

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.

Non Free.

[twitter]

The most broken part of "Unix" is that it's non free. Everyone has their own way of fixing things and does not share any of it, so we have the current fragmented landscape of Sun, HP, AIX, OSX, etc. The obvious solution is to use free software which ports the best features of each and costs nothing but time and thought to implement. What could be easier than that? The details are not as important as the root cause and the solution.

It will not run well on my first* computer.

[agent]

It will not run well on the first computer I slaved away for. DELL Service Code: 696ML

GNU all the way baby.

Revenge
http://www.legaltorrents.com/index.php? fuse=71

Fix it from the bottom up

[elronxenu]

To fix unix, it is important to start from the bottom up. Ignoring kernel internals, which are the choice of the kernel developer, the layer we need to fix first is the system call interface.

For example:

• Rename creat to create, as it should always have been
• 64-bit time_t
• localtime to return the year number, not year-1900
• Decide whether we like curses or termcap, and get rid of the other one
• Add inode-level operations, i.e. open an inode, rather than a path. Add atomic filesystem operations. Rename an inode. Delete an inode. Path-level operations permit race conditions whereby an attacker switches the filesystem around in between a privileged process examining the filesystem and making a change to the filesystem.
• And many others ...

Two things:

[Saint Aardvark]

Coarse permissions for files, and extremely coarse permissions for ports.

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.

Re:Two things:

[cortana]

There's actually a patch floating around that allows you to do exactly that with /proc/net/$proto/ports/$port or some such. Can't remember the name unfortunatly.

Re:link and file managment

[JustinXB]

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.

No!

[Inoshiro]

I do believe there are a few problems with you assertions:

"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 /proc/sys/fs/binfmt_misc/register ]; then /sbin/modprobe binfmt_misc
mount -t binfmt_misc none /proc/sys/fs/binfmt_misc
fi

if [ -e /proc/sys/fs/binfmt_misc/register ]; then
echo ':CLR:M::MZ::/usr/local/bin/mono:' > /proc/sys/fs/binfmt_misc/register
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. :)

Whats wrong with Unix?

[northcat]

Nothing.

What's Wrong with Unix

[realdpk]

Personally, I don't think there's really anything "wrong" with unix.

Now, if you asked me "What is wrong with Linux?" I would have several answers. Same with "What is wrong with FreeBSD?" so you don't think I'm just a BSD bigot. But "unix"? It's hard to pin anything on the generic term "unix".

Microsoft Aptitude Test (MSAP)

[reflx]

I applied to work at Microsoft. The interviewer asked me: "What's not broken with Windows?" "How would you break it?"

Re:Microsoft Aptitude Test (MSAP)

[utlemming]

Answer: Turn the computer on.

Lots :-)

[Erik Hensema]

In random order:

• The filesystem layout. It works, but it ain't pretty. I highly doubt we would end up with things like /usr and /etc when we redesigned the layout from scratch.
• In fact I'd rather entirely drop the fileystem in the classic sense and replace it with an object-relational database.
• X11. Though X.org is working on it.
• Lack of configuration standards. Text files with a million different formats are not elegant. We need something with a uniform interface, both to the user and to applications. Elektra Project (formerly know as the Linux Registry Project but that name is Wrong) working on it.
• No universal way to inform the user of important events in the system. Kernel events layer and dbus are going to solve this.
• /etc/passwd and friends need to go out. ldap all the way. We also need user/admin friendly ldap tools (in fact I have run my desktop system without /etc/passwd for several months, it's not that hard).

Re:Mac OS X...

[ip_fired]

Every application comes in a bundle. For example, lets say you create an app that is called foo.

You would create the following directory structure:
foo.app
--Contents
----MacOs
------ foo (the actual executable)

Inside the foo.app folder, you can put all of the libraries, data files, help system, etc that your program needs.

When you are browsing through in the Finder, the .app directory isn't treated as a directory, but rather the application itself. When you double click on it (or use the open command in the shell) it will start the application.

One of the neatest things is that you can do this with a Java program, and the OS will launch it properly. I wish it were easier to launch jars in Windows like this.

Like elektra?

[haeger]

Ideally all confi files would follow the same format and syntax (god no please don't say XML).
Ideally there would be a uniform way for programs to retrieve configuration information from a centrallized location.
Ideally local users and machines would be able to merge their prefs and config with the master to override certain prefs.
Ideally the hierarcy of administrators would be able to prevent entitities under them from overriding certain configuration options.
Ideally all of that could be done with plain text files which are automatically checked into a version control repository so you can roll back any change in a jiffy.


There was a project on sourceforge that adresses some of the points you raise. Originally it was called "Linux-registry" I believe, now it's called Elektra.
I don't know how far they've come or anything about the project, but it looks like something that You'd want to have a look at.

.haeger

Re:Like elektra?

[Technonotice_Dom]

Yep, there was a mention on LWN.net recently when they "Elektrafied" X.org. It uses the filesystem for config storage, has only a couple of libraries that it depended on (i.e. not a whole load of XML stuff) and was in essence, very simple. With revision control systems, you could roll back changes easily. From memory, it created a file for each setting, and stored the value for the setting inside it, using directories for the config layout.

COM and the Shell

[shird]

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.

setuid stuff is confusing + M$ like system restore

[thehackerfromthesout]

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

Unix Haters Handbook

[Lirvon]

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.

Re:Better Compiler

[i am fishhead]

AFAIK, gcc 4.0 will include support for this. See the -fmudflap option in the gcc manual.

Re:libs

[gibson_81]

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

The exact location doesn't matter to me.

[WebCowboy]

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

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

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

A good set of standards.

[Spy der Mann]

I'm not speaking of unix specifically, but of Linux. But I hope this enlightens anyone.

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 ./configure-make-make install and recompilation pain, etc etc etc.

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

Re:A good set of standards.

[RealAlaskan]

Linux isn't friendly for:
* Installing apps

Apt-get or urpmi or yum. Your distribution will use one of those, and you will have no problems. It's far easier than windows.

* Guiding the Joe user to a friendly painless installation of the OS itself

Windows installation is more painful than Debian, but that's immaterial: Joe User should never be installing an OS. Knoppix makes for a ``friendly painless installation of the OS'', but I still say that Joe User probably shouldn't be doing that.

* customizing
* configuring

If you want simple, you can't have those two. If you want to customize and configure, you have to accept some complexity. You have to be willing to make choices. One area where Linux could still improve is in having sensible defaults, so that you don't have to make those choices right at the start. Linux is much better on this than it was when I started using it, with Redhat 6.0. Again, Debian really shines here: I haven't had to do much customizing or configuring with Woody or Sarge. I suspect that the latest Redhat, et cetera, is similarly improved.

And don't come tell me it's much better than windows. I ALREADY know that.

Yes, there's always going to be room for improvement.

Re:A good set of standards.

[theantix]

(1) Linux is not user friendly.

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

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.

And Apple is Open, what's the problem.

[MarcQuadra]

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.

Re:And Apple is Open, what's the problem.

[MarcQuadra]

Would it really be suicide for Apple to release for free all of the source code for the OS?

Yes, Apple lost a huge portion of the home user and educational market, they're aiming to get a foothold in the data-processing sector, where *NIX is already in use. Releasing ALL the source except the consumer-friendly bits would obliterate their chance with shops like the government and large data-oriented customers. Why buy milk from Apple when you can roll-your-own Apple cow?

Also, there's a LOT in the OS that Apple probably CAN'T release, it's licensed from other folks, or it was written under different rules.

Apple does a lot of work for the OSS community, they give back more than most companies do, and they should be praised for it, just like IBM (they do a TON of stuff for the OSS community).

I thought the Linux/OSS users were going to get behind vendors that supported us and buy their products, that's what we said back in the '90s when hardware support was VERY hard to come by. The time has come, and if it's not all you thought it would be, think about all the Linux companies that went belly-up and why. There's a happy middle-ground between going totally nuts with the code-sharing and giving back while keeping a marketable product to yourself, Apple and IBM have found it.

Now think about this:

Apple gave us a BSD OS, tuned for multimedia and desktop use, something we've been working on for a while now. They'll give us Darwin, and sell us OS X. But you can take Darwin, install a ports system of your choice on it (gentoo, darwinports, apt-get, etc.) and use it just like any other system. You get OpenDirectory, which is quite possibly the best thing to happen to computers since ethernet (really, read about it!), you get xorg, and you get drivers that provide 100% functionality with Apple-branded hardware.

Re:And Apple is Open, what's the problem.

[johnnyb]

"The fundamental question is do people generally buy an Apple for the OS?"

I haven't bought one, but it sure is the reason I recommend it to others (if by OS you include applications like the Finder, but not iLife etc.).

The expose' feature is wonderful.

The heavy drag-n-drop integration is beyond anything I'd ever even thought of, and makes it a complete joy to use.

The dock is really cool. I like that it magnifies as you go over the icons, that it points to which applications are open, and that it keeps a thumbnail of minimized windows.

The ability to install an application just by moving a single file into the "Applications" directory is phenomenal.

The single-menu-bar is a fantastic idea.

The system preferences are easy to set and use. Setting up mobile networking was a snap.

And I'm sure I've only scratched the surface.

My wish list

[miu]

• A standard and efficient set of IPC mechanisms.
• Shared memory servers with defined behavior and controls for multiple readers/writer processes and threads.
• Standard debugging and trace versions of system libraries.
• Standardized time types for all commonly used timer tasks
• Clean system header files and hierarchies that don't require every compiler vendor to do stupid and confusing things to meet various published standards.
• Standarized interfaces for process read/write and trace
• A very clear distinction between userland and kernel threads in standard system libraries

Tons more, mostly it is just a problem of cruft and people trying to deal with every standard org that ever decided to publish the One True Unix standard making their standard just different enough to be a PITA.

Exploitable race condition is endemic

[Bloater]

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.

That's not just unix. :P

[solios]

It's actually WORSE in the linux community than it is in, say, the IRIX, Solaris or HP/UX camps. Then there's the OS X and Classic MacOS camps, which take the "being an elitist prick" mentality to a whole new level.

Oh, and there's LISP users and HURD developers. Dear fucking gods, they set the standard.

Re:That's not just unix. :P

[WgT2]

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.

Re:That's not just unix. :P

[tulare]

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!

Re:That's not just unix. :P

[resiak]

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 ;-)

Re:That's not just unix. :P

[pcmanjon]

" 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!"

No shit! I hate them mother fuckers. Maybe I would RTFM if the programs I need help with HAD A FUCKING MAN PAGE! Idiots...

Try out channel #mepis for MEPIS Linux; I hang out in there and they are very nice, and even help out for other distros.

Re:That's not just unix. :P

[Greg W.]

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

Well, maybe that's because you:

• Did not read the channel topic.
• Did not read the channel FAQ whose URL is the very first thing in the channel topic.
• Did not read the channel guidelines that the bots sent you in private /msg when you joined the channel.
• Did not ask the channel bots any obvious questions.
• Did not read the man page for whatever command you were using.
• Did not search Google for the error message you received.
• Did not tell the channel what command you were using.
• Did not tell the channel what error message you received.
• Did not tell the channel what you are trying to accomplish.
• Are running Knoppix, MEPIS, Ubuntu, Gentoo or Fedora instead of Debian.

Or, the greatest mortal sin of all time:

• Came into #debian with the intent of telling us how elitist we are and attempting to change us.

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.

Re:That's not just unix. :P

[falkryn]

Funny you mention that, I remember one time being in the datacenter of the college I was attending. Most of it was still running NT4. They mentioned how cost-prohibitive upgrading to 2k would be for them. So I mentioned, how about Linux? The head admin and his henchman laughed, and replied "Linux? Heh, we want a REAL operating system."

And yes, this guy makes a ton of money... There the same people whose network was so malconfigured that doing a ghosting operation in a supposedly private subnet, I managed to take down the ENTIRE network. I mean everything, even the remote campuses!

They then told the president of the college that it had been a hacker attacking the system. :-)

My list.

[Yaztromo]

Here are the general problems I have with Unix and Unix-like operating systems:

• Threading models and scheduling. A few Unicies have decent thread models, but others have abysmal thread models and scheduling. Because of this, far too many Unix applications wind up eschewing threads for simply running multiple processes, which isn't the same thing. Thread priority needs to be global, and the thread should be the most primitive execution unitt upon which all other execution units are built. No more "my thread priority is set to the max, but I get very few slices because my process priority is set low". My OS/2 machine running on a P3-450 can still out-thread many multi-gigahertz Unix systems, and that's just sad. Too many Unix kernels have had threads bolted on as an after-thought, and it shows.

  (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).

• Clipboard support in GUI subsystems. Come on, it's 2004 already. Unified clipboards have been around for more than 20 years now, and yet many Unicies still can't get this right. Cutting and pasting between applications shouldn't be a major PITA. Users shouldn't have to worry about which widget library an application was compiled against to figure out if they'll be able to paste to that application from another. Things are getting better, but really, this should have been fixed years ago, and shouldn't be taking so long.
• GUI application font support. Again, a rare few get this right, but most of them have this big conglomeration of font types, and no unified font access system. Windows 3.0 had a beter font subsystem than what some Unicies have.
• Printing. Again, some Unicies have done a good job, but far too many still don't have a good unified printing subsystem. Others here have done a great job of pointing out the problems with Unix printing in general, so I won't rehash them all here.
• Desktop access APIs. Even with KDE and Gnome, there still isn't an API to call to do something as simple as create an application icon on the desktop or in the application menus which can be used to launch an application. Everyone winds up having to roll-their-own, if they bother to do so at all. Again, not all Unix GUI environments suffer from this, but the majority do. As I developer, I shouldn't have to care what environment a user is running if I want to do something like put an icon on their desktop as a part of an installation/configuration routine -- there should be an API I can call that says "create an icon with the following properties", and have it worry about WM/environment specifics.
• USB driver development and device access. Again, in many Unicies this is fundementally flawed and can be very difficult for users to set-up and configure. And it differs drastically from Unix to Unix. Where we have pretty standard systems for accessing RS-232 serial ports, and parallel ports, USB access is completely non-standardized across Unicies. Just witness the PITA it is to set-up the newly standardized javax.usp API on Linux, and the kernel work-arounds that had to be implemented to allow APIs like this to unload aggressive modules that grab interface focus immediately just because they were included with the distro. There isn't much excuse for this IMO.
• Unicode support. Again, hit or miss.

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.

Re:My list.

[justins]

running on a P3-450 can still out-thread many multi-gigahertz Unix systems

WTH does that even mean?

Easy Two Words

[rikkards]

No Balls

Thank you! I'm here all week! Try the Chicken Kiev!

Problem already fixed, for a while now

[daveschroeder]

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

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

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

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

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

One reason ACLs are superior

[Earlybird]

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.

You need to split the functions finer, too.

[Ungrounded Lightning]

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.

Amen!

[pVoid]

The File System. Sure It Corrupts Your Files, But Look How Fast It Is!

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

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

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

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

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

You're thinking too small here

[crmartin]

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.

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 /etc/passwd to a gdb database indexed on username might be something like
cat /etc/passwd |(gdb) application.

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

Smart people find easy ways to do things,

[KalvinB]

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.

Re:IMHO, none of that matters to the typical end u

[sloanster]

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.

Something like that...

[solios]

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

Re: Firefox plug-in woes

[Anonymous Coward]

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.

OSX is not the end all solution

[iwsmith]

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.

UNIX new year's resolutions

[poopie]

- 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)

- 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 /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?

- 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 /sbin and /usr/sbin? - Give me *one* - how about only /usr/sbin so we can keep / with fewer entries?

- Do we really need /bin and /usr/bin? How about only /usr/bin.

- for application foo, what should go in /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!

- 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 /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

- 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)

Re:UNIX new year's resolutions

[Junta]

True serial console, already there for a lot of x86 servers, and besides, that wouldn't even be a Unix issue, it is a platform issue. IPMI 2.0 will allow a standard way to remotely access that serial console via network, but 20 years ago the machines didn't have that capability, and it has always been the case that Cyclades, MRV, Equinox, and the like make money off of equipment to make serial consoles net accessible. Besides, the non-x86 systems still today most all have the same serial console support of 20 years ago.

Privileged port is pretty much as you say, a joke. I am particularly amused by IRC servers dependence on ident responses as a way to validate a user connecting

The info format was meant to supercede man pages. There is a lot more flexibility, but I am torn. In day to day use I find a preference for man pages, simple, easy to search. However, man pages don't scale that well (man bash for example), and sometimes the typical string search for what you want will take forever to iterate through. Arguably more widespread html documentation coupled with text web browsers like links would give more flexible options in a more comfortable way.

What exactly is your complaint about /usr/local? Anyway, it wasn't really intended to distinguish GNU from non-GNU, it was largely meant as a site/workgroup wide repository for shared binaries/applications. My complaint about it used in this fashion is that it wasn't engineered well for multiple platforms (i.e. standard requiring arch/platform named directories to hold executables/libraries) /bin and /sbin are not boring/redundant with /usr/bin, and /usr/sbin. While many many systems nowadays use one filesystem to contain more, some systems still have /usr as a separate partition, and / containing things useful to get system to boot/mount and do recovery tasks is good for those environments.

As far as all the directories and where things go, there are pretty established standards, the problem being, of course, that not all groups know them well or bother to follow them, so they kind of get trashed. I personally think mostly self contained application/library suite directories are nice (ROX file manager supports it). I.e. the entirety of GTK would be /usr/lib/GTK/, including documentation, default configs, libraries, executables) Of course, PATH variable would get badly mangled, or else you have ludicrous fs structure (very simple apps needing directory entries, ls, rm, etc if strict, when they share a lot of documentation). It really is a hard thing to address.

Most everything else I can't disagree with. Particularly the notion of detachable X11 sessions ala screen for terminals.

Re:You guys should maybe step back...

[Bush Pig]

I've worked with a couple of MCSEs who weren't morons. Of course, they were Solaris sysadmins who'd got the MCSE as a requirement for some job or other they'd been involved in, but still ...

One of them said he'd had _enormous_ trouble with the MCSE tests, until he figured out the "correct" answers to the questions wasn't the right answer that'd actually solve the problem, it was the answer you'd been taught on the MCSE course.

Re:IMHO, none of that matters to the typical end u

[dtfinch]

For instance, I installed Flash7 for Firefox 1.0. Didn't work. I installed Sun's JAVA for Firefox 1.0. It didn't work either.

I've installed both on several distributions. I have to tell the Flash installer where Mozilla and it handles the rest. For Java, I have to create a symbolic link to it in my Mozilla plugins directory. They both work fine, except that the sound and video get out of sync in Flash.

Small developers have to either open source or pay fees they cannot afford to obtain a "widget set", something that any other OS supplies for free, and defines a standard for.

Except for Qt, most do not require you to pay a fee or open source your app.

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,

I saw this mentioned in the Red Hat bugzilla, affecting RH9 and some RHEL3 users. But they say it was fixed mostly in 2.4.24 and completely in 2.6.

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.

Yeah, but I have to use the Windows command line for a lot of things, or dig around in the registry. People who can't on Windows get help from those who can. The actual amount of command line work necessary in Linux varies between distributions. I can do a lot more fron the Linux command line than from the Windows command line, so I'm more apt to use it.

So mostly, people don't run Linux.

But I'll always run it. Ubuntu is starting to look good. I'm running the unstable hoary hedgehog branch scheduled for release in about 4-5 months. Lots of nice things appear to be on the way.

Why Unix is dead

[symbolset]

There are four relevant parts to Unix:

1. The trademarked name
2. The open, or public domain code and its functionality
3. The proprietary code and its functionality
4. The POSIX architecture

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.

Getting help from Linux gurus

[some guy I know]

But god forbid I ask a question on IRC or anywhere that someone knows anything about linux.

As has been explained countless times in many places, you have to be adversarial if you want your question to be answered on a Linux board.
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:

I can't get my XYZ brand USB mouse to work.
Can someone tell me what modules I have to load and what settings I have to make in the config file?
Thanks.

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 ... like a ... ah, like a board guru on a newbie, responding with comments like "RTFA n00b!" or "Go back to Windows if you can't be bothered to learn the simplest basics about Linux" or other equally-informative messages of encouragement.
Instead, you should have written something like:

It's too bad that Linux is still stuck in the 20th century.
It doesn't even support a USB mouse.
In Windows, I can just plug it in.
Until Linux can support modern hardware, it will always be playing catch-up to Windows.
It's definitely not "ready for the desktop".

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!

Re:Getting help from Linux gurus

[beforewisdom]

My only regret about your post is that it already has the highest score it can get and is already marked "insightful" which it truly is.

Re:IMHO, none of that matters to the typical end u

[jcr]

I'll just mention that these same issues were handled quite well in NeXTSTEP.

-jcr

Re:IMHO, none of that matters to the typical end u

[Tom]

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.

What's wrong with Unix?

[paronomasia5]

Gnu's Not Unix

What's Wrong IS What's Right

[theManInTheYellowHat]

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.

need metainfo in filesystem

[ummit]

I think the biggest single problem is that the filesystem -- specifically, the inode -- hasn't really changed since Unix was born. In particular, there's no central place to put all the new information that fancier systems (e.g. Gnome and KDE) need. So everyone implements this sort of thing using bag-on-the-side kludges instead (and of course everyone's bag is different).

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