Linked by Eugenia Loli on Mon 20th Mar 2006 07:13 UTC
General Unix After receiving several comments to his November 2005 article on hating UNIX, David Chisnall offers his responses and further insight on his continuing disdain.
Order by: Score:
well
by Duffman on Mon 20th Mar 2006 07:30 UTC
Duffman
Member since:
2005-11-23

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

Reply Score: 2

RE: well
by Eugenia on Mon 20th Mar 2006 07:36 UTC in reply to "well"
Eugenia Member since:
2005-06-28

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.

Reply Score: 5

RE[2]: well
by ma_d on Mon 20th Mar 2006 22:22 UTC in reply to "RE: well"
ma_d Member since:
2005-06-29

I wish I could vote your comment up. Good points.

Reply Score: 1

RE: well
by Tyr. on Mon 20th Mar 2006 09:15 UTC in reply to "well"
Tyr. Member since:
2005-07-06

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

Reply Score: 5

RE: well
by HankCommenter on Tue 21st Mar 2006 04:51 UTC in reply to "well"
HankCommenter Member since:
2006-03-21

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.

Reply Score: 1

Cutting Edge!!!
by monodeldiablo on Mon 20th Mar 2006 09:25 UTC
monodeldiablo
Member since:
2005-07-06

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)

Reply Score: 5

Plan 9
by KenJackson on Mon 20th Mar 2006 18:06 UTC in reply to "Cutting Edge!!!"
KenJackson Member since:
2005-07-18

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/

Reply Score: 1

Shell Globing
by rajj on Mon 20th Mar 2006 10:02 UTC
rajj
Member since:
2005-07-06

His gripe about shell globing not being in a shared library is still silly and contrived.

Reply Score: 1

RE: Shell Globing
by Vanders on Mon 20th Mar 2006 10:29 UTC in reply to "Shell Globing"
Vanders Member since:
2005-07-06

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

Reply Score: 2

RE[2]: Shell Globing
by Ronald Vos on Mon 20th Mar 2006 11:08 UTC in reply to "RE: Shell Globing"
Ronald Vos Member since:
2005-07-06

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

Reply Score: 1

RE[2]: Shell Globing
by Sheld on Mon 20th Mar 2006 14:06 UTC in reply to "RE: Shell Globing"
Sheld Member since:
2005-12-21

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.

Reply Score: 5

RE[3]: Shell Globing
by Vanders on Mon 20th Mar 2006 14:37 UTC in reply to "RE[2]: Shell Globing"
Vanders Member since:
2005-07-06

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?

Reply Score: 1

RE[4]: Shell Globing
by Ookaze on Mon 20th Mar 2006 15:03 UTC in reply to "RE[3]: Shell Globing"
Ookaze Member since:
2005-11-14

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.

Reply Score: 5

RE[5]: Shell Globing
by Sphinx on Mon 20th Mar 2006 16:48 UTC in reply to "RE[4]: Shell Globing"
Sphinx Member since:
2005-07-09

Thanks for spelling that out, some people never get it. Too bad I don't have any mod points because you certainly deserve them.

Reply Score: 1

RE[4]: Shell Globing
by Sheld on Mon 20th Mar 2006 15:08 UTC in reply to "RE[3]: Shell Globing"
Sheld Member since:
2005-12-21

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.

Reply Score: 1

RE[5]: Shell Globing
by Vanders on Mon 20th Mar 2006 16:07 UTC in reply to "RE[4]: Shell Globing"
Vanders Member since:
2005-07-06

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.

Reply Score: 3

RE[6]: Shell Globing
by Ookaze on Mon 20th Mar 2006 17:40 UTC in reply to "RE[5]: Shell Globing"
Ookaze Member since:
2005-11-14

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

Reply Score: 1

RE[7]: Shell Globing
by Vanders on Mon 20th Mar 2006 19:42 UTC in reply to "RE[5]: Shell Globing"
Vanders Member since:
2005-07-06

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

Reply Score: 2

RE[8]: Shell Globing
by Ookaze on Tue 21st Mar 2006 09:06 UTC in reply to "RE[7]: Shell Globing"
Ookaze Member since:
2005-11-14

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.

Reply Score: 1

RE[6]: Shell Globing
by Sheld on Mon 20th Mar 2006 19:54 UTC in reply to "RE[5]: Shell Globing"
Sheld Member since:
2005-12-21

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.

Reply Score: 1

RE[7]: Shell Globing
by Vanders on Mon 20th Mar 2006 20:59 UTC in reply to "RE[6]: Shell Globing"
Vanders Member since:
2005-07-06

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.

