Linked by Thom Holwerda on Fri 25th May 2012 14:55 UTC
Thread beginning with comment 519602
To view parent comment, click here.
To read all comments associated with this story, please click here.
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[5]: Unix is beautiful because it's ugly
by zima on Sun 27th May 2012 20:53
in reply to "RE[4]: Unix is beautiful because it's ugly"
RE[6]: Unix is beautiful because it's ugly
by oinet on Mon 28th May 2012 15:51
in reply to "RE[5]: Unix is beautiful because it's ugly"
RE[5]: Unix is beautiful because it's ugly
by WorknMan on Mon 28th May 2012 00:48
in reply to "RE[4]: Unix is beautiful because it's ugly"
I know many people fear learning because it consumes their time, and they feel much more comfortable in their "just works" world. Until it stops working. Then they are helpless, having a black box that just doesn't work. And of course, they cannot diagnose problems, create workarounds or create something new. They can only consume what others have left for them.
Well, that's true for most things in life, yes? Since I am a 'computer guy', I can diagnose and fix most of my own issues, unless it is a hardware problem, in which case I usually take it to a repair shop, because I don't have the time nor patience to try and figure out which one of the hardware components is causing the machine to glitch or lock up.
But when it comes to cars, I don't know shit. If it breaks down, I pay a mechanic to fix it. Same with my washer and dryer, air conditioner, plumbing, television, etc. If I were a doctor, lawyer, etc, the computer would be just another appliance to me. Nothing wrong with that, really. A doctor may not know much about computers, but probably knows a hell of a lot more than we do about healing a sick person. It's just a different area of expertise. For this reason, nobody is 'better' than anybody else just because they know a lot about computers.
What exactly do you mean? What are you missing in particular? If it's just about that you don't like it - just don't use it. It is that simple.
What I'm missing is something that's intuitive. We both know how powerful Unix is, but why can't we have something with the power of Unix, with the added benefit of being able to sit down and use it right away, without having to know that if you want to run a command named 'foo' that's in the directory you're in, you have to type './foo'. The very fact that you had to sit and type out a lengthy explanation as to why Unix works the way it works is proof positive that we can do better than that. The way something works ought to be apparent by just looking at it. It shouldn't be necesary to comprehend 30-40 years of an operating system's history just to be able to use the f**king thing and understand the way it works.
All I'm saying is that Unix is a very powerful OS, but is about as intuitive to grasp as the Chinese alphabet.
RE[6]: Unix is beautiful because it's ugly
by Doc Pain on Mon 28th May 2012 04:05
in reply to "RE[5]: Unix is beautiful because it's ugly"
But when it comes to cars, I don't know shit. If it breaks down, I pay a mechanic to fix it. Same with my washer and dryer, air conditioner, plumbing, television, etc. If I were a doctor, lawyer, etc, the computer would be just another appliance to me. Nothing wrong with that, really. A doctor may not know much about computers, but probably knows a hell of a lot more than we do about healing a sick person. It's just a different area of expertise. For this reason, nobody is 'better' than anybody else just because they know a lot about computers.
I don't even try to claim that a UNIX guru is superior to other professionals per se. I just say that he grew up with the habit of learning, concluding, adopting, exploring, training and re-orienting than many other branches would have (which are quite static in knowledge). In terms of computers, the UNIX guru of course is superior to the lawyer to whom the PC is just a tool.
And that's what a computer with an operating system and application software is: a tool. So even the lawyer should try to treat is a such. To properly use a tool, you should at least know a bit of how it works and what you use it for. "Know your tools" may be a fully different knowledge for a lawyer than for a doctor. The lawyer will know how to retrieve his cases from the database, edit text, search for law content and references. The doctor will know how to access patient data, bring up x-ray images, magnify them or change contrast, administrate medicine or order tests. Both have a thing in common: They have a computer as an important tool.
To reply to your car analogy: If you're using your car as a tool, you don't need to know about all its inner workings. I say that's even impossible for a modern car because you're surrounded by "black boxes". Most of the stuff you cannot repair, or even remotely understand. But there are few things you need to know, and you even have to prove it: You need to be familiar with the pedals, the steering wheel, the dashboard. You have to know how to accellerate, brake, turn, shift gears and so on. You also need to know traffic rules: the funny signs and colorful lights, the speed limits and the precedence at a crossing. You even have to prove that you know them. Without that pre-knowledge, your car would be totally useless to you.
Again, the language analogy applies: It's not sufficient to know the letters of the cyrillic alphabet. A language is more. You need to know the words, the grammar, rules and uses. And you need experience. You will get it only by using the language.
What I'm missing is something that's intuitive. We both know how powerful Unix is, but why can't we have something with the power of Unix, with the added benefit of being able to sit down and use it right away, without having to know that if you want to run a command named 'foo' that's in the directory you're in, you have to type './foo'.
GUIs are the abstraction layer that provide this access. The limit the pre-knowledge to pointing and clicking, the mentality to "trial & error", which is not a big problem as you cannot break things easily (but you can, just try hard enough).
As I said, typing is the way UNIX gurus get their work done. It's faster, because it's more direct. Instead of selecting from a list of prepared possibilities ("show on the chart"), they form their commands directly ("build a sentence"). This implies that the language is known, otherwise any attempt would be futile.
Please try to understand the important difference of "foo" and "./foo". "foo" means: if we have a program "foo" in our $PATH which contains directories where execution of programs is allowed, run that program; if not, give an error message back (like "foo: Command not found."). "./foo" mean: if there's a command called "foo" in the current working directory (and nowhere else!), I intendedly command to execute that program because I know what I'm doing.
Just imagine some hacker compromizes your account, for example because you have a weak password. He cannot access system directories, but he can access your home directory. Therefore he will place "dummy programs" like ls, cp, cat or dd in your home directory. So if you routinely call them, you will call his programs instead of the ones you intend.
But there's also a positive effect of the ./ notation. Imagine you've downloaded the source of a program you've installed, but you did some modifications to it. You can then call "./program" or "~/src/foo/compile/program" directly which makes sure the modified version will be tested; if you run "program", just the one that is installed will be run, e. g. for reference.
The very fact that you had to sit and type out a lengthy explanation as to why Unix works the way it works is proof positive that we can do better than that.
There are two main concepts:
WYSIWYG: What you see is what you get. Emphasize: see. If you don't see it, you won't get it. Visual confirmation is highly important here, and the set of possible selections is limited. You can compare this to a baby that points to a thing and says "gah!" or "bah!" in order to acquire it.
YAFIYGI: You asked for it, you got it. You have to use the proper "language" to say what you want. The analogy here is that the baby has grown and adopted spoken language; it will no longer point and "gah!", but start with simple sentences like "Timmy ball!", and the more it learns, the more complex operations it can perform using language, like "Mommy, can you bring me the ball?" and so on.
You can clearly see that there is an evolutionary gap between the two concepts. This doesn't mean that mouse action in general is inferior to keyboard interaction. It isn't. The key to productivity is a good combination of both!
The way something works ought to be apparent by just looking at it.
So when the system presents a prompt, for example
bob@vs19:/home/bob/src/foo% _
you can already obtain information from it. But what else does it say? It says: "I'm ready for your commands. Go ahead and tell me what you want."
It shouldn't be necesary to comprehend 30-40 years of an operating system's history just to be able to use the f**king thing and understand the way it works.
You already answered your own question: "Understand the way it works": As long as you don't try that, you don't need any more knowledge than pointing and grunting. But compare it to your car: Want to fully understand how it works? You'll get your hands dirty, you'll learn a lot, and with every car generation, you can use a lot of pre-knowledge, but you also have to re-learn many things. That's what development and evolution is.
All I'm saying is that Unix is a very powerful OS, but is about as intuitive to grasp as the Chinese alphabet.
Tell that to a Chinese, saying that your native language is way superior to his and he should forget his stupid little drawings and learn it instead?
Depending on your individual education and knowledge, things look easy or hard. If your "IT career" started with UNIX stuff, you'll understand everything in UNIX being quite simple and logical, so this would be "easy stuff" in the end. If not, it might be overwhealming and not even understandable. Learning is the key. There is no other way to get access to and to employ technology that flexible, powerful and advanced. Sorry, I don't want to sound impolite, but it simply is that way. You cannot acquire UNIX guru skills without knowing your tools. I claim nearly anyone can, but one has to actually do it, learn it, practice it. It's not a matter of "PC on, brain off". There are many resources for help and learning, but you have to access them and use their input for your own thinking. As powerful as today's computers are, they don't free you from thinking on your own. They don't make a working brain obsolete.
Allow me to come back to the car analogy: If you can't figure out car, better don't touch it, or just f*ing learn.
RE[5]: Unix is beautiful because it's ugly
by moondevil on Mon 28th May 2012 10:39
in reply to "RE[4]: Unix is beautiful because it's ugly"
UNIX has always been about development. It started its life as a development system, not as a consumer platform. This heritage is even present in modern systems that come with development tools, compilers and debuggers, with means of looking inside the back box.
This is not true for commercial UNIX systems. Shortly after System V went commercial, GNU tools were the only way to get free compilers.
Try to get a free compiler for HP-UX, Aix or Solaris, from the compiler vendor, with an EULA that allows you to resell the software.




