Strategies for Efficient IT at UC

Thin client computing are a mechanism that allows lightweight, efficient user-side displays to run software that they get from a server. It is much like the existing browser paradigm but it allows an entire desktop and application suite to be run on the server and be displayed on the client. The clients can be specialized low-power devices or PCs, with or without disks.

That the client devices can be locked down to specified levels recommends thin clients for any computing for which data security is a concern. FISMA and HIPAA requirements are already becoming concerns and thin clients can be configured to disallow writing to local CD drives, portable disks and thumb drives. In other situations where these devices need to be available, a central permissions configuration file can allow certain users to use them.

Thin clients also allow transparently portable desktops since any device which can connect to the server can display the user’s desktop with all her personal configuration intact. This is possible (or can be disallowed) to allow access for home use if the network bandwidth allows (I use VNC to administer a Macintosh in Nova Scotia from California; the NX technology is even faster).

For the great majority of administrative and classroom computing at UC, we should be using such thin clients rather than the usual fat/obese Windows and Macintosh clients. This technology is well-established, robust, more secure than Windows or Mac, easier to maintain and roll out, more energy efficient, and much lower cost. If many other first, second, and third-world countries can use it effectively, we should certainly be able to do so as well.

Linux thin clients can be implemented so as to run completely on a server, or to obtain their Operating System image from the server, depending on how much computation needs to be done on the client CPU. This allows classes that require heavy computation on the client side (engineering, statistics) to have a full client OS to run the computations on the client CPU, or act as a display for server-side software.

For distance learning, on campus or off, the NX protocol from NoMachine allows all platforms to connect to Linux servers which can provide all OSS and many $oftware products, but without the additional cost load to access them. MATLAB, SAS, Mathematica, SPSS, and many others can be run efficiently on single servers to service 10s of clients per CPU core. This is standard operationg procedure on many research clusters, which are required to run at peak efficiency.

The OSS approach encourages self-sufficiency and pays off especially with widespread use - exactly the case we see in UC, with its 10 campuses. Configuration is often done by human-readable configuration files that can be easily and freely shared. OSS tends to be simpler than proprietary software and once one group adopts and understands it, it can be easily (if not trivially) rolled out to further groups with little extra cost. This is definitely not the case with $oftware.

Increasingly, especially for infrastructure software, an OSS package is one of the top performing products. By infrastructure, I mean anything with server in the name - servers for:

In 2003 & 2004, California and Oregon promoted Open Source as part of their efforts to increase government efficiency. Both efforts were largely defeated by Microsoft lobbying, but the attempts to introduce this legislation still echo. See below for other governments which have stated that they will no longer use Microsoft products due to national security concerns.

If we use $oftware tools and libraries to develop our own software infrastructure, we will be wedded to a specific vendor for the life of the software (which can be many years - Cobol anyone?). This entails yearly fees and a subserviant relationship with that vendor once we have deployed anything developed with its products. So developing things with Microsoft products, Cold Fusion, Oracle, etc (some of which are very good, hence the attraction), while it may look like a good idea at the time, is the very definition of vendor lock-in.

OSS provides many of the same tools and libraries, in many cases superior, or of equal quality. OSS has so many software development tools that it becomes a question of How many complete Integrated Development Environments do we need?. Only when there is compelling need and a written evaluation that describe exceptional conditions should we consider such $software tools going forward.

This approach is echoed in one of the proposals from the UC Committee on Finance. It does not explicitly state a preference for OSS (nor should it) but it is entirely about efficiency - how fast, how scalable, how costly, how cost-effective a solution is.

Even in the end-user desktop arena, OSS applications are increasingly competitive with proprietary ones. And contrary to many expectations, you don’t need to be running an OSS Operating System such as Linux, BSD, or OpenSolaris to use OSS applications. The most popular OSS applications are [those used on MS Windows] (although freedom from most MS products should be the long-term goal).

