[sf-lug] IBM selling Linux computers
Rick Moen
rick at linuxmafia.com
Mon Dec 8 12:53:08 PST 2008
Quoting Jesse Zbikowski (embeddedlinuxguy at gmail.com):
> I guess Jef Spaleta over on LWN would agree with you here.
Judging by a number of LWN comments, Spaleta seems to have a lot of
people accusing him of trolling on distribution-specific (Fedora and
Ubuntu) online forums, including internal technical ones. I would just
like to note in passing that I _don't_ do that (or anything like it) --
and my knowledge of the IBM/Canonical/Virtual Bridges bundle is limited
to what I've seen in a couple of articles about it. Therefore, I don't
make sweeping claims of fact; I just point to several things that seem
very bad news about it.
> It's too bad that IBM's new offering is not 100% free open source
> software.
Let's put this in perspective: Practically all current Linux
distributions include some proprietary software, if only binary BLOBs
needed to initialise some adapter hardware (but usually also quite a bit
more than that) -- and thus is, in the overwhelming majority of cases,
standard Linux distributionare _are_ "not 100% free open source
software". However, what we're discussing here seems to be an order of
magnitude more proprietary than any conventional distribution -- and the
SaaS emphasis is a particularly disturbing departure.
> It may not be an improvement over running a traditional "pure" Linux
> shop, but it is surely an improvement over a straight Microsoft shop.
A "straight Microsoft shop" (so far) at least has you retain physical
custody of your data, _and_ a permanently usable copy of the necessary
proprietary code to read and write it. You _did_ get that implication
of the "virtualization layer" of VERDE, right? (Again, the
Canonical/IBM/Virtual Bridges bundle includes both local and SaaS code,
but I'm talking about the latter.) We're not talking about Win4Lin,
VMware, etc. We're talking -hosted- applications: Both the code and
_your_ data live on a centralised server -- somebody else's centralised
server -- and you pay by the month/year for access to both. You don't
even have a local copy of a proprietary app: You don't have the code
under any licence terms. It runs remotely on a box to which your access
can vanish without notice for any number of reasons, including but not
limited to the firm that owns it shutting down.
> For starters it means "standards-based email, word processing,
> spreadsheets"
And what does that term mean, precisely?
We know that IBM incorporated some code from OpenOffice.org 1.1.x into
their proprietary Java stuff. We don't know what they did with it.
"Standards-based" is a term with enough wiggle room to drive a Mack
truck through it.
> Plus if somebody learns to use a Linux desktop at work, albeit one
> encumbered with proprietary protocols, I hazard to guess they will be
> more comfortable with the idea of using "pure" Linux on their home
> computer or at another job.
> I don't want to debate hosted software vs. local installation.
Well, you should.
This is exactly the threat that has most started to overwhelm open
source in the last few years, first courtesy of AJAX, and now via other,
newer hosted-app technologies.
> How this trend plays out remains to be seen, but the clear and present
> problem is a desktop monoculture in which both software and hardware
> vendors say "We're just going to support Windows because that's all
> anybody uses".
I cannot see that running an Ubuntu desktop that exports all my real
computing to someone else's centralised computer services is better than
running XP and Office connecting to an Exchange Server. Actually, it
sounds a good bit worse, to me: less autonomy, less freedom.
(To stress again, I do not know the details of how the IBM bundle in
question uses VERDE. I just know how things _could_ work out, and have
been noting with alarm the increasing use of Linux as "thin client"
software for such setups. For example, Gael Duval has pushed one such
system recently -- "Ulteo Applications System", again based on Ubuntu --
after his ouster from Mandriva.)
More information about the sf-lug
mailing list