Forgot your password?
typodupeerror
Unix Operating Systems Programming

How Ya Gonna Get 'Em Down On the UNIX Farm? 606

Posted by timothy
from the small-useful-pieces dept.
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.
This discussion has been archived. No new comments can be posted.

How Ya Gonna Get 'Em Down On the UNIX Farm?

Comments Filter:
  • Huh, what? (Score:4, Interesting)

    by Runaway1956 (1322357) on Thursday December 26, 2013 @03:54PM (#45789659) Homepage Journal

    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.

  • by jones_supa (887896) on Thursday December 26, 2013 @04:06PM (#45789749)
    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.
  • by SgtKeeling (717065) on Thursday December 26, 2013 @04:14PM (#45789817) Journal
    Essentially this.

    I had a prof who would do all his lectures & demos from the command line.
    Need to write a short C program to demonstrate forking? Boom! Into vim and coding up a basic example in a minute or two.
    Typo in his LaTeX slides? Boom! Switch over to fix it, then recompile the slides, and on with the lecture.
    Student asks a question about a command line argument? Boom! Man pages up on the big screen.

    It was a little intimidating to see this CLI master hopping around typing crazy little combinations of letters and making magic appear on the screen, but at the same time it was inspiring. It was an example of what we could aspire towards.
  • by bill_mcgonigle (4333) * on Thursday December 26, 2013 @04:38PM (#45790017) Homepage Journal

    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).

  • Re:Several thoughts (Score:4, Interesting)

    by pr0fessor (1940368) on Thursday December 26, 2013 @04:38PM (#45790029)

    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.

  • A step backward (Score:3, Interesting)

    by Animats (122034) on Thursday December 26, 2013 @04:47PM (#45790145) Homepage

    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.

  • by Runaway1956 (1322357) on Thursday December 26, 2013 @05:09PM (#45790367) Homepage Journal

    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

  • by Cassini2 (956052) on Thursday December 26, 2013 @05:17PM (#45790431)

    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:Stop trying (Score:3, Interesting)

    by Anonymous Coward on Thursday December 26, 2013 @06:14PM (#45790935)

    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 right there, you can even recompile the kernel with your own debugging in there, you can read the other drivers, you can do whatever you please, and at the end of it, you have a tidy driver, and you know why it works.

    Guess which driver has had no issues since release? One guess, and no peeking now....

  • by organgtool (966989) on Thursday December 26, 2013 @06:17PM (#45790965)
    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.

Take care of the luxuries and the necessities will take care of themselves. -- Lazarus Long

Working...