Slashdot Mirror
How Ya Gonna Get 'Em Down On the UNIX Farm?
theodp writes "In 1919, Nora Bayes sang, "How ya gonna keep 'em down on the farm after they've seen Paree?" In 2013, discussing User Culture Versus Programmer Culture, CS Prof Philip Guo poses a similar question: 'How ya gonna get 'em down on UNIX after they've seen Spotify?' Convincing students from user culture to toss aside decades of advances in graphical user interfaces for a UNIX command line is a tough sell, Guo notes, and one that's made even more difficult when the instructors feel the advantages are self-evident. 'Just waving their arms and shouting "because, because UNIX!!!" isn't going to cut it,' he advises. Guo's tips for success? 'You need to gently introduce students to why these tools will eventually make them more productive in the long run,' Guo suggests, 'even though there is a steep learning curve at the outset. Start slow, be supportive along the way, and don't disparage the GUI-based tools that they are accustomed to using, no matter how limited you think those tools are. Bridge the two cultures.'" Required reading.
Not everyone cares.
Those who do, while learn the power of the command line, just like myself and many others. Those who don't, will be happy with the guy.
THATS FINE. STOP TRYING TO CHANGE THAT.
Not EVERYONE needs to be a sysadmin or developer. Some people do stuff other than dick with computers 24/7 so knowing how to use awk is a waste of time, just like I doubt too many of you guys know how to milk a cow (even just hook one up to the milker which is pretty much automatic today).
Different tools for different jobs. Not all of us need a freaking hammer.
-BitZtream
People - the Unix-likes advanced far beyond command-line utilities ages ago.
System administrators rely on command line utilities, on all platforms. That isn't a Unix-specific thing. Windows administrators do the same thing.
"Windows is like the faint smell of piss in a subway: it's there, and there's nothing you can do about it." - Charlie Br
I wonder how much of his advice actually works? People who like using CLI seem to be cut from a different cloth than people who fawn over glitsy GUI interfaces. That's been my observation, anyway. Some newbies just gravitate toward the alluring green-text-on-black-background cli that seems to hold the promise of a deeper computing experience. They tend to find it. :)
It's easier to shoot yourself in the foot with the command line. A wrong character at some position might cause a lot of unexpected behavior and leave a good mess to clean. Just offering a counter-argument for the sake of discussion.
They can learn the command line the same way people 40 years ago learned command line.
Put those students on a system that can only do command line, and require them to do things. Problem solved.
Don't pander to lazy, unmotivated fucks. we don't need any more windoze weenors trying to develop systems that run on real computers. half the java developers at my employer are totally useless and cause downtime because of their ignorance of posix systems
>> so wholly lacking in the functionality of a UNIX shell
That's why I use the GnuWin32 http://gnuwin32.sourceforge.net/ tools: basically your standard Unix utility set on Windows.
Essentially this.
I had a prof who would do all his lectures & demos from the command line.
Need to write a short C program to demonstrate forking? Boom! Into vim and coding up a basic example in a minute or two.
Typo in his LaTeX slides? Boom! Switch over to fix it, then recompile the slides, and on with the lecture.
Student asks a question about a command line argument? Boom! Man pages up on the big screen.
It was a little intimidating to see this CLI master hopping around typing crazy little combinations of letters and making magic appear on the screen, but at the same time it was inspiring. It was an example of what we could aspire towards.
For casual users, anything with a steep learning curve (no matter how powerful) is a tough sell because they'll probably spend more time learning than they would save. Trying to evangelize them may be morally satisfying; but is largely pointless.
For people who actually want to do something computer related, at scale, surely anybody sharp enough to be left unsupervised near a computer will learn (the hard way, if necessary) why we use tools with steep learning curves and great power: because the alternative is an essentially unbounded amount of error-prone manual labor.
If that doesn't become clear to them fairly quickly, either the GUI tools are working just fine for them, or they aren't in an area where the CLI really shines, or they should really consider doing something else. You shouldn't need to turn on the hard sell.
Choices of specific tools, with their quirks dating back to design constraints or decisions made, in some cases, before today's students were born are largely a matter of taste; but the use of tricky but high-powered tools swiftly shows itself to be necessary. You just can't click fast enough, even if you wanted to.
GUIs tend to suck at automation because all GUIs tend to assume that end users are blithering morons.
The problem with a GUI is that there may not be a "fully functional interface". It may simply not exist yet. Creating one by stringing together tools in a good shell is a lot easier and quicker than building a full blown GUI app.
Do more than one of something then a command line or programming environment will likely benefit you if you aren't interested in endless busy work.
A Pirate and a Puritan look the same on a balance sheet.
It took me a minute to realize the author thinks gui interfaces are Gay Paree and the command line is back on the farm. In my experience it's the other way around - once the kids have discovered the flexibility and utility of the command line it's a bit hard to keep them in the walled garden of gui interfaces.
Any gui is absolutely great as long as a) the task you're trying to do with it is one the programmer/designer has anticipated; and b) the programmer has done a decent job. As soon as you're trying to do something that a gui designer hasn't though of, it suddenly becomes difficult or impossible to get anything done, whereas you can usually work out a way to do it using the multiple small pipeable tools available in your average shell.
I shit you not: this morning, one of my neck beard coworkers did a command-line sql query ('select * from table') piped through cut, sort, and uniq. Because, hey, 'distinct columns, i, actually, want' and 'order by column' is too much work.
The point is, the best tool for the best job. Sometimes that's the command line, sometimes it's a text editor with regular expressions, and sometimes it's spotify.
Do you even lift?
These aren't the 'roids you're looking for.
In many ways the GUI system of icons is similar to the pictograph system of ancient Mesopotamia. You have one symbol for everything you want to express. The Phoenicians had a much better idea, an alphabet. You have a finite number of letters and an infinite number of words and sentences (I believe I'm quoting Noam Chomsky on the infinite part).
If you are limited to commands that contain only five lower case letters, then the number of possible commands is something like 26 to the power 5 which is over 10 million. It would be difficult to navigate through that many icons. The point-and-click method of using icons is just not as efficient as an alphabet with letters that make up words that make up a language.
Expose them all in a mandatory fashion. Those that have real potential will see the superiority of the command line. Many will not, but are no big loss. (If you can, fail them permanently later.) Incidentally, the same works with C programming.
No, the problem is not the there are not enough programmers or software engineers. The problem is that there are far too many bad ones. Get rid of those and the good ones could not only implement everything that needs implementing, they could also do it a lot better.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
Don't just explain it, give them jobs where the command line works. For instance, automating builds. All developers will need to build the software they write. Give the students the task of automating their builds. Note that this means truly automated: it has to happen with no human interaction, not even to start the build. If it can't be set to automatically check out the latest code and run the build at 2AM without a user being up to trigger it, they haven't completed the assignment. Include jobs like generating necessary Web service support code from service definitions (which will run them up against the problem that there are no GUI tools to do this in the Windows/VisualStudio environment, it's all command-line tools and they aren't integrated into VS). Once they've gotten their heads around that, hand them complex automated maintenance jobs like "Find or create a program to identify images with a specific bit of metadata in them. Now, create a process to automatically scan all newly-uploaded files and move any that contain that metadata to a location under a "bad file" location matching their location under the "new uploads" location.".
Long and short, don't explain to students why the Unix command-line environment's better than a GUI. Give them real-world jobs that're necessary for what they're doing that demonstrate how it's easier to do all this from the command line than via a GUI.
If you truly want to be nasty, give them an assignment to get in and repair and restart a Web server that's broken because of a damaged config file. They must do this from their smartphone or laptop, from a remote connection (hotel WiFi or somesuch, they're out of the office and this is an emergency), with no remote-desktop access directly available (you can have a VPN available which would let them RDC in if it were working, but if their device isn't already set up for it there's nobody in the office who can help them get it set up and turned on so they're on their own). All they have is SSH access if it's Unix servers.
I wish I could comment directly on the original article. Here's what I'd say:
If computer science students are unwilling to learn something, then fail them. End of story.
Not everything is exciting and flashy. Should we refrain from teaching the multiplication table because we have calculators now to do it for us? Any CS graduate who hasn't worked with the CLI during his/her studies is simply not worth hiring and indeed should not be permitted to graduate.
The problem isn't the capabilities of Unix, it's never been about that. The problem has always been about the usability of Unix from the average Joe's perspective. The fact that new users are typically told to RTFM and met with hostility certainly hurts the cause. It wasn't any different with DOS, it was a command line OS that was so counter-intuitive to learn that it spawned the entire 'For Dummies" series of books. By the time Windows 95 came out and put a useful GUI on DOS it was such a big deal that people lined up outside the stores at midnight just to buy it.
Steve Jobs understood this and worked ruthlessly to make Mac OS easy to use regardless of the back end. Nowadays you have the argument that Android and Mac OS/iOS are out there an extremely popular, but again they are simply GUI shells to the back-end that hide everything. Cisco routers and switches also have GUI's that will happily hide everything that was previously done by a command line. Really, the bottom line is that unless your in certain fields in IT or a programmer you don't have anything to gain by playing with command line. I grew up on the command line, I have spent decades with it, but I can't justify it to anyone just because I went through it.
Time's change, I remember supporting Novell Netware 2.x and 3.x and Token Ring, but I'm not about to suggest anyone spend time learning Netware or Token Ring either. I've had these conversations with people new to the field, they don't see the point, they just see a GUI to learn and buttons to click. The OS itself doesn't make a damn bit of difference, they don't want anything to do with a command line.
In Unixland the answer is pipes. You can quickly teach them to do things that typical stand alone programs won't do, or won't do easily using simple programs linked together by pipes. It is a form of linking the two paradigms while moving them closer to actual programming, especially since some of the tools you can link with pipes are programmable (awk, sed, perl, etc.). Once they know how to perform actions from the command line it is a trivial step to put them into a shell script - real programming with a scripting language.
much of left-wing thought is a kind of playing with fire by people who don't even know that fire is hot - George Orwell
We are talking about CS students the CLI is very important piece for them to learn as those basic commands stay the same {or mostly the same} where as there are many GUIs for the same thing. I can teach you about the CLI and it will be there but I can't guarantee that everywhere you work and every system you use will have that specific GUI installed.
When you settle into a new job, understand all those basics learned from the CLI, and you open up a GUI you have never seen before {unless it is poorly designed} you will understand what those buttons are for.
Any dumbass can do stuff in a GUI, but real BAMFs rock a terminal.
I think nearly all experienced professionals would simply say that both types of tools have their place.
I spend 99% or more of my time on the job working in a bash shell. But if you're talking about a new piece of software that I've never configured before, and probably will never have to again, then pop up the GUI, set the options, and move on with my day.
That said, while a CLI does have a much steeper learning curve, it is far more powerful in most cases. I don't avoid GUI tools out of some sort of "elitist" mentality, I avoid them simply because they're so limiting.
The original MacOS had it right - there was no command line at all, at any level. The mechanism for manipulating the system at a low level was ResEdit, a tool for editing the resource fork of files. It was a GUI tool, not a command line. If you wanted to set the color of something, you used a color picker; you didn't write RGB in hex. This was an effective way to do the job.
Unfortunately, the original MacOS sucked as an OS - no processes, no threads, no memory protection. The designers had to do that to cram it into 128K of RAM, but it didn't scale. On top of that, the Mac's "Resource Manager", which was really a little database system, was an unstable database. A crash while the resource fork was open for writing usually resulted in a corrupted resource fork. This gave the resource fork approach a bad reputation. In reality, the problem was that it was designed for floppies, where writes were so slow that keeping the resource fork in sync was too expensive.
Then, when Apple needed Steve Jobs back, they had to buy his NeXt failure for $400M, so they ended up using NeXt's warmed-over BSD/Mach kludge. So they got all the obsolete UNIX command line crap back. They also lost the Mac file system with its resource forks.
In the Linux world, the legacy command line crap is stacked so deep that nothing can be fixed. Many things that should be databases are text files. So there are stil lock files, sending signals to processes to tell them to reread their text file, and similar legacies of the bell-bottom-trousers 1970s.
There's also a pernicious tradition in Linux that GUI tools need not be comprehensive. It's OK to have a GUI tool that doesn't let you do everything you can from the command line. Linux GUI tools tend to be dumbed down, and often don't know what they did - they just display text messages from a lower level in a text box. On the original Mac, that was an absolute no-no. Programs couldn't even use print statements.
In the Beginning was the Command Line
by Neal Stephenson
About twenty years ago Jobs and Wozniak, the founders of Apple, came up with the very strange idea of selling information processing machines for use in the home. The business took off, and its founders made a lot of money and received the credit they deserved for being daring visionaries. But around the same time, Bill Gates and Paul Allen came up with an idea even stranger and more fantastical: selling computer operating systems. This was much weirder than the idea of Jobs and Wozniak. A computer at least had some sort of physical reality to it. It came in a box, you could open it up and plug it in and watch lights blink. An operating system had no tangible incarnation at all. It arrived on a disk, of course, but the disk was, in effect, nothing more than the box that the OS came in. The product itself was a very long string of ones and zeroes that, when properly installed and coddled, gave you the ability to manipulate other very long strings of ones and zeroes. Even those few who actually understood what a computer operating system was were apt to think of it as a fantastically arcane engineering prodigy, like a breeder reactor or a U-2 spy plane, and not something that could ever be (in the parlance of high-tech) "productized."
Yet now the company that Gates and Allen founded is selling operating systems like Gillette sells razor blades. New releases of operating systems are launched as if they were Hollywood blockbusters, with celebrity endorsements, talk show appearances, and world tours. The market for them is vast enough that people worry about whether it has been monopolized by one company. Even the least technically-minded people in our society now have at least a hazy idea of what operating systems do; what is more, they have strong opinions about their relative merits. It is commonly understood, even by technically unsophisticated computer users, that if you have a piece of software that works on your Macintosh, and you move it over onto a Windows machine, it will not run. That this would, in fact, be a laughable and idiotic mistake, like nailing horseshoes to the tires of a Buick.
A person who went into a coma before Microsoft was founded, and woke up now, could pick up this morning's New York Times and understand everything in it--almost:
Item: the richest man in the world made his fortune from-what? Railways? Shipping? Oil? No, operating systems. Item: the Department of Justice is tackling Microsoft's supposed OS monopoly with legal tools that were invented to restrain the power of Nineteenth-Century robber barons. Item: a woman friend of mine recently told me that she'd broken off a (hitherto) stimulating exchange of e-mail with a young man. At first he had seemed like such an intelligent and interesting guy, she said, but then "he started going all PC-versus-Mac on me."
What the hell is going on here? And does the operating system business have a future, or only a past? Here is my view, which is entirely subjective; but since I have spent a fair amount of time not only using, but programming, Macintoshes, Windows machines, Linux boxes and the BeOS, perhaps it is not so ill-informed as to be completely worthless. This is a subjective essay, more review than research paper, and so it might seem unfair or biased compared to the technical reviews you can find in PC magazines. But ever since the Mac came out, our operating systems have been based on metaphors, and anything with metaphors in it is fair game as far as I'm concerned.
MGBs, TANKS, AND BATMOBILES
Around the time that Jobs, Wozniak, Gates, and Allen were dreaming up these unlikely schemes, I was a teenager living in Ames, Iowa. One of my friends' dads had an old MGB sports car rusting away in his garage. Sometimes he would actually manage to get it running and then he would take us for a spin around the block, with a memorable look of wild youthful exhiliration on his face; to his worried passengers, he was a madman, stalling and backfiring
"Windows is like the faint smell of piss in a subway: it's there, and there's nothing you can do about it." - Charlie Br
I think the description "GUI's are not fully funtional yet" summarizes the situation. Even Microsoft eventually went back to the command line. At one point, almost all of Microsoft's tools used the Windows GUI interfaces. It quickly became obvious that the GUI interfaces didn't support remote deployment, automation, etc. Then they wrote power shell, and gave all their tools command line interfaces again.
Programs like LabView, and some of the process control (DCS) and programmable logic control (PLC) vendors have graphical programming interfaces. PLC Ladder Logic is probably the most basic visual programming metaphor ever developed, because the relay ladder logic corresponds to simple boolean AND/OR operations. The LabView interface is more fully featured. However, it takes a very big picture in LabView to accomplish the work of a simple procedural function in most programming languages. I couldn't imagine doing a sophisticated program with that interface. PLC ladder logic looks dense in comparison to the picture based function blocks of LabView.
Additionally, I have frequently found myself modifying VisualBasic Forms and VisualC++ Resource Files at the source level instead of using the graphical interface, because the change I am trying to accomplish can be done much faster from source than from the GUI. It really makes me think that GUI interfaces are missing a fundamental level of programmability.
Any dumbass can do stuff in a GUI, but real BAMFs rock a terminal.
I've always thought of it as the difference between watching TV and reading a book. Try doing this with a GUI:
less `find . -type f -exec grep -il "useful information" {} \;`
Have you read my blog lately?
HTML presents a graphical first environment that humans can come in to an enrich with code: declare your content, then orchestrate and manipulate that media via an API for the media.
HTML+DOM is awesome in that it's media-first, API second. The DOM is verbose, certainly, but it gives a much richer, more tangible surface than a standard library that is strings, vectors, ints, floats: so, we can get good at this platform without programming (HTML) and the DOM standard library, for when we do want to start programming/manipulating things, is a rich-media standard library as opposed to a primitive one.
No. Argument ad homenium is not needed.
It's got nothing to do with the arrogance or competence of the builders. GUIs tend to suck at automation because of the assumption that each interface, when presented, shall be manipulated by a human. This assumption is a reasonable one, and destroys automation before you start - the best you can hope for is applying the presented default after a timeout period, which makes for exceptionally slow progress. Automation that needs constant human intervention is (and I'll be kind here) not automation.
If opportunity came disguised as temptation, one knock would be enough.
3^2 * 67^1 * 977^1
Well, sure, but what about when you first started getting into computers?
Um, there really weren't any GUIs back then...
and yet his description is closer to technical truth than your ad hominem attack.. who's the uneducated one?
You can get your students to the Unix farm by challenging them to do simple tasks in a GUI while you perform those tasks on the command line. After you perform those tasks way faster than they ever could, reveal the command(s) you used to perform the task. Keep the tasks and commands relatively simple so as not to overwhelm them. Then towards the end of the demonstration (after you have their attention), give them one task that will blow their minds when they see how quickly it can be done on the command line. In order for the students to presume that your competition is fair, avoid using scripts and type all of the commands manually. Once they see how much faster you can perform these tasks, tell them about Linux or Cygwin and let them take it from there. Some students will stubbornly continue to use the GUI, but the motivated ones will learn it on their own.
You start them with the pure point-and-clicky GUI they already know, then show them scripting tools like in Adobe's apps and and Apple's OS that allow them to automate those points and clicks, then show them how those actions can be customized after the fact, then get down into how those actions are coded, and how code can be combined and reassembled to do other things, and with enough iterations of this process, you've got them writing bash scripts.
http://alternatives.rzero.com/
I'm going to have to argue this, as it depends on the user. In 2005 I made the switch from 9 years of Linux to full-time OSX. While it is true that I took full advantage of the GUI interface features and used a lot of (really great) OSX only software, due to my background in Linux, I spent over 50% of my time in a terminal or running Open Source software in X Windows (yes, OS X comes with X) In that respect I took full advantage of it as a robust BSD system. If you want to call OSX out as being different from all the other "Unixen" your going to have to go a step further and point out how very different Linux is from FreeBSD - and they are very different. A Unix based system is a Unix based system. There is nothing more complicated about it. Also, since I used OSX for all of it's Unixy goodness, recently transitioning back to Linux and FreeBSD full time was painless, especially since Open Source software has caught up so much.
Brought to you by Carl's Junior.
It's the MS Windows8 way now isn't it? That's how people seem to be justifying the new GUI anyway.
When someone wants to do something on thousands of files or even something repetitive within just one file (replacing all numerical dates with European numerical dates or written dates), then showing them some command line basics can light a fire under them. Until they have a need though, they usually won't care enough to learn further themselves.
This I absolutely agree with. It is critical to understand how we got to where we are. I also am not saying there aren't times a command line is better. My point is much the same as yours. Technology evolves and improves. Early versions of things are much more limited than later versions. CLI predates the GUI and so it was much, much better than early GUIs (and a well designed CLI is still better than a poorly designed GUI), however there are many, many cases where a well developed GUI can exceed the usefulness of a CLI, yet many UNIX aficionados are stuck in their CLI ways and don't bother to find the good GUI tools or learn to use them.
Maybe this is because developers in Linux assume that low level stuff will be done with a CLI, so they don't write GUI functionality that can handle it, and thus it becomes self fulfilling in the realm that most CLI fans spend there time. There are also certain situations like repeatable installations where scriptable systems are ideal, though in some cases, GUIs even exist to do some of that stuff. You still have to understand how the GUI accomplishes what it is doing though if you want to understand why it works the way it does and want to be able to use it properly.
Ease of technology is not an excuse to not understand how and why it works, at least for those who want to actually build it. The same also goes for any other field.
AJ Henderson