Slashdot Mirror


InfoWorld on Switching to Linux

brentlaminack writes "The latest Infoworld is running a lengthy piece about The Real Cost of Switching to Linux, where it makes sense and where it doesn't. As one of their columnists points out, the debate has switched from "if" to "where". One of the big wins for Linux was in the area of remote administration. Specifically noted was ssh. Also of note is the shift in calculating cost from TCO (Total Cost of Ownership) as has been calculated in the past, to ROI (Return on Investment) that focuses more on what you can do with the technology to get work done."

6 of 319 comments (clear)

  1. Long term benefits by TWX · · Score: 5, Insightful

    Thing that I've noticed is that if a large organization gets into Linux, even if they buy it, it's theirs for the duration and all of the upgrades that they can work into it, instead of requiring either yearly site license fees or massive payouts every so many years for new versions of software to do essentially the same thing. Even paying a consulting company or services company to deploy Debian would make sense in a way, as long as the apt server were the organization's, versus a public server, so that as long as someone is maintaining the package database on the local apt server, they can keep updating the workstations.

    Large organizations usually have some form of IS department, so instead of paying them to run around and fix Windows Millennium or XP problems, pay them to keep the network deployed OS current, and fix the bulk of the problems from their desks.

    --
    Do not look into laser with remaining eye.
  2. Remote management w/ SSH. by Black+Parrot · · Score: 5, Informative


    > One of the big wins for Linux was in the area of remote administration. Specifically noted was ssh.

    I admin ~25 machines remotely, most of them in a room that I don't even have access to without special arrangements. With SSH I can do that without ever having to make those arrangements, except in the case of a major upgrade or a hardware failure.

    You can write scripts that will take a shell command as an argument and then step through all your machines executing it on each in turn, greatly simplifying remote management.

    You can also use pipes and redirects to channel information between processes on the remote machine and your local machine, e.g. -

    ssh remotehost cat /proc/cpuinfo | grep flags > temp.txt
    will put the flags in temp.text on your local machine, but -
    ssh remotehost "cat /proc/cpuinfo | grep flags > temp.txt"
    will put it on the remote machine instead.

    Or, if you want to do all the work on the remote machine and only redirect the output to your local machine, use -
    ssh remotehost "cat /proc/cpuinfo | grep flags" > temp.txt
    and the grep will actually execute on remotehost.

    The example is trivial, but you can do some powerful sysadmin stuff that way. However, there are a few gottchas: a few services crap out if you try to restart them with -
    ssh remotehost service xyz restart
    so you do have to be careful about some things. (Sure wish someone would figure out what causes that and fix it!)

    --
    Sheesh, evil *and* a jerk. -- Jade
  3. They still don't get it by passthecrackpipe · · Score: 5, Interesting

    "The jury is in. After years of experimentation with Linux in the enterprise, customers, analysts, and vendors are starting to sing a consistent tune about where Linux makes financial sense and where it doesn't."

    They still don' t get it. Even though the article is moderately positive, any article about Linux that starts with "the Jury is in" was written by someone who does not fully understand the dynamics of Open Source. How can "the jury" be "in" on an environment that changes so rapidly as Linux does? How can you say for certain where Linux has a role and where it doesn't? A move in the right direction, but the hacks still need some educating.....

    --
    People who think they know everything are a great annoyance to those of us who do.
  4. Chance of rain: slight... by TWX · · Score: 5, Insightful

    If you're developing on it. If you're using it for regular users who need email and web and word processing, it doesn't matter what the licensing is. Your memo written in ABIWord doesn't have to contain the GPL.

    And if you're developing, there are commercial libraries available to you. There are BSD-licensed libraries too. You don't have to use Stallman's libraries, you can get them elsewhere. Hell, IBM even builds compilers, as does Intel. The entire point of GPLed stuff is for it to remain for everyone. If you don't like that, build it yourself, buy it, or find another non-GPL one.

    It's not impossible to do this. It just takes brains and research. I'd rather sink my money into that than into a mindless purchase of a product that goes "BOOM!" far too frequently and forces one into paid upgrades.

    --
    Do not look into laser with remaining eye.
  5. Include BSA raid in TCO for Windows by ODBOL · · Score: 5, Insightful

    I haven't yet seen a TCO study that includes the risk of a BSA audit in a Windows shop. The TCO for running Windows should include the cost of insurance against the disruption of a BSA audit and the penalties paid for apparently unlicensed software.

    --
    Mike O'Donnell http://people.cs.uchicago.edu/~odonnell/
  6. Re:What I don't understand by nathanh · · Score: 5, Insightful

    I understand that Linux is the new darling of the tech industry, but why do reviews like this completely ignore operating systems likee FreeBSD (which out performs Linux in several serving tasks, and is in general more mature)?

    Numbers. Simply numbers. It's the same reason that nobody reports on any of the 100s of fringe OSs with user bases measured in the thousands. Linux has more users and therefore gets the most attention. FreeBSD had its chance to have the biggest user base but it lost to Linux. This was despite a significant headstart in the form of 386BSD. There are at least six reasons I can fathom as to why this happened.

    First, the AT&T lawsuit against Berkeley (1992) scared a number of developers away from 386BSD at a very critical time in its evolution. Why invest time into developing 386BSD if AT&T was just going to steal your hard work? And "steal" is the right word here; it really would have been theft if AT&T had won because the 386BSD developers would have lost ownership of code they'd written themselves. Developers were scared away from 386BSD and towards Linux, which was seen as being "litigation-free". The parallels with the claims made by SCO today are frightening.

    Second, the Jolitzes. They were custodians of 386BSD and Bill was notorious for being slow to accept patches (1 year of unapplied patches). The formation of FreeBSD was essentially the "Gang of Three" getting frustrated with the slow pace of 386BSD development. They combined 386BSD plus the existing "patch kit" and sold the result as a CD-ROM. This was unfortunately too little, too late. Linux had a 2 year headstart on FreeBSD by this stage. Also the splintering pissed off a number of developers who stopped contributing to both 386BSD and FreeBSD. Instead they started contributing to Linux.

    Third, the license. FreeBSD advocates say that the BSD license is "more free" than the GPL but to some people (myself included) the BSD license is offensive. Nothing stops a commercial company leeching off your hard work if you use the BSD license. BSD advocates say this isn't a problem: "you wanted it to be free and now it is". The problem is I don't really want companies getting rich off my code. I want them to contribute back with more code. The GPL enforces this. The BSD license does not. In 1991, when Linux was still very much in its infancy, it managed to get more attention from more programmers than 386BSD ever managed. This was despite Linux being technically inferior to 386BSD. The license simply appeals to certain people. If Linus had used a BSD license then I don't think Linux could have ever wrested the #1 spot away from 386BSD.

    Fourth, the Internet. Linux development began at a time when Internet access was appearing in homes. The early adopters of home-Internet access were (of course) technology enthusiasts. The percentage of potential Linux developers in this group was relatively high. This meant from the start Linux had a huge base of developers to draw upon. And isn't it more fun to contribute to a brand new project than an existing project? Linux attracted the developers simply because it wasn't finished.

    Fifth, the installers. Back in 1992 (1991?) I was using Interactive UNIX at home. The software was showing its age so I was looking to get into one of the "Free UNIX" that was floating around the Internet. I'd already used (and dismissed) Minix because it was incredibly limited. I had a choice between 386BSD and Linux. The 386BSD installer required a 40MB download, a SCSI hard drive, and required me to destroy my existing Interactive installation. The Linux distribution came on 2x 5.25" floppies, supported IDE hard disks, and could coexist with existing operating systems. It was a no-brainer. Linux won because it cared about the newbie, even back then when I admittedly needed all my UNIX experience to get the damn thing installed. The FreeBSD distro didn't come until late-1993 but by then it was too late; I'd already deleted my Intera