How Ya Gonna Get 'Em Down On the UNIX Farm? 606
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.
Stop trying (Score:5, Insightful)
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
Re: (Score:3, Insightful)
Re: (Score:2)
Re:Stop trying (Score:5, Insightful)
It's the price you pay for being "ready for granny"
Another reason would be the WINAPI. It's a horrible, horrible mess.
Re: (Score:3, Insightful)
Because by coding against a black box, you can only become more and more proficient in knowing how the black box behaves for given inputs - the underlying concepts are pretty much invisible so the computer mostly remains 'magic'
Only a slim minority of programmers code against the OS-specific or kernel-specific APIs. They all use abstraction layers like Qt, GTK+, .NET, etc. So for 95+% of programmers they won't learn anything else since they'll still be using the same abstraction layers. Using Qt on Linux is not teaching me anything more than using Qt on Windows or OS X does and that's the lowest level that pretty much all programmers would be going.
Re: Stop trying (Score:4, Insightful)
Btw, I've seen at most companies, we'll all, that their Linux side of things is a freaking messy disaster. Why is that?
I actually haven't seen much of that at all. In the cases where I have, it boils down to one of two things:
1.) Wanting to pay Windows admin wages for a *nix admin.
or, even worse
2.) Putting the existing AD admin in charge of the new Linux servers.
Re: (Score:3)
3: Recruiting competent linux sysadmins and limiting their selection of software immensely.
For instance, requiring that they make everything work with a web interface...
Re: (Score:3, Insightful)
There's a Chrom(e|ium) extension for a terminal emulator with SSH if that's what you mean?
Re: (Score:3)
Re:Stop trying (Score:5, Insightful)
Understanding what the tools do under the hood is important. Using command line tools is not. I could write in assembly if I really wanted to, but I use C# for most stuff. I understand what it does under the hood, but that doesn't mean I have to always work at that level. Using GUI tools is the same thing. I know my GUI tools for administering a Windows server and I can typically make complex adjustments just as fast on it as my UNIX buddy can do using command line tools on his Linux boxes. The difference is what we are comfortable with. Some things go faster with one command, but when you have more complex actions, sometimes the GUI is faster. Either way, you still have to know your system and know what all the buttons or commands actually do.
Re: (Score:3)
GUI can sometimes be handy, but I much prefer that there be an underlying CLI available. CLI can fit through a degraded connection, a serial connection, etc. It's much easier to get someone to type the right thing than to click on the right picture of a squished bug. CLI scripts readily.
The ideal GUI admin tool will generate the necessary CLI commands and either just run then of show them to you.
Re: (Score:3)
Re:Stop trying (Score:4, Insightful)
Linux is a black box for 99% of its users too, since having access to the source and being able to comprehend a small fragment of it are vastly different things.
Practically speaking, for sysadmins, whether source is available is not always (or often) going to be terribly relevant.
Re:Stop trying (Score:4, Informative)
Linux is a black box for 99% of its users too, since having access to the source and being able to comprehend a small fragment of it are vastly different things.
Practically speaking, for sysadmins, whether source is available is not always (or often) going to be terribly relevant.
No, actually, that's a horrible analogy.
If we must analogize, Linux is deep water. Almost infinitely deep. So deep, in fact, that few choose to plumb it all the way down. But it remains visible and accessible to the level of every sysadmin or developer's needs. The fact that most people prefer to skim along the surface takes nothing away from the volume of information waiting to be explored.
And now, because I'm forced to indulge in silly analogies, I find myself compelled to say that Windows is a swimming pool. A large one, it's true, and a crowded one, too. But you cannot easily move beyond its (broad) confines, you have no insight into where the water comes and goes (a topic which increasingly preoccupies my thoughts as I consider the statistical likelihood of people pissing in the pool), and you have little control even over your own course as you are buffeted and blocked by the arbitrary actions of others.
Finally, to get things back on a more practical level, PowerShell may do wonderful things, but the thing that makes Bash so compelling is the environment it runs in. Bash itself is a bit awkward and limited, but it's just glue for binding together countless ingenious (and sometimes even elegant) commands and utilities that can allow you to do things in minutes you couldn't really contemplate doing on Windows in comparable time. In fact, the only way that Windows seems to be able to compete with *nix on the server side is by appropriating the very things that make *nix so compelling.
Re:Stop trying (Score:5, Insightful)
"Could" does not equal "is".
I code for a living, 20 year veteran. I've rolled my own Linux distros (back before the likes of Knoppix remastering made that trivial). I've tweaked my own kernels to (for example) force enumeration of a second PCI bus on a box that only announced it had one (nothing impressive, not bragging, just establishing my "cred").
And honestly, 99% of a modern Linux distro still amounts to a black box to me. Yes, I could open the box, and have the background skills to understand what I see inside; but the GP's claims stand, IMO. To 99% of Linux users, even including devs, Linux may as well run on caffeine and enslaved pixies for all we passively know about the internals.
That said, I will agree with you to the extent that having the ability to open the box when necessary makes a world of difference. But going back to TFA, that doesn't mean squat to someone who only sees pixies even when they do look inside.
Re: (Score:3)
The point is, when problems do arise, you have the option to look, and often times, it's a better look than any army of vendor support drones could give you. This cannot be done with windows in typical shops.
Re:Stop trying (Score:4, Insightful)
As it ever was, grasshopper.
Re:Stop trying (Score:5, Informative)
I wasn't talking about what 'the tools do, under the hood' (dammit, typical windows speak), my point was that your operating system is a black box. dammit there isn't even source code available.
Darwin source code no longer exists? This link [apple.com] no longer works? In an education environment you can also get access to the NT source code. Either way, it's all irrelevant to most programmers even those on Linux.
IOW, windows experts know how to use windows, unix experts know how unix work (and therefore, due to the openness and clarity, a lot more about how their computers work).
So OS X is no longer Unix? No longer bundles all the Unix utilities? No longer uses POSIX?
Re: (Score:3, Interesting)
I wrote a SCSI driver for OSX, because OSX specifially disallows generic SCIS access, even to root. That part of the kernel is not (or no longer) open source, so you are on your own when writing the driver, which by the way is a horrible, horrible experience with XCode and layer and layers of C++ abstraction and inheritance. Why do storage drivers panic so much on Macs (LaCie, etc, they all need custom drivers because OSX _knows_ you don't need SCSI CDBs of your own)? This is why.
On Linux, the source is rig
Re: (Score:3)
Have you ever used a mac? Your great spouting of cliches suggest you havenâ(TM)t.
OS X is UNIX(tm) - not UNIX-like, UNIX-wannabe, etc... UNIX. http://www.opengroup.org/openbrand/register/brand3602.htm/ [opengroup.org]
When did the shielding of lower layers become contradictory to UNIX philosophy?
Why do you think it is called a shell?
Re: (Score:3)
and yet his description is closer to technical truth than your ad hominem attack.. who's the uneducated one?
Re: (Score:3)
Re:Stop trying (Score:5, Insightful)
How many people writing applications on Linux ever regularly read the kernel code? Or, for example, the Qt source code beyond the headers? Yeah, next to none of them.
Re: (Score:3)
(*)unless it's, say, the damn flash plugin, by far the most crashing program here. Those times, while bending over to take it up the ass from adobe, i'm reminded of how your proprietary world feels.
Re: (Score:3)
Windows users know how Windows works too. We may not have access to the source code details exactly, but most of the underlying structure of the system is extensively documented as to how it behaves. Symbol builds are also available for debugging purposes. True, it isn't as simple as it would be with an open source system, but you are overblowing the difference between the two. The main advantage of open source software is being able to change how something behaves rather than knowing how it behaves. I
Re: (Score:3)
You don't need every driver to understand how a transmission works in order to get their drivers' license, and you don't need every delivery driver to understand routing algorithms to be able to drive their route.
You're right, of course. Except that the topic here isn't about the general population of computer users; it's about teaching maybe 1% of people to develop the software for those computers.
With autos, it's true that 99% of us will never need to understand how a transmission or other internal subsystems work. But if you're considering a career either designing or maintaining vehicles, you'd damned well better be learning about the mechanics (and chemistry and electronics) of their internal mechanisms, o
Re: (Score:3)
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
Re: (Score:3)
In what way exactly? I can use all the same GNU tools on Windows and OS X as you can on your enormously more cost effective Loonix box.
There. FTFY.
Oh, and yes that's completely true. cf. Cygnus Tools [cygwin.com] for Windows and, well, OS/X *is* UNIX.
Re:Stop trying (Score:5, Informative)
" well, OS/X *is* UNIX."
Easy there, Cowboy. You don't want all these pilgrims to just drop dead of coronary arrest, do you? Break the news to them gently, please?
Re:Stop trying (Score:5, Insightful)
Cygwin is an abomination.
No, seriously.
Compared with cmd.exe and the standard MS command line, it is heaven, my friend.
Re:Stop trying (Score:4, Informative)
The "standard windows commandline" is now powershell, and it is wonderful in many ways despite its quirks.
Re:Stop trying (Score:5, Funny)
The "standard windows commandline" is now powershell, and it is wonderful in many ways despite its quirks.
Absolutely. Indeed, it is approaching the Bourne shell of the 1970s, almost approaching late '70s C shell.
Re:Stop trying (Score:4, Informative)
I dont disagree, but one of the reasons I love powershell is because there is so much vendor support for it. Rather than having to use crappily written vendor provided scripts, or learn a new set of syntax and instructions for everything, you can just use one set of cmdlets to manage everything. For example, managing storage units, virtual infrastructure, and networking (if you were using Cisco UCS for example) would involve a unified set of syntax and command structure (verb-noun-- GET-nacifsshare; REMOVE-cluster), with output that can easily be manipulated and passed around. Everything is an object; everything can be piped into get-member to discover its methods, properties, and data types.
Obviously it will depend on what platform youre on; if your work involves primarily *nix boxes I imagine you would want to stick with bash. But Ive found that it is incredibly rewarding to work with powershell in a windows environment just because of how easy it is to take knowledge from one task and apply it to many others, and how easy it is to get your bearings in an unfamiliar task.
Re: (Score:3)
Its almost sad to me that so many techies are falling back into the "I dont understand it so I hate it" mentality.
StackExchange has a pretty good explanation of the whole Powershell vs Bash thing, with the takeaway being, they have different designs and are good at different things.
http://stackoverflow.com/questions/573623/is-powershell-ready-to-replace-my-cygwin-shell-on-windows [stackoverflow.com]
There are a lot of reasons to criticize powershell (startup time for one, memory usage for another), but sadly the ones here basic
Re: (Score:3)
Its almost sad to me that so many techies are falling back into the "I dont understand it so I hate it" mentality.
StackExchange has a pretty good explanation of the whole Powershell vs Bash thing, with the takeaway being, they have different designs and are good at different things. http://stackoverflow.com/questions/573623/is-powershell-ready-to-replace-my-cygwin-shell-on-windows [stackoverflow.com]
There are a lot of reasons to criticize powershell (startup time for one, memory usage for another), but sadly the ones here basically amount to "I hate closed source" or "I gave it 5 minutes and I didnt like it" or "im a unix guy and see no need for it". Those may be true, but theyre not faults with powershell
Let me clarify my point from a few replies ago. As an admin, it's not about BASH vs. Powershell, it's about having tools I can use across multiple platforms *without modification*.
If I have to write Powershell scripts to accomplish something on Windows and then Perl or Python scripts to accomplish *the same thing* on UNIX/Linux, I'm duplicating effort in creating and maintaining those scripts.
Us admins hate duplicating work. We like to do things in a way that takes the least effort to do the job correctly
Re: (Score:3)
that being said, sort can sort on arbitrary colums (-k)
Your point is moot.
Re:Stop trying (Score:5, Insightful)
Cygwin is the only thing that made life tolerable while doing development work for companies that only allowed employees to run Windows. I don't think I'd call it an abomination, it's perfectly fine if all you need is a bash shell and the standard tools (find, grep, sed, etc). But I hope I never have to use it again, mostly because I hope to never be stuck on Windows again.
Re:Stop trying (Score:5, Insightful)
Cygwin is GNU bolted onto Windows. So it has it's own quirks. While it's better than all of the alternatives if you're being forced to run on an NT machine, it's no replacement for the real thing.
Re:Stop trying (Score:5, Insightful)
They are stuck in the way TFA points it out -- it's in their minds.
Lets try an analogy:
Say you have a hammer - yet nobody ever taught you how to use it, so you have to figure it out yourself. You mistake the head for a grip, and start bashing nails into the wall by holding the hammer's head in your hand, and hitting them with the
It sort of works, and more importantly, you aren't aware of a better way, so it's "the best way" (you know).
Now imagine being told that you've been doing it wrong all the time, that the hammer is to be held at the other end.
Skeptically, you give it a try. Holding the hammer correctly for the first time in your life, you realize it's a bit harder to handle than the way you're used to.
Then you violently, like most people on their first attempts to hammer something, smash it onto your thumb, OUCH, WTF, this is fucking dangerous.
Clearly, your original way to hammer was superior, and way less painful/dangerous. Right?
No -- all it would have taken is to actually see someone working the hammer properly, before you realize how wrong you've been.
It's pretty much the same when it comes to CLI vs GUI
Re: (Score:3)
It's pretty much the same when it comes to CLI vs GUI
OK, but sometimes the GUI is hammer (held the correct way) and CLI is a sledgehammer. Yeah, the sledge can probably drive in a small nail with one well-aimed swing. But it's really heavy, and if you get it wrong you'll flatten the nail and possibly break the thing you were trying to nail.
Sometimes you just want to drive in a nail, not construct a railroad. The right tool for the right job.
Re:Stop trying (Score:4, Funny)
destroyed by typos and autocorrect stupidity
You see how powerful a GUI is! Good thing your typing is perfect, I am sure the command line never gives you syntax errors.
Huh, what? (Score:4, Interesting)
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.
Re:Huh, what? (Score:4, Insightful)
Sure. The problem is teaching people to be admins. If they refuse to use the CLI, then it doesn't matter if they are smart or not - they will not learn. This was the focus of the original article: teaching students used to GUIs.
Try GnuWin32... (Score:5, Informative)
>> so wholly lacking in the functionality of a UNIX shell
That's why I use the GnuWin32 http://gnuwin32.sourceforge.net/ [sourceforge.net] tools: basically your standard Unix utility set on Windows.
Re: (Score:3)
I'm currently a Windows sysadmin.
Fuck PowerShell.
I have nothing more to say.
Re: (Score:3)
Youre missing out. How on earth do you manage huge batch jobs like modifying 100 print queues or getting reports on your VMs?
Re:Huh, what? (Score:4, Informative)
Yes, you can enable SSH on ESXi. There are also varying levels of support from third parties, most of which are easier to deal with than Microsoft.
Perhaps I should clarify what I mean when I say I'm a "Windows sysadmin"... For the past two years, I've been doing systems work with Windows. For the first year, it was mostly in a bog-standard admin capacity, but for the past year I've been working exclusively on a project in Windows Server 2012, using PowerShell heavily. I'm now in charge of maintaining and improving about 10k lines of PowerShell scripts.
Powershell is the second [veekun.com]-worst language I've encountered in almost two decades of programming. Here's a few reasons why:
My theory is that PowerShell started as a way to tack .NET support onto batch files, but then some brain-dead executive thought it'd be a suitable competitor to Bash, so they had to add pipes, but it's just gotta use objects, because Windows is all about the objects! Then somebody actually tried to use it for something productive, and realized it was still limited, so they added half-assed module support so it could be more useful later. Executives saw the progress, and declared that it had to be integrated into all the new 2012 stuff, so that meant that each team had to figure out their own way to make PowerShell make sense. Of course, in typical Microsoft fashion, nobody thought to look over a
Re: (Score:3, Insightful)
I hate to break it to you, but I can ALSO write a black box executable that you can call with "connect-nacontroller ctrl1.dom.local \; get-na vol" and have it do magic shit behind the scenes. The fact that, on unix, I do not need to and can use teh tools the OS provides is the whole fucking point. This is why powershell sucks. You can only do the tasks someone else already programmed for you. Get it through your dense head.
Several thoughts (Score:2)
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 don
Re:Several thoughts (Score:4, Interesting)
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.
It's an Exclusionary Club (Score:2, Insightful)
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.
Re:It's an Exclusionary Club (Score:5, Interesting)
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.
Re: (Score:3)
It's the MS Windows8 way now isn't it? That's how people seem to be justifying the new GUI anyway.
Re:It's an Exclusionary Club (Score:5, Insightful)
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.
Re:It's an Exclusionary Club (Score:5, Funny)
Well, sure, but what about when you first started getting into computers?
Um, there really weren't any GUIs back then...
Re: (Score:3)
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" {} \;`
I wonder . . . (Score:3, Insightful)
Re:I wonder . . . (Score:4, Funny)
How fast can you rename all files whose names contain the string 'numbskull' in a different directory without leaving the current directory using Windows Explorer?
I'll be down at the dock with my fishing pole. Come find me when you're done.
Re: (Score:3)
also be maintainable, none of those things benefits from CLI over GUI.
..all of which might just be more quickly and efficiently done with a CLI, thus adding value to your company. Using a GUI alone does not automatically bring value. It depends on the task bringing that value. If you can automate it with a few CLI commands, you should.
In the beginning was the Command Line (Score:2, Flamebait)
Read Neal Stephenson's In the beginning was the Command Line [cryptonomicon.com], or, better yet, give it as a set book to the students. It's available for download from his website [cryptonomicon.com] for free, or you can buy it as a paperback from all good booksellers (and some bad ones [amazon.com])
I'll take a tank, please. (Score:4, Interesting)
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
Command line is more error-prone (Score:5, Interesting)
Re: (Score:3, Informative)
User error can happen regardless of user interface really.
Re: (Score:3)
Your finger needs to slip quite a few times to add the --no-preserve-root to that command (it might be GNU coreutils exclusive though). :)
I've clicked the wrong button on a GUI several times, just as I've made typos on the command line. Both have the potential to screw things up unless I'm being careful.
I don't know how many times at my previous job that some Windows admin deleted whole sections of our AD database via the GUI. That GUI doesn't even have an option to prompt before deletion, whereas I can just insert "alias rm='rm -i'" into root's ~/.bashrc. Just sayin'.
Re: (Score:3)
If it is text based or (shudder) XML based configuration files, then you can easily stuff the file into any version control system and easily see the differences between what you started with and what you are now running with.
For server administration, documenting what you did to configure the system is a very big deal. Text based configuration files mak
Re: (Score:2)
It's easier to shoot yourself in the foot with the command line
Depends how you learn. If you sit down with a table saw, never having operated one, you're in for a hard learn. Same as any tool. I would say the same goes for a gui too....that damn Voiceover is error prone enough to qualify for the-icepick-of-death-in-the-speakerhole treatment.
Re: (Score:2)
if a gui goes wrong, unless the designers thought of that circumstance, you're left with some internal state inconsistency that you can't even diagnose much less address.
Right. But that's a bug in the software, while I was talking about user errors.
no need to gently move (Score:4, Informative)
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
Re: (Score:2)
Don't pander to lazy, unmotivated fucks.
This.
I work in (actually, I own) a small software company and everyone is on Linux, even the non-technical people. Most of the non-techies do not normally use the command-line. However, I have written small CLI utilities for various things and the non-techies were perfectly fine learning enough CLI to use my tools. It's not that difficult and if people are too lazy or stupid to learn something new, then they don't deserve to be employed.
Re: (Score:2)
Indeed. And fail those that cannot cope permanently. They have no business managing or creating IT systems. A professor I know requires everybody to learn C and use it competently in order to pass his OS course. Students complain of course, because all they learn is Java. But that attitude changes for most of them later, when they realize what things they would have real trouble with, without that experience. When this guy retires, the quality of the education there will drop markedly.
Re: (Score:3)
Don't pander to lazy, unmotivated fucks.
Is that like those "lazy, unmotivated fucks" who use an electric drill instead of a bit and brace? Or those people who drive a car instead of walk everywhere? Technology changes and calling people names does not motivate them to stay stuck in the past.
Re: (Score:3)
Technology changes and calling people names does not motivate them to stay stuck in the past.
If the students in question are going to spend their careers in Marketing or HR, you might have a point.
If the students in questin are going to spend their careers in IT, the inability to use the CLI == incompetent.
Sorry if you don't like it, but that's the way it is.
Re: (Score:3)
the inability to use the CLI == incompetent.
So is the over reliance on a CLI. There are many things a GUI can to faster than a CLI.
Learn CLI's and use it for what it is good for but also learn GUI and use them for what they are good for.
Re: (Score:3)
If it's better, how hard do you need to sell it? (Score:5, Insightful)
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.
The FA is backwards (Score:5, Insightful)
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.
Re: (Score:2)
Indeed. But that is only true if you have bright people with potential. The others will stick to the GUIs, as they are completely lost without them. Hell, many "programmers" or "system administrators" are mostly lost _with_ a GUI. The state of IT competence that you can routinely find in the OT field is a disgrace. I think you could kick out something like 50-80% of these people and productivity and quality would improve.
Maybe you should get them OFF the UNIX farm (Score:2)
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.
Re:Maybe you should get them OFF the UNIX farm (Score:4, Interesting)
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.
Yep. Depends what you want, too. I screwed around with a few different mp3 players, besides xbmc on my DVR trying to get a repeating elimination shuffle for the house holiday music, and wound up with this instead:
while :; do find /storage/music/holiday_mp3 -type f -print0 | shuf | xargs -0 -n 1 mplayer ; done
running on a screen(1) on the dvr. The only downside is that the folder is hand-curated because I couldn't get id3fs to do what I wanted because only the very latest Clementine can store ratings in id3 tags. Next year that'll be different (not that I need to buy any more holiday music...).
Anyway, the command line does exactly what I want and I don't have to go submit an RFE to the various mp3 players or write such a patch myself. Obligate-GUI users might just have to accept "I can't do that". Unix lets you combine tools in new ways - GUI's let you easily do things that the GUI developers have already thought of (and to be fair, worked out all the steps involved for you).
Need motivation? Salary. (Score:2)
>> 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
The command line is more efficient (Score:3)
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.
Simple (Score:3)
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.
Best course is to give them working examples (Score:3)
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.
Computer Science students (Score:4, Insightful)
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.
Re: (Score:3)
Your notion of "worth" is kind of amusing.
Imagine for a moment how many children are growing up now with iPads and Android tablets and probably won't be using keyboards at all. Using the command line is as arcane as using punch cards, and inevitably they will be phased out.
For every ipad waving shop assistant scanning the barcodes on products, swiping your card down the side thingy and selling you the goods, there a poor sod somewhere with a keyboard typing in the product descriptions and barcode numbers so they can be printed on labels to be transacted keyboardless later. The keyboard is still part of the process, it has just been removed from the sight of the consumer.
Unix is powerful (Score:3)
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.
Not just command line (Score:2)
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 v
Pipes (Score:3)
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.
Same Old Programmer-Dictator Bullshit (Score:2)
Provide an outstanding GUI with an outstanding migration to the command line.
Stop being arrogant.
No Need (Score:2)
A step backward (Score:3, Interesting)
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.
Re:A step backward (Score:5, Insightful)
Wow... Just wow...
Expanding on your example, what was the MacOS way to set the color on 7,000 items, out of 10,000 that were in that location? Did the GUI tool that you are so certain is the "One True Way" provide an easy way to do that?
GUIs may be great for the type of work you do, but I assure you, there is a LOT of work to be done for which GUI tools are absolutely horrible.
HTML (Score:3)
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.
Challenge Your Students (Score:4, Interesting)
stepwise! (Score:3)
Pipes, loops, sed, awk (Score:3)
Re:Command Line Not Necessary (Score:5, Insightful)
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.
Re:Command Line Not Necessary (Score:4, Interesting)
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.
Re:Command Line Not Necessary (Score:4, Insightful)
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.
Re: (Score:2)
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.