Member since:
2006-10-08
What do you mean by "access"? If you're going to read from or write to a file in the current working directory, no path needs to be specified. If you want to execute a file (a binary or a script) from the current working directory which is not part of $PATH (the search path for programs to execute), you need to prefix it with the ./ "here" path. This makes sure you don't run the "ls" binary some hacker left in your home directory by accident. :-)
The dot infront of a filename means it's a "hidden file". Files starting with . are not listed by ls by default, you need to use ls -a to see it. To be more generic, ".* is not part of *".
It seems you should read a little bit about UNIX history. In the older versions, /etc (having the meaning "et cetera") did not only contain files for system configuration as it does today, but it did also contain "additional binaries" such as /etc/mount or /etc/fsck.
Today, some people interpret /etc as "editable text configuration" which is what it is commonly used today on UNIX and Linux: Text files for configuration of the system, its services and additional software.
Again, you should read some history. Agreed that vi is not intended to be a "word processing typewriter", it's a powerful editor. Again my statement about language applies: You have to know how to operate it in order to make full use of its power.
Some UNIX and Linux systems have a different standard editor (even though they often ship vi in the basic distribution). $EDITOR or $VISUAL can be used to configure what editor should be invoked for programs that will open a file for editing (e. g. chsh).
Yes, and what's the problem?
The problem is that you are wrong. On some Linux systems, the 1st hard drive is named /dev/hda, yes. But some Linusi use sda. BSD uses ad0, da0 or0 ada0 for the same disk, depending on how it is attached to the system (and which driver grants access to it). OpenBSD did use /dev/wd0. On other UNIXes, it's just /dev/hd0. On Solaris, it's even "more complicated" like /dev/dsk/c0t0d0s0. Since disks usually use labels, there even is no need to deal with this "bare metal" kind of files. Just ignore what you don't need.
Not quite. Learning basic independently from their actual implementation is what makes a UNIX guru that powerful. He can use any system even though they are different. He has successfully learned how to deal with new situation, not being tied to strange concepts of how to do things. This flexibility is the result of learning. I know many people fear learning because it consumes their time, and they feel much more comfortable in their "just works" world. Until it stops working. Then they are helpless, having a black box that just doesn't work. And of course, they cannot diagnose problems, create workarounds or create something new. They can only consume what others have left for them. A UNIX guru can always create functionality he needs, and this is what he can do with the most limited tools. Because, you know, in worst case, when nothing works, you'll be happy for all that "ass-backward" stuff because it brings your data back, your system up and your company back into production.
UNIX has always been about development. It started its life as a development system, not as a consumer platform. This heritage is even present in modern systems that come with development tools, compilers and debuggers, with means of looking inside the back box. Free UNIX-derived systems even come with source code of all their parts. All parts of today's modern technology that consumers take for granted is somehow related to the beginnings. Do you know why the Internet works today? Because there's a lot of "old-fashioned" UNIX stuff (systems, concepts and philosophy) that keeps it running. This is not a short-term consideration as you typically see them in (home) consumer products.
What exactly do you mean? What are you missing in particular? If it's just about that you don't like it - just don't use it. It is that simple.
UNIX and Linux development has come a long way. But also recognize that much older stuff like mainframe technology or COBOL is still alive and kicking, especially in governmental use (where money doesn't matter). Could they do better? Sure! But why risk to break something that has proven to work? :-)