After receiving several comments to his November 2005 article on hating UNIX, David Chisnall offers his responses and further insight on his continuing disdain.
10 Things I Hate About U(NIX) Revisited: Readers Speak
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
I will never understand why some people waste their time to speak or write about something they don’t like.
Your time is limited, you should speak about what you like instead …
I disagree. I talk about things I don’t like more than things I do like. The reason is because there is always hope that someone might listen and corrects the problem.
In fact, you see this on all aspects of life. When things are right, you don’t hear a peep (not even a ‘thank you’ card). When things are not right though, everyone has an opinion somehow. It’s how most humans work. And it’s a good thing, because it drives interest and hense, fixes.
I wish I could vote your comment up. Good points.
I will never understand why some people waste their time to speak or write about something they don’t like.
Your time is limited, you should speak about what you like instead …
And yet here you are writing about how you don’t like how the guy writes about things he doesn’t like 😉
I will never understand why some people waste their time to speak or write about something they don’t like.
Your time is limited, you should speak about what you like instead …
I Agree, but actually reading the article this fellow is not just some weenie writer blogging about the glory of Windows or Mac, he’s a weenie writer knows one hell of a lot about UNIX. Worth a read.
Wow! This guy is so ahead of his time! I’m sure that nobody (plan 9) ever (plan 9) thought (plan 9) of these ideas before.
Seriously, though… plan 9 does all that he wants and more. And it’s been around for eons. And it was developed by the original Unix crew. Cuz, ya know, they decided that instead of whining about leaking abstractions, they could actually *make* something better. And after all, if he can consider QNX or Mach Unices, then plan 9 counts just as much.
I suggest David take a look around before griping about Unix’s impotence. Just because most implementations are broken or shaky doesn’t mean the entire concept is wrong. In fact, plan 9 was a direct attempt to get the Unix philosophy right this time.
P.S. Want BSD-style inits in Linux? OPEN YOUR EYES, DAVE!! Try Arch. (Oh, and smile: it’s only computing)
I’ve never used Plan 9, though it’s been on my list of things to experiment with for some time. Here’s the link for those who are curious:
http://cm.bell-labs.com/plan9/
His gripe about shell globing not being in a shared library is still silly and contrived.
Not really. The problem with globing being in the shell is that application never get a chance to pre-process their command line arguments before the shell expands them. At least if the globing were somewhere both the shell and the application could access it and control it’s behavour, commands such as “mv *.foo *.bar” would actually have a chance of working.
Edited 2006-03-20 10:30
At least if the globing were somewhere both the shell and the application could access it and control it’s behavour, commands such as “mv *.foo *.bar” would actually have a chance of working.
And to think people were heftily discussing the expressiveness of the commandline only yesterday
What’s wrong with “for f in *.foo; do mv $f $(basename $f .foo).bar; done”?
“mv *.foo *.bar” doesn’t make much sense, something like “rename *.foo .foo .bar” would seem more logical.
And of course file globing is available from the glibc, so writing a rename command which would correctly handle “rename ‘*.foo’ .bar” is very easy. Such a command is just too specific to become part of the standard Unix toolbox.
It was mearly a simple example. What’s wrong with your equivilent loop is that it is far more verbose and less obvious. Why write a for loop when the shell could do it for me? What if I wanted to do “mv qux*_foo_*_.[cpp|h] qux_bar_*_.[cpp|h]”? Write, test and debug an even bigger shell script?
Just because the UNIX shell doesn’t allow me to write “mv *.foo *.bar” doesn’t mean it’s a bad idea. Why should there be an artificial barrier to writing applications to do more useful things?
It was mearly a simple example
And someone competent came with the solution right away. You should start to understand where the problem is.
No, the guy is no genius, he jus knows his tools.
What’s wrong with your equivilent loop is that it is far more verbose and less obvious
BS, it was pretty obvious to me. ‘far more verbose’ and ‘less obvious’. Wow man, you don’t even know what you want.
The guy did your job but obviously, what you want is not your job done, what you want is disparage the shell as it is, to find an issue where there is none.
Good luck on that. FYI, I have production code in shell far more complicated than that, that do things you could apparently not understand (if you find this not obvious).
I learnt the shell in one week, the rest is experience, so I fail to see where you people find an issue.
Why write a for loop when the shell could do it for me?
Because the shell does not read your mind ? Some people are amazing, searching issues where there are none. Look at the rename command.
What if I wanted to do “mv qux*_foo_*_.[cpp|h] qux_bar_*_.[cpp|h]”? Write, test and debug an even bigger shell script?
Why not ? With sed for example. Or use rename.
Just because the UNIX shell doesn’t allow me to write “mv *.foo *.bar” doesn’t mean it’s a bad idea
Wrong, it allows you to do it as long as the last name is a directory. The only problem here, is that YOU do not understand what this command means.
You think the authors of mv should have designed it like you think, you don’t even understand the problem is that you don’t understand what mv does.
Why should there be an artificial barrier to writing applications to do more useful things?
There is none. But that’s not what you want. What you want is redefine existing well entrenched Unix commands, because of a whim.
And you use stupid articles (and guys) like this one to justify your wrong view.
When I hear people saying such nonsense, it reminds me of my CS courses, when I realised how much design was important, and how much design had been put in common Unix commands.
Thanks for spelling that out, some people never get it. Too bad I don’t have any mod points because you certainly deserve them.
Because “mv *.foo *.bar” would introduce a discrepancy with the way file globing usualy works. ‘*.bar’ doesn’t stand for anything in your example, you might as well drop the *.
I think introducing this kind of odd behaviour makes the shell less user friendly, not more user friendly. The for loop might be more verbose but at least it’s clear, comprehensible and coherent with the rest of the system. As I said ‘remame *.foo .foo .bat’ for example is not much longer than ‘mv *.foo *.bat’ and compliant with the Unix semantic, it’s a much better solution.
As for your new command, I suppose you meant “mv qux_foo_*_.{cpp,h} qux_bar_*_.{cpp,h}”, it looks more and more as if your mv command is going to have to read in the user’s mind, using regular expressions would be much more natural and less error prone (what if the two file globings don’t match?). “rename qux_foo_*_.{cpp,h} s/qux_foo/qux_bar/”, or today:
for f in qux_foo_*_.{cpp,h}; do mv $f $(sed ‘s/qux_foo/qux_bar/’ <<< $f); done
You’re trying to fix a problem which doesn’t exist.
To be fair, I’m not trying to fix anything. If I personally really felt that file globing was a big problem, Syllable wouldn’t be using bash and I’d have written a different shell that doesn’t do automatic globing. There are generally workarounds to most problems; you’ve provided plenty of examples of scripts that can do mv operations on complex filesets.
What bothers me is the argument “That’s the way UNIX has always done it so it can’t ever be wrong”. Globing is mearly a simple example of this.
P.S: O.K, so “mv *.foo *.bar” isn’t syntactically correct if you’re running a Bourne-like shell. Nor does “mv *.foo .bar” make much sense and .bar could be a directory anyway. Your suggestion of having a special purpose “rename” command isn’t right either; now you have two commands “mv” to move files and “rename” to rename them and the user needs to know what the difference is.
Perhaps my real beef is that the Bourne shell syntax is not expressive enough. Or perhaps it’s the fact that traditionally, UNIX commands are non-interactive so can not gracefully handle ambigious cases. Perhaps the problem only exists in my head and everything is just peachy. Although I’d rather be talking about these sorts of things than taking the absolute position that UNIX is the evolutionary be-all and end-all of Operating System design.
There are generally workarounds to most problems
There start the misunderstanding : these are not workarounds, these are the correct way to deal with the problem, AKA one of the solutions.
What bothers me is the argument “That’s the way UNIX has always done it so it can’t ever be wrong”. Globing is mearly a simple example of this
And there lies another misunderstanding. The argument is not that at all, the argument is “UNIX has been thought out but people keep coming, that without having studied anything about Unix and its command line, come with solutions full of design problems, worse than what we have now”.
Saying globing is wrong, when it lays on years of studies of automata design and logic, that you learn in CS courses, is amazing to me. Especially since globing works so well.
At least, the author of the original troll seems to know Unix.
P.S: O.K, so “mv *.foo *.bar” isn’t syntactically correct if you’re running a Bourne-like shell
Wrong again, it’s syntactically correct, it just is not gramatically correct (with the mv command) if .bar is not a directory. Then the shell won’t complain, mv will.
Nor does “mv *.foo .bar” make much sense and .bar could be a directory anyway
Again, it makes sense, and will work as long as .bar is a directory.
Your suggestion of having a special purpose “rename” command isn’t right either; now you have two commands “mv” to move files and “rename” to rename them and the user needs to know what the difference is
Knowing your tool. That’s what I talked about earlier. Man is there for a reason.
Like I said earlier too, the problem here is not the tool, it’s a bad understanding of regular expression : a beginner’s classic mistake.
Perhaps my real beef is that the Bourne shell syntax is not expressive enough. Or perhaps it’s the fact that traditionally, UNIX commands are non-interactive so can not gracefully handle ambigious cases
What do you mean ? Of course they can. You’re starting a course on automata or what ? That’s precisely the kind of things that automata try to solve, and you can write one in shell if you want (I would not advise you to do that though).
Wow. You’ve managed to reply to my post without ever reading it. You havn’t even the slightest understanding of the small out-of context parts of my post that you’ve quoted. NIce work.
Heres the executive summary for you:
1) I never said globbing was bad.
2) I never said “mv *.foo *.bar” was wrong as it is currently implemented
3) I never said “mv *.foo .bar” was wrong either.
4) It boggles my mind that anyone could think having two tools that do only slightly different things could be a good idea.
5) UNIX tools are not traditionally interactive.
6) You’ve completly flown off the handle and entirely missed the point of the article, the arguments raised within, my reply and no doubt, this reply as well.
Well done. You qualify for your UNIX beard and certificate of “Approaching Computing as a Purely Academic Excercise”.
1) I never said globbing was bad.
2) I never said “mv *.foo *.bar” was wrong as it is currently implemented
3) I never said “mv *.foo .bar” was wrong either
Of course not, you just said “if the globing were somewhere both the shell and the application could access it and control it’s behavour, commands such as “mv *.foo *.bar” would actually have a chance of working”.
Except that “mv *.foo *.bar” and “mv *.foo .bar” work.
4) It boggles my mind that anyone could think having two tools that do only slightly different things could be a good idea
Look who will talk about “Purely Academic Excercise” later. In the real world, people make other tools that make slightly different things, but are more specific, like mv and rename.
5) UNIX tools are not traditionally interactive
Like ed/ex, terminals ? Most are not, yes. I doubt that’s a tradition.
6) You’ve completly flown off the handle and entirely missed the point of the article, the arguments raised within, my reply and no doubt, this reply as well
You just failed to explain how, like a good troll.
Well done. You qualify for your UNIX beard and certificate of “Approaching Computing as a Purely Academic Excercise”
And again, like a good troll, you forgot conveniently that I said I use the shell practically in my work.
It’s not so much that it’s “the way it has always been” as it is that there is a good reason for things to be the way they are, and if you don’t fully understand how file globing works and why it is the way it is, then you may think that something is wrong with it.
If something was wrong with the way it works and if some other way had clear advantages it would have been fixed a long time ago, the Unix world is not that conservative.
Well I’d disagree to a certain extent. UNIX is pretty conservative about these things. That’s why it’s still fundementally the same OS it was 35 years ago.
As the author of the original article points out, when globbing was implemented as part of the shell it was a good idea. These days, perhaps it isn’t. Maybe things could be made more flexible if globing wasn’t built into the shell.
As it happens, this is one of those things that just can’t change. It’s baked right into the design. Not performing globing before passing the arguments to the executable would break pretty much everything; applications would need to be re-written to perform the globing themselves and expand the raw shell arguments, and that clearly isn’t going to happen.
What’s been really amazing is that a simple reply to make the simple point that perhaps a design decision made over 30 years may not be the best design today has erupted into a long thread about the merits of globing, something that I happen to care very little about in the grand scheme of UNIX design. Even if I don’t think it’s much of a problem, it’s amazing to see that many people arn’t even willing to consider the possibility that it could be done better today.
As the author of the original article points out, when globbing was implemented as part of the shell it was a good idea. These days, perhaps it isn’t. Maybe things could be made more flexible if globing wasn’t built into the shell
So the article is based on shaky grounds ? The author based all this rant on supposition ? Well, it reads like a troll.
As it happens, this is one of those things that just can’t change. It’s baked right into the design. Not performing globing before passing the arguments to the executable would break pretty much everything
Did you hear about quotes ? There’s no need to remove the globing from the shell, there are already mechanisms preventing the shell from parsing the arguments
And it doesn’t break anything if you quote the arguments. So I still fail to see where the problem could be in the design.
What’s been really amazing is that a simple reply to make the simple point that perhaps a design decision made over 30 years may not be the best design today
Everybody can say “perhaps sth is not the best”. It stays an empty discussion until you bring something to support your claim.
Even if I don’t think it’s much of a problem, it’s amazing to see that many people arn’t even willing to consider the possibility that it could be done better today
And I find amazing that some people, out of boredom, make some troll based on empty discussions, searching for problems where there are none.
That’s not how you do things better. You have to find issues first, then try to solve them, proposing sth.
As with using the shell for all these years, I still fail to see any issues with its design : I don’t even master it yet, and can do very powerful things already (things like some used on production servers). Companies invent big GUI programs to do a little of what the shell can do in one line.
You mean like the “rename” command, shipped with my system? Quoting from the man page:
NAME
rename – Rename files
SYNOPSIS
rename from to file…
DESCRIPTION
rename will rename the specified files by replacing the first occurrence of from in their name by to.
Yeah, and such a command does actually exist. It’s syntax is (from `man rename`):
rename .htm .html *.htm
I think the Amiga solved a number of the Unix problems mentioned here quite some time ago. Pity the underlying hardware, distribution, and marketing were not up to the competition.
I think this guy has a lot to offer.
Instead of speaking of how good things are “*Nix owns windoze”, he actually has a pragmatic approach about what can be improved. More devs should be this sincere about what they’re doing and try to solve problems instead of just saying the others are worse.
So let’s not get upset about this, let’s instead see how can the issues he bring up be solved?
I think this guy has a lot to offer
I think he has nothing to offer.
Reading his rant or troll, how you want to call it, does not give you ANYTHING.
Instead of speaking of how good things are “*Nix owns windoze”, he actually has a pragmatic approach about what can be improved
No he doesn’t. I did not see any approach of anything. OTOH the guy just says nonsense.
For example, reimplement part of the shell : we will not be any better even if it’s done, and it will require rewriting several apps, putting more bugs.
Or security. This guy says Windows kernel is better because it is more fine grained. Did this guy heard about KISS or “complexity kills security” ?
He even give examples of complexity killing security on Windows (how stupid one can be ?), but put the blame on the user, not on MS. Yeah right, the Windows user must be a security wizard now …
With your straw man of “*nix owns windoze”, you’re in line with the guy’s troll, right.
More devs should be this sincere about what they’re doing and try to solve problems instead of just saying the others are worse
Except that the author clearly says that security is still better on Unix, so the devs you talk about are the author and Windows ones.
Perceived excellent security of Windows kernel is BS if the OS around it can’t use it properly.
So let’s not get upset about this, let’s instead see how can the issues he bring up be solved?
Except that there are no issues. Where are the issues you talk about ?
The guy is talking about things he doesn’t like, the only issue is himself.
Come back when you have real people with real issues, not some rant or troll fest.
Wow, the article totally went over your head.
Shame you get so defensive when he criticizes your pet OS.
The guy is correct: Unix sucks. So does Windows, because it is simply Unix all over with a different all-in-one API.
What we need is an operating system where:
1) the filesystem is typed: each file is of a particular type.
2) the filesystem is a database.
3) the system keeps the code to manage each type in a shared library.
4) the command line is the same programming language used by the system.
5) the O/S is transparently distributed.
I would also like to point out that message-based O/Ses would be much better if CPUs were not monolithic things that only support user/supervisor privileges. By extending the idea of virtual memory, CPU designers could add memory maps to modules that are implicit: a call to a procedure would switch memory map (just like a task switch changes the page table), thus making message passing and modularity really fast and easy.
Edited 2006-03-20 11:37
You should try working on a AS/400. Fits most of your laundry list
Wait, I think he’s looking for PICK.
but I think that the NeWS section has some truth. I really like X11. However a NeWS system would be also very good to be present. We could keep both. However someone must release the source code ….. and give us a chance to update it. There is also of hardware like low cost Xscale machines (no-fpu) that can be used as NeWS servers and can benefit from it. Another good idea is also beneficial. I do not believe in killing motif / openlook /cde / lpr and other old Unix heritage is good. We should update them and keep current. UNIX is synonymous to innovation and democracy of ideas (instead of the vendors’ attempt to financial dictatorship and medieval practices). NeWS has lot of innovation and did not deserve to die such a silent death. We need developers and documentation to help.
> The original UNIX system was used mainly for text
> processing. In this context, small programs were an
> adequate substitute for shared libraries (and easier to
> implement). Gradually this little hack became a
> tradition, and the original reasons for it were overlooked.
Finally, somebody found the flaw in “lots of small programs with well-defined tasks”. If they were library procedures, they could be used as components in bigger programs without a lot of problems:
– no formatting of the data streams into and out of the component. One would not be limited to character streams but could send whole data structures at once.
– ease of use and type safety for the data passed into and out of the components
– with a nice scripting language, these components could still be assembled to three-line scripts, and possibly much easier than done today with the shell
– the library procedure can still be wrapped by a minimal application to be available at the command-line or GUI
… and so on …
> The ideas outlined here are just one potential
> approach to making microkernels more efficient. For a
> taste of how scalable asynchronous programming can
> be, try playing with Erlang and get used to the
> feeling that you can make your code faster by
> throwing another few dozen cluster nodes at it.
I think this is a bit naive. Sure, performance skyrockets that way, but it’s exactly the asynchronous behaviour that will cause race conditions on a higher level. In a microkernel system, where everything runs in parallel *asynchronously*, noone can really predict all possible orderings of actions. The only way to keep control is to use special ordering constructs, but even then it’s hard, and most programmers will be lazy anyway and just hope it works.
Why do you guys have that opinions about other point of view ? Why, if you are the knowledge, don´t you justify for a+b you opinion ? Then all of us can learn.
Edited 2006-03-20 14:17
“man rename” was too much effort you to read, right?
From the man page:
“”rename” renames the filenames supplied according to the rule specified as the first argument.”
And fiddling with the first example:
rename ’s/.foo$/.bar/’ *.foo
Of course, this only solves your problem for the mv *.foo *.bar example, so I invite you to come up with another example.
psn@lupin:~$ which rename
/usr/bin/rename
You might not be the only with the same idea.
OK..this ONE question/answer per each page is a joke…read this single page version instead.
http://www.informit.com/articles/printerfriendly.asp?p=456824
This is an odd concept, but give BeOS a shot. Yes, I know it’s “dead” – but that’s not an appropriate term for any operating system because someone out there will be using it (whatever it is) for years to come. Support is limited, and software is getting sparser – but if all you want is a jumping-off point into the giant vat of *nix, Be (Haiku, Zeta, whatever) may be an interesting venture. It is not an official (or very portable) unix variant, but for the beginner – it may be (rather, it probably IS) much more usable to the novice than any Linux out there. The responsiveness, intuitive layout, filesystem, and stability it was so famed for will never go away, but will only be forgotten.
If it had been kept secure (which wouldn’t have been difficult – just use a login and permissions) and proper posix bindings, it would have taken over the unix geek world. But alas, it was just a little too unique to be accepted by the rest of the posix world. If Apple knew what was good for them, they would’ve use the Be kernel versus this awful Mach implementation (I use OS X alot, so don’t flame me on this – I know of what I speek). The stopwatch, hourglass, pinwhee-o-doom, whatever your OS uses, just remember – There is NO such icon in BE!
I went back and read the original article, and it seems like he is arguing for *nix to be more UNIX-like. He doesn’t seem to be saying *nix sucks, MS rulz. He is saying that, for example: ‘everything is a file’ should be more consistenly applied, processes should be queued/executed asynchronously, etc. In a nutshell, he is saying that the the road *nix started should be extended and adopted into the mainstream. What is so wrong with that?
What’s wrong with it? Commenters lik erecting false dichotomies between Unix and MS, that’s what!
4) the command line is the same programming language used by the system.
I think you’re looking for a Lisp machine. At least I hope you are. I could handle typing (cd “/”) when I wanted to change directories. Having to type int main(){cd(“/”);return 0;} would be a bit much.
I think you’re looking for a Lisp machine. At least I hope you are. I could handle typing (cd “/”) when I wanted to change directories. Having to type int main(){cd(“/”);return 0;} would be a bit much.
Why should it be a lisp machine? how about a simple
cd “/”
???
why should it be C syntax??? methinks lots of people are stack into Unix and C…
1 part pr page, where the 5 first are about something that could have been coverd in one page…
He answers 8 bad questions, that were largely the same complaint, and only the last question was the interesting one. And he made a good point. But his point could have been just as easily been written this way:
I wasn’t dissing Unix, I was saying we should improve it and how to go about that.
But 10 Things I Hate About Unix is so much more catchy
.
Frankly, all this complaining about shell expansion is pretty much ridiculous. Do not want it? Put double quotes on the strings “to be expanded”. Need to use RE by yourself? Well, regex is there for just that.
About security, well NT-style “no thanks” to me. Just go to fix a compromised Windows Server anytime. If you like it, you deserve it.
I have to agree with Ookaze about the “issues”, they don’t exist! Or the guy don’t understand/know how to use them properly or forgot about the trade-in that was made when the design/implementation was settled.