Reply Score: 2

RE[3]: Shell Globing
by SomeGuy on Mon 20th Mar 2006 17:21 UTC in reply to "RE[2]: Shell Globing"
SomeGuy Member since:
2006-03-20

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.

Reply Score: 1

RE[3]: Shell Globing
by bogomipz on Mon 20th Mar 2006 17:31 UTC in reply to "RE[2]: Shell Globing"
bogomipz Member since:
2005-07-11

Yeah, and such a command does actually exist. It's syntax is (from `man rename`):

rename .htm .html *.htm

Reply Score: 1

Amiga
by nii_ on Mon 20th Mar 2006 10:10 UTC
nii_
Member since:
2005-07-11

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.

Reply Score: 1

I like the guy
by Haicube on Mon 20th Mar 2006 11:27 UTC
Haicube
Member since:
2005-08-06

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?

Reply Score: 1

I don't like the guy
by Ookaze on Mon 20th Mar 2006 13:33 UTC in reply to "I like the guy"
Ookaze Member since:
2005-11-14

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.

Reply Score: 0

RE: I don't like the guy
by sappyvcv on Mon 20th Mar 2006 15:25 UTC in reply to "I don't like the guy"
sappyvcv Member since:
2005-07-06

Wow, the article totally went over your head.

Shame you get so defensive when he criticizes your pet OS.

Reply Score: 1

The guy is right.
by axilmar on Mon 20th Mar 2006 11:28 UTC
axilmar
Member since:
2006-03-20

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

Reply Score: 3

RE: The guy is right.
by morglum666 on Mon 20th Mar 2006 14:18 UTC in reply to "The guy is right."
morglum666 Member since:
2005-07-06

You should try working on a AS/400. Fits most of your laundry list ;)

Reply Score: 2

RE: The guy is right.
by Sphinx on Mon 20th Mar 2006 16:54 UTC in reply to "The guy is right."
Sphinx Member since:
2005-07-09

Wait, I think he's looking for PICK.

Reply Score: 1

I generally disagree...
by fithisux on Mon 20th Mar 2006 11:54 UTC
fithisux
Member since:
2006-01-22

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.

Reply Score: 1

RE
by Morin on Mon 20th Mar 2006 13:47 UTC
Morin
Member since:
2005-12-31

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

Reply Score: 4

positive point of view
by csousa on Mon 20th Mar 2006 14:16 UTC
csousa
Member since:
2006-02-04

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

Reply Score: 0

RE[2]: Shell Globing
by psnfiller on Mon 20th Mar 2006 14:39 UTC
psnfiller
Member since:
2006-03-20

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

Reply Score: 1

RE[3]: Shell Globing
by psnfiller on Mon 20th Mar 2006 14:59 UTC
psnfiller
Member since:
2006-03-20

psn@lupin:~$ which rename
/usr/bin/rename

You might not be the only with the same idea.

Reply Score: 1

Milo_Hoffman
Member since:
2005-07-06

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

Reply Score: 2

My user-friendly Unix
by JacobMunoz on Mon 20th Mar 2006 16:11 UTC
JacobMunoz
Member since:
2006-03-17

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!

Reply Score: 0

What is so wrong?
by estrabd on Mon 20th Mar 2006 16:32 UTC
estrabd
Member since:
2006-01-18

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?

Reply Score: 1

RE: What is so wrong?
by EliGottlieb on Mon 20th Mar 2006 17:58 UTC in reply to "What is so wrong?"
EliGottlieb Member since:
2005-10-30

What's wrong with it? Commenters lik erecting false dichotomies between Unix and MS, that's what!

Reply Score: 1

RE: The guy is right.
by schala on Mon 20th Mar 2006 19:02 UTC
schala
Member since:
2006-01-17

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.

Reply Score: 1

RE[2]: The guy is right.
by axilmar on Mon 20th Mar 2006 21:26 UTC in reply to "RE: The guy is right."
axilmar Member since:
2006-03-20

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

Reply Score: 2

anoying page...
by hobgoblin on Mon 20th Mar 2006 19:39 UTC
hobgoblin
Member since:
2005-07-06

1 part pr page, where the 5 first are about something that could have been coverd in one page...

Reply Score: 1

Wha?
by ma_d on Mon 20th Mar 2006 22:13 UTC
ma_d
Member since:
2005-06-29

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

Reply Score: 1

Shell picking
by acobar on Tue 21st Mar 2006 09:46 UTC
acobar
Member since:
2005-11-15

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.

Reply Score: 1