We’ve all used UNIX or one of its derivatives. A lot of us use it for development and server applications. Quite a few of us love it. And I’m sure we’ve all got things we hate about it too. Is it time for a new Unix-Hater’s Handbook?
I have a few bones to pick:
a) Inconsistent command-line options:
Most programs use -- in front of their options. For example, mc --version. Some don’t, like dd, find, and other utilities from the Stone Age.
(backward compatibility, blah, blah, blah, it’s been several decades, blah, blah, blah)
b) Directory structure:
Yes, we’ve all heard the reasons why there’s a /bin, /usr/bin, /usr/local/bin, and /usr/local/*/bin, or why there are multiple library locations, or why there’s a /usr and /usr/local, etc. So what?
And then there’s the programs that think they’re somehow special so their default installation location is something like /usr/local/mysql (cough). Or libraries that think they’re special (hello, Qt, I hate you with a passion).
The directory tree is a mess, no matter what the reasons given.
c) Libraries and binaries:
Related to the above, all the binaries and libraries are thrown into a huge pile. Take a look in /usr/lib. Do you know what every library in there does? What its dependencies are? And what about /usr/bin? Don’t forget /usr/local/lib and bin too! And what happens if you have different versions of a library in /usr/lib and /usr/local/lib? Fun!
Yes, in this era of shared libraries and commands accessible from everywhere (ie, ye olde PATH), that’s one solution. Yet, while DOS didn't have shared libraries, its layout was a whole lot simpler. Want to install a program? Put it in its own directory. Want to remove it? Delete directory.
It's not that hard to devise a solution that combines simplicity and consistency with shared libraries and programs. Where is it?
d) The shell:
Zsh/BASH/tcsh, etc, are all a lot better than the windows world. On the other hand, shell scripting is amazingly ugly. Why isn't the shell more extensible? Perl may not be an ideal language, but the perl shells I've seen were a lot saner when it came to making shell scripts. Oh, sh and friends also have a convoluted configuration system.
e) Configuration:
I love doing a ls -la of my homedir. ~90% of the crap I see there are dot files. It’s like every program thinks it has a god-given right to throw a file in there.
And then there are the ones that don’t put a dot file. Nor a dot dir. Nope, they put a _normal_directory there (hello GNUstep, zinf). So now not only is my –la listing full of junk, normal listings are too. Thanks guys.
Why can't they standardize on something like ~/.config/* ? At least then there'd be only one uninteresting entry clogging up the file listing. It’s not that hard to cd .config to get at my settings.
f) Init system:
So how do you like your poison? BSD or SysV? Do they treat you well at night too? Or are you one of the crack-heads who made your own custom init system that uses a makefile so you can parallelize you boot? That makefile’s pretty brittle, huh?
People are having flamewars and religious arguments over BSD and SysV, but they simply both suck (although SysV sucks more, hah!). Maybe Apple is right? I don’t know much about initd, but Apple has a point.
g) Editors:
The major editors are all terrible. Emacs is a monstrosity that required bizarre key-combinations. Vi has that horrible dual-mode (and also has byzantine sequences of keys). I prefer vi myself, and I know vim can remove the dual-mode, but why aren’t there any sane and powerful default editors out there?
h) Library, library, on the wall...:
Since I’m one of the strange people in this world who still downloads source tarball and compiles, I’ve noticed an odd trend: more and more programs are making useless libraries. The developers think it’d be brilliant to put all functionality in the library, and leave some tiny stub program in the binaries.
Of course, nobody ever uses that library other than the original proggie. So why did they make a library in the first place? You’re writing a program, not a library.
Linux-land, at least, has gone library mad. They make and use libraries like it’s air. Then there are the fools who make major pieces of software that require either KDE or Gnome to be installed. And eventually we end up with several pieces of software that use either.
Nah, we’re not using GTK or QT, we’re going all the way, baby!
Wait, I’m running two desktop environments now? At the same time? WHY?!
i) ZOMG FREEDOM!
Does h) sound familiar? Do you often hear the refrain, “but it’s freedom to do and use whatever you want! Evolution! Yayayayay lololol!”
Guess what? As a user I don’t give two hoots about your freedom. I want a system that works, and isn’t held together by cruft and duct-tape.
Guess what? As a developer I don’t care about your fucking freedom either. I want a single API to target (and isn’t held together by cruft and duct-tape)!
Why do I have to use an additional abstraction layer so I’ll be able to use either QT or GTK depending on what’s available?! And what’s the whole deal with autoconf?
If you had a free hand, what would you wish was changed? Do you disagree with me? Flame away and show me where I’m wrong.
>>39
http://img143.imageshack.us/img143/7089/screenshot4do.png
Zsh "menu" let's you scroll and choose with arrows when there are multiple possibilities (I guess tab-completion has same behavior(?)) , works for files, hosts, usernames, parameters of actual command, env variables and possibely everything you ever wanted to tab complete on command line.
Also corrects upper/lower cases, typos based on some rules, ie completing file by r<tab> if there's only file beginning by t or m will commence completing the t... because of possible typo, well you get the idea.
Shells have great posibilities today. Sadly, most distros come with old sucking bash.
oops, tab-completion -> bash-completion (or whatever that extension is called)
Zsh always comes up in these discussions, but every time I try to use it, it doesn't do any of the wonderful stuff mentioned. It seems to really, really need a better default configuration. There's no use in having wonderful features if you go to great lengths to hide them from the users.
>>1
I can't believe how fucking right you are. Quoted for win. I agree on each and every one of your points.
The problems thus far highlighted for the Unix world can be summed up in an analogy I heard once. If operating systems were buildings...
A few people at the Bell Labs thinktank tried to develop the perfect operating system. The first steps, just like erecting a building, are putting up the scaffolding and inventing the needed tools that don't exist yet. But as it turned out, the tools and scaffolding had a fatal flaw: they became too useful and well-designed to be just temporary structures. As a result, the perfect operating system was never built, and what we have in its place are tools and scaffolding.
Hah, that's unusually apt.
apt-get install a_better_os
So far as a) goes, VMS also got this right, in addition to AmigaOS, in a somewhat similar fashion IIRC.
b) on your list is, I think, best handled in current linux distros by gobolinux. They toss out the normal unix directory structure in favor of old-school DOS like one-program a dir type system. I keep meaning to try it out, but am hooked on Ubuntu lately; perhaps when I get Xen setup I'll give it a whirl in a VM!
c) see b) !
d) ksh (real ksh, NOT pdksh) has much better extensibility, in fact it has hooks so you can add syntax!! It's now open source from att labs, so check it out if you want a better shell for scripting. I'm not sure how the default ksh set is for interactive use, I know that it can be turned into bash-equivalent friendliness for interactive use, but the vendors who've used it (Sun, IBM, I mean you!) have had really shitting interactive defaults for it. Not sure about the mothership att distro though. Apple shocked me by having a sane tcsh interactive environment for Terminal!
e) say it, brother!
f) I keep meaning to redo init in a capability-secure variant of Scheme!
g) yes, they do suck, no?
h) I'm in favor of static linking, along with placing things all in one dir like gobolinux does. Or at least stashing your dynamic libraries under your own dir hierarchy like you do in gobolinux (or apples Libraries/ dirs)
Cheers!
-djm
VMS got a lot of things right, particularly security-wise. It's one of those legendary operating systems that a lot of us younger ubergeeks would love to install and play with, but probably never will. Compaq just sits on OpenVMS and largely lets it rot.
The whole Xen and Microsoft story is quite sad too. I'd almost kill for something like Xen, but no Windows supports it on current CPUs. The ability to write and test both server and client software on the same machine at the same time? Wow!
Someone might point out I could do both on one OS, except that some tools I like only work in linux (mainly valgrind), while the client may be a closed-source windows binary. Using Wine is a crapshoot, and I'm not sure what to think of VMware.
Oh man, if there's one thing I want back from AmigaOS, it's ReadArgs(). Best function ever. That, and Datatypes. I can't believe it's the year 2005 and no major OS has an extensible framework for reading generic file types. Mac OS X has a perfect setup for creating that kind of thing, but instead they've just got their half-assed NSImage and NSSound objects.
How does ReadArgs() compare to getopt()? By the sound of >>4 it's a lot more interesting.
They're miles apart. First and foremost, any ReadArgs()-using program would automatically print out its argument template when invoked with "?" as the only argument. That way, there was always a standardized way to see what arguments a command takes. The template isn't the most readable thing, and if I re-implemented it, I would add some cleaning up to make it more readable, but the basic idea of a standardized way to print out the exact argument template is wonderful.
ReadArgs() also isn't anywhere near as anal as getopts() about argument order - there's no need to stuff every option before the filename (to the point that most unix commands require you to specify the output file BEFORE the input file, something that just makes no sense). Since all options are named, you can put them in any order. Only if you leave out the named identifiers does order become important. These would all be equivalent:
copy file.txt directory
copy from file.txt to directory
copy to directory from file.txt
>>1
Totally agree with that. Unfortunately, I doubt any one of them will be fixed ever. <3 unix beard
Very relevant: http://it.slashdot.org/comments.pl?sid=166174&cid=13863290
Ars Technica reviews MS' new command-line environment.
They've integrated scripting and command-line parsing much more tightly. The command-line parser is actually just evaluating expressions in their Perl/Python/Javascript-like language (with extensions to make it more a traditional command line). The commands also read arguments in a style reminescent of ReadArgs(), which makes me very happy (although I think they could do without the dashes everywhere). The syntax is a bit quirky at points, but nothing as bad as Unix shell scripting.
I'm undecided if this is a success or not, but it sure is lightyears ahead of Unix shells.
Heh, not exactly the right link, that. Here is the real one: http://arstechnica.com/guides/other/msh.ars
The one I originally posted should be amusing to Alpha Centauri players, though.
Hallelujah! Maybe someone will rip it off because it's teh evil M$!!1!
About bloody time. Anything is better than *nix shell scripting. It's the programming atrocity of the centu past three decades!
Even if they don't, maybe it could (and I know I've being incredibly naïve here) drive home the point that Unix shell scripting is incredibly primitive and behind the times, and inspire someone to create something better.
>>most unix commands require you to specify the output file BEFORE the input file, something that just makes no sense
Most unix programs require you to specify the output file only if you specifically don't want it on stdout; and most unix shells make it very easy to get stdout into a file, so you don't need to give the output file to the program, you can just tell the shell to redirect the program's output to the file. After the program. Problem solved.
blah -o outfile infile
blah infile > outfile
> Most unix programs require you to specify the output file only if you specifically don't want it on stdout
Incorrect, and even when it is correct, it's incredibly annoying, as you are likely to send binary data to your console, possibly screwing it up, or at least making a lot of noise.
That would be a bug in the program then. It should use the isatty(3) system call in order to avoid outputting binary data on a terminal. gzip for instance does this.
There are a few programs that will write binary data to a terminal if you explicitly specify stdout (they shouldn't), but I don't know of any that do so by default, with no options given.
There are lots that do. I don't know how many times I've had to start a new terminal thanks to some program spewing binary data into my console. The netpbm tools come to mind.
And this whole discussion is yet another example of how Unix is broken: It promotes behaviours that can easily be disruptive, without giving a mechanism to easily avoid the pitfalls, leaving it up to individual program authors to jump through every required (and non-obvious) hoop. In the end you can't blame every individual programmer for not learning the secret tricks, when the system should have provided easy-to-use mechanisms instead.
isatty(3) is hardly a secret trick. It's in POSIX and has a manpage just like everything else. It's no less obvious than any other system call, including open(2) or fopen(3). Are those hoops programmers have to jump through to open files, in your opinion?
>>71
I've had cat do it to me numerous times.
>>72
That's your fault for using cat on a binary file. cat can't know if its input files are binary, unless it buffered and tried to guess. You can avoid this problem by running file(1) before you run cat(1) if there is any doubt about the file's nature.
On the other hand, gzip, netpbm and flac know that their output is always going to be binary.
Waah waah waah! It's all my fault! So terribly sorry, good sir, I promise never to do it again!
I mentioned that cat does this. Since someone wanted an example, there it is.
No, it's not a secret trick that you use "isatty()" to find out if something is a tty. It is a secret trick to know you're supposed to do this when outputting files to stdout, which as you say is a preferred method to do this. A decent system would offer more automated methods to perform such tasks, that hide the details from the programmer so he doesn't have to worry about it.
This doesn't mean there should be a function to combine fwrite() and isatty(), mind you, it means that outputting to the console by default is a retarded idea, especially when the console is designed to break if you do this (needless to say, this is also retarded in itself).
You think I keep a list?
But we're not talking about outputting to the console by default; we're talking about outputting to stdout by default. Yes, it's a standard principle of unix systems that stdout is usually attached to the terminal; and it's also a standard principle of unix systems that stdout is conveniently redirectable via IO redirection and pipes.
I can't believe that anyone who's used unix for more than 5 minutes doesn't just by default pipe things with unknown or variable-length output through a pager like more/less/most etc. (And if your pager blats binary output at your terminal: dude, your pager sucks.)
> I can't believe that anyone who's used unix for more than 5 minutes doesn't just by default pipe things with unknown or variable-length output through a pager like more/less/most etc.
We do, mate, we do. Contrary to what you may think, we're not clueless, and everything you've mentioned up until now is pretty obvious. This isn't about what can and cannot be done; this is about how to do it better than it's done now.
Never having used ReadArgs() I'm in no position to comment. However, WAHa has, and he thinks it's a lot better. So... how about you tell us why the current *nix nuttery is better than ReadArgs(), or at least why it isn't inferior in comparison?
This has just been a long and drawn out response to Waha's comment about needing to specify the output file before the input file. I was just saying that you rarely need to do it that way.
>>ReadArgs etc
Standardised argument parsing is a great idea. But when I look at the proliferation of getopt modules on CPAN I don't exactly feel confident that anyone is ever going to come up with a single way to do it that everyone is happy with. And if people don't like it, they will roll their own, which is exactly how the current *nix nuttery came about.
testing
Fuck you too, >>79.
> It still doesn't have default actions for non-executable files (so that I can just type "main.c" and it'll load it up in a text editor, or "yaranaika.jpg" and it'll open an image viewer.
Guess what I just stumbled upon on some ZSH fansite?
alias -s tex=vim
./a.tex
<vim starts up and displays the file>And another thing..
autoload zmv
zmv '(*).bak' '$1' # Removes '.bak' from all files that match the first argSuperiority! Groar Now I want this to become something like that MSH. I propose ruby as the foundation~
Oh, you can leave out the ./.
alias -s de=$BROWSER
alias -s htm=$BROWSER
alias -s html=$BROWSER$ heise.de
<opens in browser>
$ http://4-ch.net/manga/index.html
<opens in browser>:O
I prefer ksh.
i like fish
That is neat, although of course it still uses horrible incomprehensible Unix syntax, but that's to be expected.
I could also make some comment about having to stumble across these things on some zsh fansite. Zsh seems to be horribly embarrassed about having features, and does its best to not let you know.
>>86
Actually, you can conduct extensive research on all it's features by reading the manpages, but for me, that's a clear case of 'tl;dr'.
>>87
What the fuck is tl;dr?
>>88
"Too long; didn't read". An appropriate comeback to RTFM.
>>89
Ohh, I always thought it was nonsensical, like "fgsfds". Thanks!
And totally agree with WAHa on zsh.
So I've read all this thread and agree with most of the UNIX-hate part, it looks like the proponents of the status quo are always replying that since they spent months of their lives learning about the intricacies of 70's software, everybody should, and if they complain, they just are not intelligent enough.
What UNIX needs to get outside of a server room or a nerd's basement is more vendors that give a big "fuck you" the UNIX way and customs.
But then I use OS X and launch applications using a mouse instad of terminal.app, so maybe I'm just too stupid.
nobody is forcing you idiots to use UNIX. don't like it? don't fucking use it.
What's wrong with noting the deficiencies and fixing them >>92?
PS. DQN is here: http://4-ch.net/dqn/
You're not fixing anything.
You're whining about a simple, coherent and powerful system because you're a whiner who can't create such a thing yourself.
> You're not fixing anything.
The first step to fixing is recognizing there's a problem.
> simple, coherent
Next up: goldfish are deadly.
> you're a whiner
You're in the wrong board. Trolls go here: http://dis.4chan.org/dis/
I shall try to adapt to the level of discussion here. Ahem.
*>>94, if you love Unix so much, why don't you marry it?*
> You're whining about a simple, coherent and powerful system
Looks like you haven't read a manpage in years.
>>95-97 are DQN
"The first step to fixing is recognizing there's a problem."
But you don't do anything about it. You just complain about the people who actually do stuff. If you think UNIX is so bad, show me a system you've made that works better. But you won't because whiners just remain whiners.
I'll expand a bit on this. UNIX is the best and most productive system I've used, and yes, coherent. It all fits together. It's sure not perfect, but the alternatives aren't forthcoming. The critics ITT haven't produced any.
This thread has left a bitter taste in my mouth because many of the criticisms are based on a lack of understanding, or a lack of willingness to understand. >>1 for instance complains about inconsistent command-line options, but nearly all UNIX utilities do use options consistently: they are one character and can be combined, so "-9qo -" is equivalent to "-9 -q -o -". The --long-option style was invented by GNU and has been copied by some applications. It is not at all the standard.
The directory structure >>1 complains about serves a good purpose and is not at all a mess. /bin is for utilities that are needed when the system is booted in single-user mode and the files under /usr may not be available. /usr/bin is for other system programs, and /usr/lib is for system libraries. /usr/local is where applications and application libraries go. These distinctions are important for maintaining servers and timesharing systems. If >>1 only wants a single-user desktop computer, then maybe this is overkill for >>1. I, however, find the /usr vs. /usr/local distinction helpful and the /bin vs. /usr/bin distinction quite livable, if a little superfluous. MySQL and Qt are not part of UNIX and are therefore moot, although if >>1 thinks they suck so much, he's welcome to fix them or make something better.
I can recognize more than half of the files in /usr/lib and have at least a vague idea what the others do. The same goes for /usr/local/lib. I do not know what everything in /usr/bin and /usr/local/bin is, but I can easily find out by typing "man commandname". I do not need to know about library dependencies, because anything in /usr/bin or /usr/lib is part of the operating system and I have no reason to change it, and my operating system supplies a package manager that tracks dependencies in /usr/local/bin and /usr/local/lib (although this is not a standardized part of UNIX).
If "it's not that hard to devise a solution that combines simplicity and consistency with shared libraries and programs," then indeed, >>1, where is it? Anything is easy if you're not the person who has to do it. I find the directory hierarchy simple and consistent enough already. That's not to say it couldn't possibly be improved upon, but you haven't suggested any improvements, and there are more important things to worry about. There is no real problem with the current layout.
The complaints about shell scripting are pointless. If >>1 prefers to write Perl scripts, then why doesn't he just do so? There is nothing different about the process, only that the line at the top has to say "#!/usr/bin/perl" rather than "#!/bin/sh".
The configuration complaint is similarly without merit. The entire reason ls hides dotfiles by default is not to show configuration files. If you don't want to see them, don't give ls the -a option. Then >>1 complains about GNUstep and Zinf saving configuration files visibly, not as dotfiles. This is a valid complaint against those programs, but like the MySQL and Qt examples, the problem lies with poor-quality applications, not UNIX.
It is easier to dismiss a system as worthless and badly designed than to learn to use it properly. But if you must do the former, at least don't make stupid threads, please. If you have something better, just release it, and stop complaining about what exists, okay?
>>102's very valid point aside, how about I show you a shell I made for AmigaOS once back in the day that was much more of a joy to work with than pretty much any Unix shell out there? Will that count?
(Excepting the theoretical possibility that I might one day figure out how to make zsh behave the way I want it to)
Also:
> This thread has left a bitter taste in my mouth because many of the criticisms are based on a lack of understanding, or a lack of willingness to understand.
I think you misspelled "unwillingness to agree with me" at the end there. Trust me, we've had the supposed justification explained to us many, many time, and we are not ignoring them out of some sort of pigheaded denial of the world around us, we actually disagree with them. You can not simply dismiss those who do not agree with you as uninformed or unwilling to learn. As it happens, both me and dmpk2k are, if I may make so bold a claim, highly skilled computer users and programmers. We have many, many years of experience using both Unix and non-Unix systems. It is from exactly this experience that we formulate our criticisms of Unix as it now stands.
I really don't have the time to refute all your points, especially as many of them are refuted here, or even in >>1. If you try to read the thread, you will also notice a criticism of the mindset of many Unix users and developers that there is nothing wrong with Unix, and any problems experienced is due to the person complaining. This is not only incredibly arrogant and irritating, it also not a good attitude for a developer to have, if he wants people to use his product.
> It's sure not perfect, but the alternatives aren't forthcoming.
a) It's not perfect.
b) There aren't any alternatives.
therefore
c) We shouldn't note the shortcomings?
Ignoring that b) is false, I'd really like to know what the hidden premise here is, because c) certainly doesn't follow from a) and b).
>>102, many individuals can write software by themselves. Few can overturn governments and/or start their own countries.
>>103, please do.
>>104, the original post contains many complaints that suggest the writer does not understand the mechanisms involved (see >>101 re: command-line options, directory layout, etc.). Argument from authority will not change this.
>>105. Alternatives. Present some then. VMS? DOS? AmigaOS? Those are all dead. Unix has some deficiencies, but not what you've "noted" -- your notes are the same old whiny rants about how "I don't understand it, therefore it sucks."
> many individuals can write software by themselves. Few can overturn governments and/or start their own countries.
How many write operating systems by themselves? You're just parroting the number one fallacy of the Internet: "If you can't do better, you're not allowed to critize!" Do you never complain about food if you can't make something better? Do you never critize art, music or architecture?
> the original post contains many complaints that suggest the writer does not understand the mechanisms involved
Look, I am trying to tell you: Both him and me do understand. We just do not agree. Try to accept that there is a difference. If you would read >>1 again:
> Yes, we’ve all heard the reasons why there’s a /bin, /usr/bin, /usr/local/bin, and /usr/local/*/bin, or why there are multiple library locations, or why there’s a /usr and /usr/local, etc. So what?
And again: "Yes, we’ve all heard the reasons..." - why then are you repeating them, as if being told them one more time would suddenly make them valid?
For instance: The reason you give for the split between /bin/ and /usr/bin/ is completely invalid on just about every modern Unix system. Modern Unixes, especially those running as a home desktop, are never booted into single-user mode, and if they are, /usr/ is pretty much always available. There is no longer any need for this, yet it is still vehemently defended as a good design decision. That is the attitude we're annoyed by.
>>107 It sure is difficult to drag logic into a debate where so much is at stake for the status quo camp, they don't want to realize that their extensive knowledge of trivia about legacy UNIX quirks would become useless with some clean-up.
I hate all the mystique the UNIX hackers like to have around their OS.
A lot of valuable time is wasted all the time by people who try to learn their way around issues that should have been solved before half of us were born.
Let's all just move to Plan 9. :-)
> Present some then.
Off the top of my head, used commercially: OSX, Windows, QNX, OpenVMS, TRON.
> "I don't understand it, therefore it sucks."
I understand it all too well, mate. Just because you say I don't doesn't make it true. But, if it protects you emotional investment, you'll believe that regardless.
By the way, you still haven't told me what the hidden premise in >>105 is.
>>107, you could at least suggest an alternative design, e.g. instead of doing this, the system should work this way. Write a detailed specification for how the entire system should work and justify why each part of it is best off working the way it does. If you don't want to do that, or are not willing, then maybe you'd best not be commenting on the shortcomings of existing systems. The number one fallacy here is "My ideas are great, and I can just leave the easy part of actually doing something with them to other people." Nobody's going to come along and fix Unix for you because you whined and ranted about it.
>>110: OSX is Unix. Windows -- glad your sense of humor is still there. QNX is a real-time operating system, so it's not suited to the same purposes as Unix. Besides, a quick visit to Wikipedia informs me that it is "POSIX compliant" and "Unix-like." Not familiar enough with your last two examples to comment -- but if they're so good, why aren't you using them, instead of griping about Unix? This is a serious question.
>>111
I thought that this thread was already the spec. You take UNIX and you correct what has been stated to be wrong.
And people may actually take steps to fix UNIX if enough people are pissed off at its current state. Somebody comes up with the idea, somebody with the work. I have seen my share of interesting projets started that way from discussion.
But you know, you really shouldn't expect people to design or develop a complete operating system to make a point in an Internet discussion.
And you cannot say that OS X is UNIX because it is not perceived as such by normal users (by normal users, I mean people who only use terminal.app when coding). It is not a pretty GUI on the top of a standard UNIX, it is UNIX reworked until you could integrate it into Mac OS.
> OSX is Unix.
So... if I mention the mess of libraries that plague *nix, then I'm misguided because that isn't UNIX, but if I mention OSX, all of a sudden it is? You defend against many of my criticisms, yet when OSX attempts to fix those same problems you want to take credit for that?
> Windows -- glad your sense of humor is still there.
I favour pragmatism. I try to use the best tool for the job, and for some things Windows is that tool. Are you saying that there's nothing Windows is better at?
> QNX is a real-time operating system, so it's not suited to the same purposes as Unix.
Why no, it isn't, although the embedded folks would be interested to hear that. Mind you, QNX isn't too bad as a general *nix replacement either. Ever used it for desktop?
But we weren't discussing specific domains. We were discussing flaws with *nix. Just because *nix makes a good server doesn't mean that it has no problems. So the directory hierarchy is ugly, what does that have to do with it serving webpages?
Nobody's going to use my own personal spec either, and neither should they, because it wouldn't be very good. I'm not an operating system designer, nor does everyone have the same requirements as me. That's why we have discussion first to get people interested in the idea, to indentify problems, and to suggest improvements. Such as this very thread.
Are you seriously suggesting that every single person who has problems with Unix should make up their own design before they are allowed to even talk about it?
>>112
Unfortunately, nobody seems to be correcting anything ITT, just complaining.
I don't expect anyone to design an operating system to make a point, but surely in order for a better operating system to exist.
>>113 is DQN. The "mess of libraries" is an application issue -- third time I've had to say this. I'm not defending KDE or GNOME. And operating systems that serve a different purpose are not alternatives -- should be obvious, right?
>>114
Certainly anyone should have given serious thought to a better design before they begin to talk about it with your sort of attitude: "It's not me, it's Unix." If you believe the root of the problem is Unix being flawed, you should be ready to suggest a system design that isn't.
If what you people are trying to say is that Unix is not ideal for desktop systems with GUIs, I agree. Moreover, for that application, I think it should be replaced, not fixed.
> The "mess of libraries" is an application issue -- third time I've had to say this.
And M$ Windows has DLL-hell, amirite?
It looks like I have to spell this out for you:
> And operating systems that serve a different purpose are not alternatives
Why not? Why isn't Windows an alternative? Why not QNX? Why not all the others? It's only an alternative if it's in an problem domain where UNIX is superior, right? The fact that people are trying to push linux embedded (where QNX and TRON make their daily bread) have nothing to do with this, right?
And again, what does this have to do with anything? Even if *nix was the only solution, and no others existed, does that mean the ugliness vanishes? That somehow the directory hierarchy improves itself, there are fewer inconsistencies everywhere, the commonly installed shells magically suck less, and the library mess fixes itself? *nix is somehow suddenly perfect?
> If you believe the root of the problem is Unix being flawed, you should be ready to suggest a system design that isn't.
One of my professors at uni is an old-skool OS developer (now retired) who happens to like Solaris. When I ask him about the problems with initd, all I get is a bunch of handwaving. He is unable to give me a single reason why initd is better than launchd, other than something along the lines of, "it's missing the magic".
The problem is that the *nix of today evolved that way. Normally I'd applaud that, but now there's cruft in there that's several decades old. Even parts that were there in the initial design could use replacement, but they're still there because of inertia (the same reason the linux fanatics always gripe that Windows is still here).
When better solutions comes along, what happens? They're ignored due to dogma and familiarity.
You're right to some degree about good ideas being ignored. Fortunately, though, there are enough Unices out there that at least one of them generally implements any particular good idea.
I'm thinking of strlcpy and strlcat, for instance, which are now available pretty much everywhere except on Linux.
Another way of looking at it: Steve McConnell, in his book "Code Complete", introduces the idea of a "technology wave": if you're on the early end of the wave, you're working with new technologies that are exciting but still developing, and you may not have very mature tools. On the late end of the wave, your tools are hardened, battle-tested, but consist mostly of thoroughly crusty technology.
Unix is very late-wave now. For me this is a good thing, because having a solid, carefully put together operating system is important to me. It does mean some aspects look a bit quaint (e.g. /bin vs. /usr/bin is rarely a useful distinction anymore), but not so much that I can't be productive.
Now, Microsoft's "monad shell" is an interesting idea. I haven't used it, but examples I've heard give me the flavor; for instance when you type "ls", instead of having text thrown at you, you see objects, which have properties and can be manipulated. I'll be the first to admit that seems quite a bit more powerful than cut, paste, find, and xargs. But this is real early-wave stuff, so for the moment, it's only interesting to experiment with, not to use on a daily basis.
I don't think any major improvements will be made to Unix. All you'd end up with would be an incompatible Unix, and who wants to use that? I think the next big system architecture will have to start from scratch. It also won't be written in C. When C is your systems language, Unix is probably about the best you can do. The next kind of system will use, and popularize, a more higher-level language, like Lisp, Haskell, or who knows what.
> The next kind of system will use, and popularize, a more higher-level language, like Lisp, Haskell, or who knows what.
and will probably require 2GB of RAM to run well (Windows Vista, anyone?)
There used to be computers that ran everything with lisp (see: lisp machines).
Some commercial lisp compilers can come close to C, as can certain dialects of ML. Given the additional leverage you're getting from higher level languages, it would almost certainly be a worthwhile tradeoff.
>>120
Actually, I swear Microsoft wrote most of Vista in Haskell. Not only would it totally explain the astronomical memory requirements, it also might explain the rumors that they've finally built a secure OS this time. (There are no buffer overflows in Haskell programs.)
>> (There are no buffer overflows in Haskell programs.)
I bet MS could find a way
No, they really couldn't! Haskell is referentially transparent and purely functional. There's no such thing as a pointer in it.
I suppose they could mess up and have a buffer overflow inside part of the Haskell run-time system, though.
after finally looking at plan 9, i have to say it looks like it could be a very nice system if it had better graphics capabilities and more apps ported to it...
I think it's pretty safe to assume that if your language can't have a buffer overflow, you can't code an OS in it either. Part of an OS, sure, but not the whole thing.
>>126
I meant the vast majority of it. You can at least code all of userland in such a language, and probably parts of the kernel.
Also, 0x80GET!
>>117
That's typical behaviour from Solaris fans. Deride everything until it appears in Solaris, then claim ground-breaking and revolutionary. I have to constantly put up with them; they spend years bashing features in other OSes not in Solaris, then magically when Solaris gets a piss poor copy of them (under a different name, naturally), the bitches won't stop extolling the virtues of it and claiming how it's the first of its kind. e.g. DTrace, just a weak copy of perf counters.
> DTrace, just a weak copy of perf counters.
Hahaha, what?
>>130
Sounds like the cdrecord guy; apparently, Solaris is the gold standard of SCSI device handling, and other OSes require so much ostensibly horrible hackery to get working that he'd rather not deal with them unless they're "reasonably close" to what Solaris does. The comments bashing Linux in the libscg source are particularly telling (and they only got worse after his little hissy fit on linux-kernel).
Not only that, but "libscg" insists on viewing things through the guise of a Unix workstation circa 1992 (e.g. a SPARCstation IPX or SS1); it demands a SCSI bus:target:LUN address and will freak out at you if you hand it a device node. (It may still work, but it still bitches you out.) This, of course, makes ittle sense if you're trying to burn to a non-SCSI device (you could argue that anything that speaks SCSI is subject to the SCSI Parallel Interface rules, but not even SCSI-2 or CAM says that, and Windows certainly doesn't do it that way), and I haven't seen a new SCSI CD writer in years (only the very first DVD recorders were SCSI, not that cdrecord will support them without getting "ProDVD"...).
Someone at SuSE patched the warning about this out of their version of cdrecord, and he screamed and yelled about it on linux-kernel until they told him to go away. (He does the same thing on the Debian bug tracking system whenever someone does something "inofficial" with cdrtools...god damn annoying, that). I find that behavior childish and unprofessional, and would like to see cdrecord replaced because of it. I've considered doing it myself, using some patches I made up to FreeBSD's burncd program for another project, but I just haven't given myself the time to write SCSI support layers for other OSes and clean it up.
The directory structure can be fixed, take a look at heretix(http://www.h-e-r-e-t-i-x.org/, a new linux distrobation, everything is written in ruby(the init system too). The package manager installs everything into /pkg with a name system based on the package name and version. For example GCC 3.4 is installed as /pkg/gcc/3.4/. Then it's symlinked into /bin, /lib and so forth.
At the moment it uses WhiteWater(a bittorrent like protocol) for distrobation. But a change to a new protocol is expected with the next stable release.
Sure there are som problems with their implentation but it is a change for the better and imho the road that alot of distros will take.
>>133
That sounds like a half-done version of GoboLinux.
http://www.gobolinux.org/
"Distrobation" is my new favourite nonsense word.
Why the emphasis on it being written in Ruby? That's hardly noteworthy.
>>137
I looked up FHS on Wikipedia. It seems to be a fairly new standard that everyone ignores in the first place, based on the article. I suspect you meant to trash on the de-facto standards that preceded FHS (/etc, /bin, /sbin, /usr/bin and so on).
>>134
GoboLinux is doing stupid things, like adding capital letters to the begining of names. It doesn't do anything new excecpt change the names of stuff.
>>136
Easily extended init system.
>>135
Embrace it.
>>137
FHS is just de facto heir with ugly /opt added to it.
>>138
It is better then the windows way of doing things, it was created before the thought of dependency handling :).
>GoboLinux is doing stupid things, like adding capital letters to the begining of names. It doesn't do anything new excecpt change the names of stuff.
So if different FS layout and init system don't qualify as "new", what exactly is remarkable about heretix? The portage clone in Ruby?
> Easily extended init system.
i don't know ruby.
learning ruby is a decidedly nontrivial task.
therefore i suggest you refrain from using the word "Easily" next time.
> GoboLinux is doing stupid things, like adding capital letters to the begining of names. It doesn't do anything new excecpt change the names of stuff.
This statement makes no sense.
Problem: File system is badly structured.
Attempted solution: Changing the names of stuff to arrange it better.
Complaint: Changing names does nothing new.
what
>>141 is right on. If it's supposed to be easy, it should be possible to do it in my choice of language.
If it's supposed to be easy, it shouldn't be using a "language" at all.
"It's possible to program a computer in English. It's also possible to make an airplane controlled by reins and spurs." -- John McCarthy
>>138
Yes, I meant the guys who came up with that shit. Didn't know FHS was new, I thought I just had found a name for the source of all evil.
> GoboLinux is doing stupid things, like adding capital letters to the begining of names.
Capital letters aren't stupid. They look better. For example, see the menu on the left here in 4-ch. If it were all lowercase, it'd look like a GNU hippie's job.
> It is better then the windows way of doing things
Ha ha, no.>>139
Capital letters aren't stupid. They look better. For example, see the menu on the left here in 4-ch. If it were all lowercase, it'd look like a GNU hippie's job.
Capital letters are stupid for path names because you have to mash the shift key all the time.
Capital letters are good... if you have a case-insensitive filesystem (sup NTFS)