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
Each user is coming in with a set of experiences that has conditioned them to prefer one way over the other. Someone who has used a CLI a lot may simply prefer it because they are familiar with it and can do things quickly vs. learning a new way to do things with a GUI. They are predisposed to think their way is better; just as a GUI user is towards their preferred interface. to that end:
1. Don't assume that the CLI is always better, even if you can do something faster or easier. If the GUI gets the job done without frustrating the student or taking a long time, let them use the GUI.
2. For instances where the CLI is clearly a better choice; have them use both and let them draw their own conclusions.
In the end, unless one way causes a lot of extra work or cannot accomplish the task neither is inherently better; just different ways to do the same thing.
I'm a consultant - I convert gibberish into cash-flow.
Any dumbass can do stuff in a GUI, but real BAMFs rock a terminal.
At least, that's how it was sold to me when I was a young'in. Worked pretty well, too.
An enigma, wrapped in a riddle, shrouded in bacon and cheese
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. :)
Read Neal Stephenson's In the beginning was the Command Line, or, better yet, give it as a set book to the students. It's available for download from his website for free, or you can buy it as a paperback from all good booksellers (and some bad ones)
I'm old enough to remember when discussions on Slashdot were well informed.
It's better to know the niche market, because less competition.
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.
First, ask them to look up how to do some esoteric thing via the GUI and then do by following the long directions - open panel, go to menu, get dialog, go to tab, click on option, get another dialog, blah, blah, blah , etc .....
Then the command line version: copy paste command into terminal - enter. Done!
In my professional experience I have observed two types of people in various IT roles. The first group is the highly technical, analytical, command-line folks. The second group is mostly point-and-click user support and administration folks. Both groups are necessary in any moderate sized information system environment. Personally, given the choice between command-line versus GUI applications/tools I favour command-line because I am exceedingly productive without the distractions present within GUI environments. The only time I expect my colleagues to be proficient at the command-line is when working in a *nix environment. But again some people do not belong anywhere near a command prompt so there are tools available for them. Granted my first exposure to computers was in the early 1980s with Commodore PET BASIC and 6502 assembly language followed later by numerous languages and operating systems including GW-BASIC, FORTRAN, WATFIV, iAPx86 assembly language, PERL, BASH, Korn Shell, et. al.
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.
Why would they use Spotify in their studies or their work?
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.
>> Convincing students from user culture to toss aside decades of advances in graphical user interfaces for a UNIX command line is a tough sell
BS. Simply point out that GUI-only IT grunts are being replaced by the truckload by cheap Indian and Chinese labor (and why not) while those who have specialized in security, automation, programming and other areas that require you to use a keyboard continue to make top dollar and find interesting work even in this crappy economy...and I think you'll make your case.
(Or...just point out that "decades of GUI advances" led us into the Windows 8 ditch - your choice.)
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.
If they don't need it, why should they use it? A tool has no value in it self.
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.
[QUOTE]
When I volunteered to help teach programming to a group of librarians earlier this year (read Teaching Librarians Programming for details), I witnessed this cultural schism firsthand.
{/QUOTE]
The first and most important question in my head was "Why do librarians need to learn about computer programming?" The article failed to expain the context of the situation which gave rise to the perceived need to conduct a training session for the librarians. There might have been a legitimate job-related benefit yet it was left unstated.
The remainder of the article stated obvious differences in the mindset of computer programmers versus application/tool users. However, most of the examples cold have been illustrated at the command prompt if a suitable text-based application was available. We have plenty of console-based music player applications to choose from in the various *nixes to pick on Spotify for a moment. I understand the intent of the article but the underlying premise is about as insightful as a debate over the reasons some people prefer black pepper versus salt on their food.
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.
Another issue with Linux adoption is packaging and backward compatibility. I tried to install an older version of Capistrano (the current version is not backward compatible and I didn't want to re-write the scripts) under CYGWIN. It would not work with the newest version of Ruby because Ruby is not backward compatible (the compatibility issue) and I couldn't find a older ruby binary for CYGWIN. Sure I could have compiled it but I just want to use it not be a Ruby developer. If you are not using the latest version there are too many dependency and compatibility issues.
The other issue is that command line requires remembering a lot of esoteric commands. I would rather concentrate on creating software than remembering the difference between "git -push" and "git -commit". Also, since I use Eclipse it is an extra step to get out of eclipse to go to a command line and enter a command rather than just click a few times. If I am in a GUI I want to stay in it.
To those who say "You can do everything you want on command line" I say "You dig a canal with a teaspoon too but I wouldn't want to do that either". Command line has it's place for some things and GUIs others.
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
Already Done - it's called "KATE" and is part of KDE. You have a console right there when you want it and minimized when you don't need it and it's been part of KDE since v:3 days
Provide an outstanding GUI with an outstanding migration to the command line.
Stop being arrogant.
Mastering the command line is not necessary if all you care about are are average (read: bad) skills at software creation and system management. The GUI is _not_ a step forward. It is a slow, inflexible crutch for the incompetent (of which there are many). Being incompetent is perfectly fine for ordinary users and GUIs are for them. IT professionals have no such excuse.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
'You need to gently introduce students to why these tools will eventually make them more productive in the long run
Or, you could just, you know, fucking prove it scientifically if you're so sure of yourself instead of relying on your l33ter-than-thou attitude to show me the error of my ways. I use an IDE and my salary is the exact same as my VIM-obsessed coworkers.
The smart ones who have a propensity for it will "get it" and gravitate towards it, just like the always have. Many, or maybe even most, programmers (at least back end) are going to interact with a UNIX like environment at some point.
Does the professor teach his students by giving verbal and written instruction or does he do it in the form of interpretive dance?
The challenge of Computer Science is managing, modelling and directing complexity. GUIs do that in one way; command line interfaces do that in another. You teach students how to deal with complexity and their ability to do that - the maximal level of complexity that they can manage - determines their potential as a Computer Scientist (programming being a subset thereof)
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.
When I volunteered to help teach programming to a group of librarians earlier this year, [a two day boot camp] I witnessed this cultural schism firsthand.
The 35 students all came from user culture, whereas the 6 instructors all came from programmer culture.
Note that by ''programmer culture,'' I mean a UNIX-style programmer culture. There are lots of programmers who work completely within proprietary IDEs (e.g., Matlab, Xcode, MS Visual Studio) with specialized workflows for version control, rich searching, and task automation. However, the high-quality, widely-available free software that is most likely to get beginners hooked on programming --- to turn users into programmers --- are almost always written in a UNIX style. That's why my article focuses on this culture.
Explain to me again why the novice or casual programmer or the working professional in other fields would not be more comfortable, engaged and productive using a modern IDE outside the UNIX culture?
You could hate free software development tools available for the *NIX environment and not make a better case against them.
If he wants them to get out of the world of the Graphical User Interface into the Command Line Interface, Professor Guo (which looks and sounds like GUI) should set an example and change his name to Cli.
Speaking of the command line, I have never seen a terminal emulator which mimics the smooth scroll effect of some of the hardware terminals. Have you seen such?
Linux and Mac need this. :) I would create it myself, but am too occupied with other stuff (like lethargically reading Slashdot) and probably would be too stupid to do it anyway.
But if someone needs an open source project.
I first learned Unix in school from a classic GUI-hating Unix veteran, and my line of thought was typical of anyone who had grown up on DOS and Windows. "What a pain. This is so archaic. Why do I have to bother with this?" Eventually, though, it started to fascinate me. It was like I was truly learning to use a computer for the first time. Maybe it was just the geeky hacker feel of scrolling white text on a black background. When I was taking Windows Server courses a couple semesters later, I was really beginning to miss the simple flexibility of a command prompt; now that I had experienced the alternative of pumping a mouse cursor through an endless torrent of snap-ins and pop-up menus. When I first started tinkering with various Linux distros around the same time, there was no turning back. I still had a graphical interface which a lot of things obviously require, but any time I needed to I could open a terminal and interact with the system directly. I was enthusiastic about Powershell when it first came around, but got turned off of it pretty quick. Even if MS didn't change the freaking syntax with every service pack, it just isn't the same.
Well... comics have been around almost as long as written text, yet still books are written. The Nobel price for literature has yet to fall on a comics author. Both formats can bring across ideas and stories, yet most readers still seem to prefer written, sparsely or non-illustrated stories over comic novels.
--frank[at]unternet.org
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
It's easier to shoot yourself in the foot with the command line.
That is the fundamental reason why no one but the hobbyist or professional has ever been comfortable working in a command line.
don't disparage the GUI-based tools that they are accustomed to using, no matter how limited you think those tools are.
Or else they can simply point out those limitations.
After all, those limitations are key motivations for using command-line tools.
It's possible to discuss the limitations of something without disparaging it.
Software Productivity is why GUI Development Tools are here to stay!
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.
You're comparing a Unix shell to Powershell applications, not Powershell itself. Did you notice the VMWare VSphere GUI client is only on Windows, too? I'm not surprised they have supplemental Powershell scripts/programs to interact with VMWare hosts considering they don't offer *any* management utilities at all to Unix/Linux users.
Bad analogy from a bad admin.
Your education shows a complete lack of understanding. (DWE==dick with ears)
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.
Apple and it's fanboys will only acknowledge the Unix underpinnings of MacOS when they need a marketing bulletpoint or want to win a pointless argument with a total stranger.
Beyond that, MacOS is all about it's own thing completely separate and distinct from all of the other Unixen. It has always been it's own thing, even before the bolted all of the visible parts onto something else.
If you care about the Unix-y bits, you are just as likely to be completely unimpressed by the rest.
A Pirate and a Puritan look the same on a balance sheet.
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
I feel like I have to turn in my geek card for using that terminology, but its still the best way to describe it. In the end, the culture, the environment, it all doesn't matter as long as you can do what you want to do in the best way.
For programming/CS, its pretty easy. Lately, all the best stuff is coming out for Unix, which, for almost a decade, was debatable. Some people liked developing under Unix, but not everyone. Say what you will, but VB6 drove a lot back in its days, and .NET has a significant mind share. For a long time, SVN's client TortoiseSVN was what a lot of people used.
Now, with SVN blowing up in everyone's face, and with Github becoming a de facto standard, many are turning to git. And git, while it has a few interesting UIs, simply blows on Windows. I got it to work the way I liked, but it took a lot of Powershell black magic and reverse engineering some of the Unix tools, and even then its significantly slower than it is on Unix for extremely large projects (it shouldn't be used that way, you should split your repos in smaller ones, but when making the transition from SVN its not always possible).
Then you have tools like Grunt/Node that are becoming standard...they work GREAT on Windows. They work better on Unix. Even though I'm in a Windows shop, half of the devs work on Macs to have the Unix ecosystem without having any issues integrating in the existing Windows environment.
So that will take care of developers all in due time on its own. For normal users? Thats trickier. But it will always be about the apps...and now that everyone does everything in a browser, making people care about whats behind will always be a tricky one.
Driving Instructor Philip Guo poses a similar question: 'How ya gonna get 'em down on a manual transmission after they've used a slush-box?' Convincing driving students from automatic culture to toss aside decades of advances in transmissions for a stick shift 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 RACECAR!!!" 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 automatic transmissions that they are accustomed to using, no matter how limited you think those tools are. Bridge the two cultures.'"
I an disturbed by just how few words I had to change there.
#naabhaprzrag, #sverubfr-000, #agi-fcbafberq, negvpyr[pynff*=' negvpyr-ary-'] { qvfcynl: abar !vzcbegnag; }
This is just all funny.
As an old, crusty unix guy, I think I can fairly confidently say that the death of Unix has been predicted since about 5 minutes after K&R.
In other news, the Internet will die, any day now. Wait for it. Remember how it was going to be AOL?
You can't kill my tools. Linux is annoying in a lot of ways, but it is good enough. And sure as hell beat Solaris.
Or the computer programs you.
and yet his description is closer to technical truth than your ad hominem attack.. who's the uneducated one?
If you want them to learn the CLI. Make them learn it. If they refuse, then they fail. What's the problem? Required learning is not up for debate among students, or at least I don't think it should be.
But if you make them learn it, be honest about it. Personally, I find GUI's to better for simple, non-repetitive tasks. If I need to automate something, or do something fairly complicated with my system I immediately bring up my terminal (but really, that's just my preference). I don't think one is inherently better and offers so many advantages and insights into a system, that an admin learns to plumb the depths of their OS. You can do some pretty cool stuff at in the *nix command line and you really have no clue about how the system really works - especially if the system is in terms of the kernel interfaces. Trying to develop/push CLI tools that completely overthrow all equivalent GUI tools is silly - there is no point. Sometimes the GUI is simply far more effective.
That being said, I think it is extremely important that young developers have to fully run through at least 1-2 project(s) early on, using only the CLI (editor withstanding). I have noticed that people who do have solid CLI experience are much better developers (note: this has nothing to do with innate capability).
If a dev has spent time significant time in the CLI then I can count on at least the following: ...
-then they understand the difference between a thread and a process - because they read about a pipe.
-they understand that OS processes/threads send signals to each other and react to them.
-they know what a build system is, and that a good one should be appreciated.
-they understand a development toolchain; what an object file is; what a linker script is; etc etc.
-they know what SSH is.
-they know, beyond any shadow of a doubt, that applications should have some sort of logging mechanism.
-etc
Silly stuff, I know. But its amazing how many do not know *any* of the above! Seriously, there is an entire army of dev's out there who know nothing of any of this. If you ask them to operate/do their job without Visual Studio/IntelliJ/etc they are dead in the water. They cannot do it - and it's not that they just don't know the commands. They fundamentally don't know how any of this stuff works, or that it even existed.
I don't think preferring a GUI precludes anyone from learning this stuff - its just it doesn't throw it your face the way a CLI does. As such, if I know a dev has solid CLI experience - I can count on at least some baseline of knowledge. In my experience, that is simply not true for someone who is, and always has been, completely GUI driven.
If we ever live in a world where application programmers have already done everything that needs to be done, then I'll believe "programmer culture" has become obsolete.
It's already painfully obvious, that we're not even headed in that direction, much less that it's happening any time soon.
I am a programmer and a user, but it's nearly routine that I encounter problems where if writing an awk script weren't an option, then my answer to a problem would be "I can't do it. My tools aren't flexible enough. I fail."
Keep in mind that "do it" is sometimes defined as working within a constraint, or being efficient. Let me give you two examples, one where things go great, and one where they don't.
My girlfriend browses IMDB on her Android smartphone. There's a plugin, where any time she's looking at a movie, she can just touch the screen in a certain way, and a few seconds a certain tool on the home server does some searches and begins to download. A little while later, she can watch the movie. No "programmer culture" needed, because some applications programmer(s!) already identified and solved the problems. "User culture" succeeds -- built upon programmer culture while trying to remain blissfully ignorant of the fact that the tools didn't write themselves.
She also sees that a certain TV series is returning in a few weeks, and decides we'll re-watch the previous season, to remind us of the plot. And we might as well watch it in full 1080 glory, rather than the old hdtv rips that we got nearly a year ago. So she tells a certain tool to upgrade our quality.
So far, so good. Sickbeard knows about this use case, so it helps her.
But something goes wrong. Some indexer gaves us a bad answer. She sees in the download queue, that we're downloading thirteen things, where twelve of them about about 4.5 gigs, but the first one, supposedly for S01E01, is about 49 gigabytes. That first download actually contains the whole series.
We already know how the tools will handle this. It'll download that 49GB set, take the first episode from it, place it where we watch it, and THROW THE REST AWAY. And then it's going to download the remaining twelve episodes. Again.
So she can either cancel that download (we'll watch the old S01E01 HDTV rip) or put up with the total nearly-95GB download. In user culture, the solution is to shrug and say "oh well. sucks but what can you do?" But in "don't be a pussy" culture, you let the 49 GB download finish (and cancel the other 12 of them) and you just manually unpack it, instead of relying on the automation. It's not hard. But the application programmers didn't handle the case, because they (mostly correctly) saw it as a something they don't need to deal with. And if the filenames are obfuscated so that you have to do some awking and grepping before your unraring, then you write your little "match things up by their crc32s" scripts. Programmer culture is the difference between getting what you want, and NOT getting what you want.
If we ever do get to the point where application programmers have done everything that needs to be done, I think it'll be because we have strong AI. You'll say "computer, get me season 2 and if the indexer gives you a too-big nzb, just fucking deal with it." Yet even at that point, you'll find a programmer. You'll talk to the AI and he'll tell you about how he learned awk.
Just show them the average salary ranges for UNIX admins vs. Wordpress admins. Actually don't. Let's keep this our little secret......
Again, a superb user interface/OS/Browser/Explorer WILL allow the launching of tasks from text input; there is no reason to do otherwise. Envision the following for an OS interface: // Screen Top [ File/Web Address ] // Begin Txt/Web/Application Screen // End Txt/Web/Application Screen
Wallpaper dims, icons hide and text displays on text output. : Command : Desktop -> shows desktop
Can split into multi text sessions: Command: SplitScreen (ctrl+tab to navigate between shells)
Can pop out as a window : Command: PopOut
[ text input field | [button for mouse folks] ] || Quick Launch Tasks
-- GUI Autocomplete on Command/File/Fav Progs Index
Popped out windows you can alt+tab through.
Each GUI application must sign a contract to provide all menu buttons text entry points, hopefully done at a low level
Each GUI application form must sign a contract to provide a text submission format
The OS would enable the rendering of HTML/javascript within the text session which would allow a rich experience if desired, such as printing images, graphs, movies to text sessions if desired.
The amount of stuff we do could be greatly compressed into a well designed operating system, and we could enforce interfaces which would make both the text side and GUI side more bearable for both sides of the spectrum.
TEXT sucks for a myriad of reasons.
GUI sucks for a myriad of reasons.
But this is a question of DESIGN, not the basic concepts of TEXT vs GUI. I am not arguing that GUI is superior to TEXT, I'm arguing that there's a better user experience than TEXT which should be equally fast provided good hotkeys and systems developers that require contracts be completed by applications developers.
It's about the right tool for the job. CLI tools are generally absent from user culture, but that doesn't mean that GUI tools shouldn't be part of programmer culture (even on UNIXy systems). It's important to present new learners to CLI, but it would be a mistake to characterise GUI-based programming tools as toys. I'm not at all suggesting Prof Guo has done this this; I'm just noting that it's an attitude I've bumped into more than once.
This luser is supposedly an assistant professor in CS at some little university ex polytechnic is my bet - you know if your learning something at Uni your supposed to be a fracking professional and you are meant to know your field from first principals - if you cant hack a CLI switch to midia studies
The name of the game is automation in the Admin world.. that involves using Vi or VIM to edit puppet scripts
What, no GNU Emacs?
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.
Using the UNIX/LINUX/SUCKIX command line to program is like riding a horse after the car was invented. Visual Studio is way more advanced than the kludge of command line tools available for "programming" in UNIX.
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 could hardly read the downloaded file since it is a monospaced text file. Ignoring the lessons of hundreds of years of typography is willful blindness.
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.
you don't understand command line tools, you're not even a real programmer. You're probably creating GUI's from GUI programming interfaces which isn't real programming at all. A child can do this with today's tools. Also, if you don't realize how much more productive command line applications are compared to GUI's, then you're pretty much an idiot and shouldn't be working in the programming field or any computer related field for that matter. This is a basic CS fundamental which is why terminal tools are still being created over GUI's for a large portion of applications.
When you communicate with a person, a gesture is fine if what you are trying to communicate is very simple or context makes it clear. If you don't have a language in common, you are forced to use gestures. If you need to communicate rich or subtle information however, a language is required. Communicating with computers is analogous.
Beyond that, MacOS is all about it's own thing completely separate and distinct from all of the other Unixen. It has always been it's own thing, even before the bolted all of the visible parts onto something else.
That's fine and dandy except for the fact that MacOS _IS_ (being derived from NextStep, itself derived from IIRC 4.1 BSD) Unix underneath, nothing it adds overtop changes that. IRIX had a load of GL/multimedia stuff overtop the base system, it was still Unix underneath. Your complaint is much more applicable to Linux, which despite all the pretending otherwise with constant talk of "inherently secure" because of "Unix underpinnings" is not and never was Unix. It's built to mimic Unix to a certain extent, but ultimately does its own thing, separate from Unixen, hence the term Unix-Like.
Unless of course you're an AIX/Solaris/IRIX/HP-UX/SVR5 guy, otherwise, sit down and let the grown-ups talk, sweetie.
I hate the command line (but then I'm not a sys admin). If I have something simple to do, a GUI gets one simple thing done fast. If I have something complex to do, I'll write a compile a program in a real language to do it. CLI scripts always seen to start simple and intelligible, but so quickly become unmaintainable garbage programs once you cope with real-world complexity. Give me a real language any day.
Socialism: a lie told by totalitarians and believed by fools.
Nevertheless most Mac OS users know how to write a shell script ... (except for the females, sorry, unfortunately true)
Wow! Conclusions from anecdotal evidence *and* misogyny in one post. You win the asshole of the day contest, Angel!
Who could not use the command line. Have no unix experience. An egghead that is not involved in linux.I round all my questions starting with nt 3.51
DOS 3.1 and 6.0 Like how do you swap floppy A with B in each.
dichotomy ever bro
The last time I used a CLI in my workplace, I was almost accused of hacking.
99% of the human race that has any knowledge of computers have no idea about the c-prompt, let alone a single blinking underscore.
[End Of Line]
I dispute that. I've got developers here porting a lot of old stuff into python because a few versions of VB went away. Lucky there's no silverlight stuff from before that went away. MS have a long history of abandoned tools.
Tell the hipsters it's what MacOS copied.
this article is stupid, if you want unix and decades of user interface advances the solution is simple...buy a mac. now if you insist on running hacked together open source shit. well. then you might have a problem...
GUIs tend to suck at automation because all GUIs tend to assume that end users are blithering morons.
Which, to be fair, is frequently a safe assumption.
I am officially gone from
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.
Beyond that, MacOS is all about it's own thing completely separate and distinct from all of the other Unixen. It has always been it's own thing, even before the bolted all of the visible parts onto something else.
That's fine and dandy except for the fact that MacOS _IS_ (being derived from NextStep, itself derived from IIRC 4.1 BSD) Unix underneath, nothing it adds overtop changes that.
I infer from "even before [they] bolted all of the visible parts onto something else" that the lack of "X" in "MacOS" is intentional; it sounds as if they were referring to "Mac OS" as dating back to the original Mac Toolbox or whatever the heck the term is, long before OS X.
Mac OS X was derived from NeXTStEP, but the original Mac software wasn't.
(But saying Apple "bolted all of the visible parts onto something else" when they went from classic Mac OS to Mac OS X is a bit bogus; there ain't much classic Mac OS code in OS X - there was Classic, but that was an emulation environment, running classic Mac OS on top of OS X rather than on the hardware - and even a lot of the UI conventions changed; Carbon on OS X implemented a similar API to Carbon on classic Mac OS, but, again, the code was different.)
IRIX had a load of GL/multimedia stuff overtop the base system, it was still Unix underneath.
Yup.
Your complaint is much more applicable to Linux, which despite all the pretending otherwise with constant talk of "inherently secure" because of "Unix underpinnings" is not and never was Unix. It's built to mimic Unix to a certain extent, but ultimately does its own thing, separate from Unixen, hence the term Unix-Like.
Every single UN*X does its own thing in some areas, separate from all other UN*Xes - if a supposed UN*X OS doesn't differ in some noticeable way from every other UN*X, it's not a UN*X. :-)
Yeah, Linux code isn't derived from AT&T UN*X, but that's true of a lot of the commercial UN*Xes as well, as well as the BSDs and OS X.
On the other hand, I have absolutely no problem using the GUI solutions for most of the simple stuff. I would suggest that one of the first things you need to do is teach newbies when each tool is most appropriate -- not that one is unconditionally better than the other.
Sometimes boldness is in fashion. Sometimes only the brave will be bold.
Nevertheless most Mac OS users know how to write a shell script ... (except for the females, sorry, unfortunately true)
Wait. What? I use OS X all of the time, I know a number of people that are similarly afflicted. Most of them would parse out a 'shell script' as cursive writing on a bivalve. And wonder why in bog's name why you'd want to do that.
Faster! Faster! Faster would be better!
GUI tools work fine while everything works the way it is supposed to. However, real life problems require one to read the error messages and those one can frequently only see on the command line.
Excuse me, but please get off my Pennisetum Clandestinum, eh!
My daughter came into my room while I was writing a bash script to run LAME against my music wav files. She asked what I was doing and I explained. She spent the rest of the afternoon reading the bash man pages.
How you gonna get them to hammer nails through their balls when they find out they don't gotta hammer nail through their balls?
At the time I switched to Linux I had only DOS which I regarded as inferior due to MS not supporting a flat memory model. MS started to support this in a credible way only with winnt in 1993, whereas they could have had something when the 386 came out in 1985. Given that they started in 1981 they had only four years of acquired customers but they managed somehow to respond to new hardware with a delay of eight years.
Once I had Linux running in '95 I also totally liked the grown up look X-Window had. Maybe you should tell your kids " ... and when you grow up I'll let you play with the big iron".
Je me souviens.
We are not talking about the "avarage joe" here. We are talking about people that can maintain an system - even if the beloved GUI is down, or only having remote (non-GUI) acces..
I would certainly not hire someone that has no idea what to do if their "clicerty-click" does not longer work, or is not accesable at the location he/she/it is..
"Convincing students from user culture to toss aside decades of advances in graphical user interfaces for a UNIX command line is a tough sell"
WHO SAYS YOU HAVE TO TOSS AWAY ANYTHING.
You use graphical user interfaces when needed.
You use command line when needed.
I don't have any problem with my engineering degree students to use the command line. It is a very powerful tool and they understand it very fast. It is also good looking in any Linux or Mac. We use big, vector, beautiful fonts and everybody loves it.
Of course I am not asking my students to do a spreadsheet or browsing the Internet in the command line.
The main point of using a CLI is that it offers you more options than any GUI. Stop, re-read the first sentence. The CLI lets you take a tool, then add tools to it. As many as you want. In any order you want to get exactly the answer you are looking for or whatever you want the computer to do. Using a GUI, you use it the way the person designing it intended. A typical CLI has hundreds of available tools that can be mixed and matched; applying them in different orders gives different results. A GUI has some pre-programmed results, select the one you want, if the one you want isn't there, you might need another program which may not exist. A CLI can store groups of commands: a 'script' which can be re-applied as needed. I've been running my own kernels, exclusively, since 1994.
There are some use cases an everage user may encounter that would make a good demonstration of the command line power.
I don't have many in mind just right now, but the typical case is a long, tedious, error prone task to be done with a mouse and GUI, but it boils down to one or two commands that do the job in five seconds. Think of something about the files (moving, renaming, searching, ...)
There are also some examples with pipes:
How do I check if there is the word "myemail" in one of those 4000 text files located in a compressed archive ? (I don't want to unpack all the archive on my disk!)
There are some nice command tools to show:
"I can't open this file f8965446, it has no extension, what is it ?" Try "file f8965446", if it is a video you will also get the container, codecs and so on...
Other variants with unicode problems, binary viewer in hex (no additional GUI tool needed), disk usage on directories, file comparison,.
Finaly end the demo with a few scripts: ...
First a dumb script made with the output of a long "ls -1" and brutal search-replace on many lines, then execute to do the job (massive rename, whatever).
Then a smarter script with a loop on files for a batch conversion (or download).
Then a script with command line arguments to encode their mp3 or whatever, sort a collection,
Schedule a script to download the specific web page, process it, and log some info in a journal, then take advantage of the journal. For instance: a script to catch the transcient tweets of someone.
You see, you use assembly as an illustration of tedious labor, but assembly language was actually a great relief for programmers when it was introduced. Prior to that, they had to write code in machine language which produced much more strain and was far more prone to errors. Speaking as an embedded developer, there were times when I would kill for a command line, yet all I had was an unused microcontroller output pin and, if I am lucky, an oscilloscope. Coming from that to UNIX is like getting into heaven.
Therefore, if you need to teach the students the innards of computers, start with basics, and add improvements. It is not coincidence that in biology development repeats evolution. So should education - present the state of the art in historical context, why it is better then what was used before it, and what was there before that, ... You can't understand modern art unless you understand the art it reacts on, you can't completely understand C# before you suffered in Java, understand Java before C++ made you cry, understand C++ before you toiled in C, understand C before you had to port something from one architecture and assembly language to another one, appreciate assembly language before you had to insert a snippet in machine language and recalculate and change all relative jumps in code, appreciate computers before you had to redesign a digital automaton because specs changed, really appreciate digital circuits before you fought off noise and oscillations in analog computers, ...
You mean allowing morons to crank out tons of worse-than useless code? That is not productivity.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
Well I for my part hate the "new" search function since 10.4 or was it 10.5? So I often use find, and unlike others here in the thread: awk is one of the most useful programs ever made.
Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
Summary
There are now two main cultures in computing: Most computer users treat software as a tool for getting tasks done, while programmers hold conversations with their software.
How do you "hold conversations" with a command line that rarely gives helpful feedback, and never gives any feedback before you've already sent a potentially destructive command? As programmers, we mostly use IDEs unless the language is very easy (= not very expressive), or unless we're very comfortable with the language and libraries. So why do we still use bare command lines?
This is what is wrong with the command line: it's not responsive enough. And if the lack of usable GUIs in UNIX even for tasks as restricted as changing a preference is a choice, it's a stupid one. Not everything you do on a computer requires a Turing-complete language, and not every Turing-complete language needs to be written on a teletype. No one should be required to RTFManpage before trying out stuff.
As many have already pointed out, it's irrelevant. Different tools do different jobs better, and that's just the way it's always been. I find managing my email in a GUI a hell of a lot easier than a command line for example, but when it comes to managing the Brocade switches at work (I'm at least partly a storage admin) it's a hell of a lot quicker for me to SSH in and type a few commands. Of course, it doesn't help that the Brocade GUI is probably one of the worst out there but my point still stands. Managing the SANs I manage is actually easier with a well designed GUI (primarily Compellent at the moment) because I don't have to use my own brain-cycles to visualize it; I can see it on the screen. But yes, if I'm doing bulk stuff then dropping to a command line is key. Similarly, I also manage vSphere... for day to day management the GUI is pretty good but when doing a lot of repetitive stuff I use PowerCLI which is VMware's PowerShell extensions... they work fantastically well and make me look like a hero.
Now having said that I do see the point of the article a little. My personal feeling is that as a parent it falls to me to make sure my son is familiar with the command line and sees the value in it as well as the GUI. I decided to put my money where my mouth is and bought him a Fuze for Christmas. I was concerned he would hate it because he is used to having a Windows-based laptop and is well familiar with the GUI tools there. But he has really taken to it, learning BASIC programming and fiddling with the command line with a few things I've taught him. In fact this morning I was having a hard time getting out the door and heading to work because he wanted to show off the program he'd written to flash a set of LED's in the breadboard in sequence. I was incredibly proud of him for it and wanted to show my enthusiasm. I was late for work and didn't care.
Honestly the way I see it; my 13 year old boy if he continues on this path will be programming and working with the hardware that goes into satellites, space probes and the like where a BSOD cannot be tolerated. He will have work for life because there will be even more need for the microcontroller programmers in the electronic, wearable and increasingly digital world he will grow up in. Meanwhile his peers will compete to administer Windows computers and maybe write apps for the iPhone 26... and may even struggle to make ends meet as they convince themselves that their app will make them a billionaire. So long as my son continues what he's doing and learning even as I write this, he'll find himself comfortable and in-demand until he retires. Just like his old man (hopefully!)
Despite my working as an administrator of systems, I have a background in programming. The command line taught me how to pipe, how to use variables and so on. I write a surprising number of scripts in a number of languages because they make my job easier and make me look like a hero. I find myself occasionally competing with new kids coming into the workplace with their "Mad GUI Skillz" and their macros. If they go toe-to-toe with me they can rarely compete. The ones who know command line stuff and scripting we tend to keep... the ones who don't, tend not to last.
I'm building a site right now (actually the site's finished, on the surface) that if you enter the Konami code on the main page it loads up a Synchronet BBS in a flash or html terminal (I don't want people logging in right now or checking the site, so I'm keeping it quiet.) I think it will be pretty popular compared to the BBS's that are still out there because BBS's that have been up since the 80's/90's are like abandoned palaces waiting for their kings and queens to come back rather than try to find new royalty. Anyhow, if anyone wants to work on a BBS for fun, i've got work to do!
Myth #1. You Need to Use the Command Line to Use Unix.
With modern distributions of Unix/Linux there is no reason to ever use a command line if you are an average desktop user.
The myth of the linux command line requirement is a lie.
Myth #2. There is a 'Difficult Learning Curve' To Using Unix
With modern distributions of Unix/Linux the GUI is as self explanitory as MS Windows. There is no real learning curve. You click a GUI button in Ubuntu something happens, you click a GUI button in MS Windows same thing. The curve is a lie.
Myth #3. Advanced GUI Features Arrive From MS Windows Direction
Most of the advances in the MS Windows GUI over the last 10 years have been lifted from either Mac or the various Linux window managers. The latest MS fixation with touch screens is lifted from Apple and Android mobile device operating systems.
Myth #4. Grandma Needs MS Windows to Survive
Grandma needs Google Chrome or Firefox web browser, Thunderbird E-Mail or Gmail, and a solid solitaire or mine-sweeper game. Those are all available for Unix/Linux. Grandma wouldn't notice the difference.
What is Most Surprising About This Article
...is that there is a biased assumption that somehow there are two (battling) cultures. The reality is there is only one culture, largely underinformed on both sides of the Unix or not Unix debate. The assumption that 'There will be trouble in Dodge City' (oooh!!) if we try to teach Unix to students is the myth that creates all those other myths. This is mainly due to the fact that most CS Profs are old MS Windows crones who continue to think the relative psychological security of 'InstallShield wizards' are what keep Grandma (and students) computing. Most programming is currently happening on Android/iPhone or else on web platfroms that have nothing at all to do with specific operating systems (Unix or otherwise).
I say leave it this way. There are people who by their nature will always trend towards lazy and stupid solutions. Give them those solutions so that we can pick them out easier when we're hiring people.
"No good deed goes unpunished"
"Paree". Problem solved.
I work with a sysadmin - first job - whose main experience has been windows. I introduced him to pipe's, awk and other tools. I could see him put two and two together when he said, it's all text manipulation.
The big dirty secret is that Windows is based upon Unix!!! Microsoft's first product was Zenix a flavor of Unix albeit a bad and really really slow one. If you dig deep enough (and I have) all those Unix O/S calls are there. It is not a coincidence that 2 years after Cal Berkley thru Unix source code over the fence to the public domain Windows NT appeared. Originally laughable (ever tried to hook a modem up to NT 3?) at the time it is the undisputed king of the civilized world.
Any time someone is foolish enough to talk about Apple computers, I remind them they are toys, not work tools. When you can design a bridge for both stability, controls, and dynamics on a Mac, output the bill of materials and send design documents to the subcontractors that they can build and bill to. I will call it a tool. In the meantime it is a toy. So what are we left with? Not much really.
1) IBM Mainframe a very small niche
2) VxWorks (very very much Berkley BSD with an interrupt handler, and deterministic scheduler) and a bunch of other realtime O/S products that have market share like a Windows Phone (proof Microsoft makes mistakes)
3) Vaxes and Solaris boxes bought for next to nothing
4) my personal favorite the SGI beer cooler
You want students to be employable? Teach them Microsoft and Visual Studio and all the Microsoft business technology because the odds are they will email with Exchange, work on a Microsoft desktop, and store documents in SharePoint, plan products with Project, and store data in SQL Server and do big data/big data table in Hadoop with SQL Server extensions.
In 5 years Oracle will stop making Sun boxes that only zealots with government money buy. Oracle already loses money on their hardware each and every quarter; are you listening Larry?. When thinking about Oracle think of Data General, Silicon Graphics and Integraph. Java will continue its ossification and decay.
Facebook and Google use copious amounts of cheap Linux boxes. Linux is free because it really isn't much good. The world does not need Facebook which will be gone in 10 years and the rest of the world will realize Google is a front end and that the NSA has backend superuser access to everything Google does in spite of public denials.
Other than that Microsoft, in spite of all their mistakes, will continue to rule the world, except maybe cell phones, but no one needs a cell phone like they need food, clothing, shelter and a business desktop to do work.
Apple will eventually be $20/share again. Bill Gates is the richest man in the world because he deserves to be. Linus Torvalds doesn't matter. BSD Unix matters and Windows is a BSD box with a windowing system and development tool set that are richer than anything else in the computing world.
Feel free to denounce me as a fool, but I accurately predicted the demise of Digital Equipment, Integraph, SGI and Sun. A lot of shareholders would have done a whole lot better had they listened to me instead of, well almost everyone else. The price of Apple stock is a bubble, fundamentals aren't their, ask Ben Graham or Warren Buffet. Clip this paragraph of mine and 5 years from now you will realize how prescient I am and will have wished you sold your Apple stock. In the meantime I have to get back to work on Windows desktop.
I still have a place for Unix: I am looking for the perfect 1994 Silicon Graphics 'Predator' box for my bonus that I can turn into a beer cooler for the bonus room. Onyx boxes are too passé. VAX's makes nice end tables but have no visual panache like vintage SGI.
I know the shell, the command line, have since the days of glass TTYs, but you can lead the GUI users into it the next time they run across a situation where the file manager or finder doesn't give then the fine control they would get with file name regular expressions in the shell.
It isn't that Grandma has a problem finding the recipes file from time to time, she may well learn to use grep from the terminal, eventually, but it is for the person, whether sysadmin or not, who has to find stuff everyday all day. Then eventually he finds out that the shell and regular expressions will help him achieve his goal faster. If you want to introduce GUI users to the terminal, just answer a question with it. My son brought his Macbook to me one day and asked if Python was on his machine and how he could use it. I could have easily told him to go to the Applications folder and look, but I opened terminal and did "python" typed in a couple of statements and demoed it to him. I may also have done 'man python', to show him it was there. As python is used in system maintenence, it may not be listed in Applications if the idle application isn't installed, but I'll bet it is there.
On Windows, yes Windows, a good implementation of the shell can save you money, paying for the third-party programs that do utility jobs that aren't part of Windows but can be easily created with an instance of bash installed. Renaming lots of files is a task that comes to mind. There are plenty of programs written for Windows that do that and you will pay, but install Cygwin for nothing, one of the first things I do if I have to own a Windows system, and do it from a terminal, xterm, in bash with a for loop.
wow! there's so much that's new and really thought provoking in what this guy is saying. and did you hear about the lecture he gave last week on this new thing they call 'fire'?
GUI's are limited because they are walled gardens. That is you can directly use a feature in one program from another. But I believe that it is possible to create a GUI with the flexibility of a command line. For example, you could create a photo organizer with the essential photo organizing tools. Then some other user could extend that photo organizer with photo editing tools via popular command line utilities such as Irfanview, Exiftool, FFMpeg and others. The user would have control over key/mouse assignments, positioning in the menus etc within the GUI without programming.
Only a slim minority of programmers code against the OS-specific or kernel-specific APIs. They all use abstraction layers like Qt, GTK+, .NET
.NET is an OS-neutral "abstraction layer"? Why, yes, it supports multilple OS's: Windows XP, Windows 7, Windows 8, Windows 8.1...
grep -r "useful information" | less
Do more with less!
UNIX has had GUIs in one form or another since X graphics server reared its ugly head in 1986, not long after microsoft and apple did the same.
as for the CLI, like the keyboard its not going anywhere. Its been decades since its seen daily use by casual users, however its still needed for many things. For one, its quicker and EASIER for experts and power users. there is no need to navigate a complex maze of windows and submenus, you can type any command from anywhere. There is also no need to navigate directories(you can though), you can refrence a file anywhere, from anywhere. Then there is scripting and automation. You can automate system tasks by making a script with the same commands you use on the command line. GUIs have macros which are not nearly as powerful, far more complicated, and will never ever work nearly as well.
Mabey there is a reason microsoft introduced powershell to compete with traditional UNIX shells for scripting on servers. BASH is still well maintained.
There is no OS popular today that precludes the use of a command line for troubleshooting.
As far as next generation with GUIs, again another misnomer. My generation grew up with GUIs. I am over 30 years old. in the 1990s we also had mp3s, web browsers, internet porn, instant messaging, all in a GUI.
Exept today there is far more motivation to learn computers (they are EVERYWHERE, and run EVERYTHING), computers are cheaper, documentation is far more abundant, they work better, and you can get things like Rasbery PIs for $35. We didn't have that in my generation.
Like our generation, the ones that want to learn, for whatever reason, will. The ones that are content with being users, will.
Stop forcing kids to use IDE's and make them use text editors and compilers. The biggest joke I have noticed in computer science is making kids using IDE's for ASM and C. They spend more time loading the IDE's and more time setting up the projects then the entire project would take in the first place. Proper computer science starts on the command line with a old editor like VIM and a compiler like GCC, anything else is just wasteful.
...on Linux.