More digital data is being collected faster every day. The Large Hadron Collider will collect more than a GB/s during experiments. Social networking data, clickstreams, and network data is nearly unimaginable. Satellite data is streaming down at TB/hr. Even data from personal lab machines like a genome sequencer is overwhelming - the processed output from an Illumina High Throughput Sequencer can be 100s of GB per day. And you can’t analyze it with Excel. Or rather you can, but it would make you want to chew off your fingers and use the bleeding stumps to gouge your own eyes out.

A university that wants its students to be facile in the ability to analyze modern amounts of data will assure that they have access to, and learn how to use Linux and its data utilities.

There are good reasons why 92% of the world’s top supercomputers run Linux - the remaining 7% run some version of the similar BSD/Unix; only 1% runs Windows (and these are largely funded directly by Microsoft). This is the market share that matters for research.

Why are we spending significant FTEs essentially acting as sales people for $oftware vendors when there are Open Source alternatives that are quite comparable? The $oftware vendors should actually be paying US for what we are doing - introducing new students to their products so that they’ll be uncomplaining customers for post-graduate life. We should be enlightening students as to their software options, not acting as Enablers for Microsoft. If $oftware vendors want their $oftware on our campuses, they should PAY US for the opportunity, not the reverse.

(Incidentally, OSS bypasses the whole issue of license servers, EULAs, copy-accounting, etc.)

It will not be possible to end the use of $oftware, but the default should be to consider OSS and WHY we need to pay for $oftware, rather than to thoughtlessly cut a PO for yet another round of unnecessary contractual subservience.

Both Russia and China have released statements that they plan to remove Windows from their state computers over the next 4 years for security reasons. Also Google. And now that Windows has contributed to a major national security catastrophe for Iran, probably they will as well. UC, on the other hand, continue to pay for this notably insecure software and then pay extra for the anti-malware software that supposedly protects us from that insecurity. This is nothing but expensive comedy.

When we continue to use Windows, we should use as much Open Source and Free software as possible. There are certainly some cases where it may not be possible to rid ourselves completely of Windows, but in those cases, we should be be encouraging the use of OSS on Windows. There is a significant pool of such software and since most new software for UC’s infrastructure is Web-based, the underlying platform shouldn’t matter much.

Besides the cost savings of OSS, appropriate hardware can save considerable energy and space, obviating the need to construct much more expensive data center space. 1U (1.75"), 48-core nodes are available for ~$7K. Two such machines can replace an entire rack (44Us) of 4 year old machines, are significantly faster, and use 1/10th the energy. Such 48core machines can probably host a hundred Windows virtual servers (but see immdiately above about the use of Windows in general). A single such machine, configured appropriately, could probably supply ALL of UC Irvine’s web services, for example.

We need to document why we make decisions and how those decisions turn out. We need to make those documents public to assist other campuses in making the right decisions & avoiding expensive wrong ones. At the very least, not writing down your reasons for signing off on a multi-year, multi-hundred thousand dollar committment is bad management, not to mention an abrogation of responsibility, and a loss of paid-for institutional knowledge.

So let’s encourage people to:

While it’s certainly good to plan ahead, be rational about it. Encourage the use of the minimum software for a job rather than the maximum. Few people actually need to use even MS Word to transmit information. What they really need is a simple HTML or text editor. We need to be exchanging information, not proprietary software headers.

When evaluating infrastructure software, concentrate on the the features we need, not measuring the length of feature lists. More code leads to more bugs, more cost, more configuration, more to read, more to fail.

Incidentally, OSS can be fully evaluated without legal review, RFPs, cutting POs, etc. Since it’s Open Source, the full version (not a time-limited or crippled version) is available to evaluate to see if it is appropriate. At the very least, using the OSS version allows you see what a $oftware version has to exceed to be worth paying for.

I’d be happy to suggest Open Source alternatives. Departments and Schools who don’t want to use Open Source should be welcome to continue to use $oftware and should be welcome to support it out of their own pockets. If Google, Amazon, Kmart, Target, IBM, Apple, Oracle, Cisco, and even Ernie Ball (the guitar string manufacturer) can be profitable and save money using OSS, why can’t we?