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:
  • by rubycodez (864176) on Thursday December 26, 2013 @04:10PM (#45789781)

    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

  • Try GnuWin32... (Score:5, Informative)

    by xxxJonBoyxxx (565205) on Thursday December 26, 2013 @04:11PM (#45789785)

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

  • by Xipher (868293) on Thursday December 26, 2013 @04:14PM (#45789815)

    User error can happen regardless of user interface really.

  • Re:Stop trying (Score:4, Informative)

    by LordLimecat (1103839) on Thursday December 26, 2013 @04:46PM (#45790127)

    The "standard windows commandline" is now powershell, and it is wonderful in many ways despite its quirks.

  • Re:Stop trying (Score:5, Informative)

    by Runaway1956 (1322357) on Thursday December 26, 2013 @04:49PM (#45790169) Homepage Journal

    " 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, Informative)

    by HarrySquatter (1698416) on Thursday December 26, 2013 @04:51PM (#45790185)

    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:Stop trying (Score:4, Informative)

    by LordLimecat (1103839) on Thursday December 26, 2013 @06:46PM (#45791205)

    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:Stop trying (Score:4, Informative)

    by grcumb (781340) on Thursday December 26, 2013 @09:53PM (#45792545) Homepage Journal

    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:Huh, what? (Score:4, Informative)

    by Sarten-X (1102295) on Friday December 27, 2013 @12:04AM (#45793271) Homepage

    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:

    • It's supposedly all based around objects, but you can't natively define your own classes. You have to embed C# for that.
    • The "pipeline" passes objects from one command to the next, but there is no standard for what semantics a passed object must support.
    • Opaque objects can't easily be manipulated or constructed for debugging.
    • Commands are loaded modularly, but there are no namespaces. Collisions are inevitable.
    • No include-like functionality for scripts. You can import (with .) a modular script multiple times, but it'll run multiple times.
    • Multiple overlapping APIs. In addition to the PowerShell native commands, there are interfaces to .NET, WMI, COM, and command-line executables, any one of which may be the expected (or only) way to accomplish a given task, and of course the available features change with every revision of Windows.
    • Context-sensitive errors. Assign several kinds of Get-* results to variables, and you can check that variable safely in an IF condition. Checking the Get-* directly in the condition will throw an error if the Get-* operation returns an empty set.
    • Moving to an inner scope is copy-on-write [stackoverflow.com].
    • Far too much boilerplate to declare constants (38 characters) or globals (27 characters).
    • Symbol aliases like "%" and "?" are not obvious when reading old code [joelonsoftware.com], and text aliases are also rarely intuitive unless you use them frequently.
    • No cross-platform support whatsoever.
    • Incomplete support in older OS versions, and no upgrades.
    • No unified documentation (due mainly to aforementioned modularity hell and split APIs)
    • Whitespace sensitive [pastebin.com].
    • No native support for test-driven development.
    • No support for multiple entry points.
    • Worse multithreading support than Perl.
    • Little control over command output. Either you nitpick each command to accommodate its error, warning, and output streams, or you change the global error-handling variables
    • As with all Microsoft products, absolutely no guarantee of support beyond the current version. As soon as Microsoft decides that SuperShell is the next big thing, PowerShell will go join other abandoned systems [lessonsoffailure.com] like COM, WSH, and VBScript.

    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

How much net work could a network work, if a network could net work?

Working...