Post a Comment
Member since:
2005-11-23
Fans: 4
Member since:2005-06-28
Fans: 15
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.
Member since:2005-06-29
Fans: 5
Member since:2005-07-06
Fans: 2
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 ;-)
Member since:2006-03-21
Fans: 0
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.
Member since:
2005-07-06
Fans: 1
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)
Member since:2005-07-18
Fans: 5
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/
Member since:
2005-07-06
Fans: 0
Member since:2005-07-06
Fans: 3
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
Member since:2005-07-06
Fans: 0
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 
Member since:2005-12-21
Fans: 0
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.
Member since:2005-07-06
Fans: 3
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?
Member since:2005-11-14
Fans: 2
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.
Member since:2005-12-21
Fans: 0
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.
Member since:2006-03-20
Fans: 2
Member since:2005-07-11
Fans: 0
Member since:
2005-07-11
Fans: 0
Member since:
2005-08-06
Fans: 2
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?
Member since:2005-11-14
Fans: 2
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.
Member since:2005-07-06
Fans: 11
Member since:
2006-03-20
Fans: 0
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
Member since:2005-07-06
Fans: 1
Member since:2005-07-09
Fans: 12
Member since:
2006-01-22
Fans: 0
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.
Member since:
2005-12-31
Fans: 2
> 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.
Member since:
2006-02-04
Fans: 0
Member since:
2006-03-20
Fans: 0
"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.
Member since:
2006-03-20
Fans: 0
Member since:
2005-07-06
Fans: 0
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
Member since:
2006-03-17
Fans: 3
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!
Member since:
2006-01-18
Fans: 0
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?
Member since:2005-10-30
Fans: 0
Member since:
2006-01-17
Fans: 0
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.
Member since:2006-03-20
Fans: 0
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...
Member since:
2005-07-06
Fans: 0
Member since:
2005-06-29
Fans: 5
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 .
Member since:
2005-11-15
Fans: 0
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.
