| Weblog: |
|
Real Desktop Linux, Part II
|
| Subject: |
|
Linux in the enterprise??? |
| Date: |
|
2003-12-02 22:56:05 |
| From: |
|
anonymous2
|
|
|
Mark-
Your article is interesting and I am really fascinated by the notion of Linux on the enterprise desktop. However, you don't seem to have much experience supporting Linux in an enterprise environment. I worked in several environments supporting Windows desktops over the last 15 odd years and I can tell you that the list of application types you presented is the tip of the iceberg. Productivity apps are the "easy stuff" and its inconsequential that Linux can do those reasonably well. The really hard parts are line-of-business applications of varying types and flavors-everything from stuff written on Siebel to those freaky one-off apps for calculating the rate of return on Treasury bonds.
Top that off with the need for many different "desktop" profiles based on different business roles, and you have anything but the nice, confined environment you portrayed.
Linux needs a couple of key things to be successful on the enterprise desktop. First, they need a unifying API for developers to write applications against. Without the apps, it just won't happen, and without a consistent, agreed-upon API akin to Win32 or COM, there is little incentive.
Second, Linux needs "enterprise class" software distribution and configuration management tools. Its probably closer on this front than on the API front but its not there yet. If the stuff isn't manageable en-masse,then it ain't gonna fly.
Frankly, as a hard-core Windows guy, I would really love to see Linux succeed on the desktop. But someone in the Linux world needs to take some lessons from the progress that Windows has made over the years--take the best from that and then make it "Linux-like".
|
Showing messages 1 through 1 of 1.
-
Linux in the enterprise???
2003-12-03 14:39:00
anonymous2
[Reply | View]
|
Showing messages 1 through 1 of 1.
|
1) The business applications stuff (e.g. Siebel, etc.): Virtually all of that has been re-written into Java, or is accessed via a terminal program client on a mainframe or via a web browser, over the past ten years at the major Fortune 5 companies that I am familiar with. This stuff runs as well on Linux as anywhere else.
2) Unified API: Linux *has* a unified API. It's called POSIX. Linux implements the entire POSIX API. Linux has two GUI API's (GTK+ and QT/KDE), but since both are installed on every Linux system in existence today, that's irrelevant. When I was part of a team that wrote a major enterprise application for Linux, we used GTK+. We could have used QT just as easily. It just didn't matter.
3) "enterprise class" software distribution: Unix has had this for years, and Linux is just a re-implementation of the Unix API. All the "enterprise class" Unix software distribution software is also available on Linux. Google runs tens of thousands of Linux nodes to search the web, surely you don't think they're doing software distribution *by hand* on those tens of thousands of servers?! Personally, when I was managing several hundred Linux and Unix servers, I used 'rsync' and ssh to handle the software distribution. This required about 30 minutes of scripting time on my part, after which software distribution was a case of pressing a button (I could have automated it, but we didn't want to do that for reasons of quality control -- software didn't go out until it'd been vetted on a test setup).
4) Configuration management tools: I'm not quite sure what you're talking about here. Large-scale Unix and Linux deployments are comprised of entirely identical systems, to the extent that even every byte on the hard drive is identical (with the exception of swap file and /tmp areas, of course). Anything user-specific lives on the server. There's no configuration to *MANAGE*. I can log in to any workstation on our network and be at my desktop. When I was managing a network of several hundred systems, I kept some spare cloned hard drives and systems hanging around. If a user's system went down, it was a case of go to the user's desktop with a new system on the cart, yank the old system out, put the new system in, turn it on, and after it finished booting the user was back up and working with her desktop and files and all.
5) Desktop "profiles" -- all Unix/Linux user management is done from a centralized location. All non-standard Unix/Linux software is installed in a centralized location (on the file server). Typically providing for different desktop "profiles" is part of the standard process of creating a user, where you decide what user groups he's going to be a member of, and from thence Unix enforces the access priviliges (if he's not a member of the group that can access CAE applications, for example, he doesn't even *see* the CAE applications or the directories that hold them, much less be able to run them). The Linux/Unix machines themselves are bog-standard with a standard software load that does not vary from machine to machine -- everything that is user-specific lives on the server, and a user can go to any workstation on the network, log in, and be at his desktop with his settings and his applications.
Look, us Unix geeks were doing this with Sun equipment back in 1989. Linux is no different from any other Unix when it comes to ability to manage large-scale deployments -- it's been done, it's old hat, there's hundreds of thousands of Unix sysadmins who could do it in their sleep. The fact that hard-core Windows guys know nothing about this is a testament to their ignorance, and has nothing to do with the limitations (or not) of Linux.
BTW, the biggest issue I have with going to Linux workstations rather than a proprietary Unix workstation: Maintaining standard system configurations. Unix hardware tends to remain standardized over a long period of time. But if I buy a video card today for a PC, it will be discontinued within three months as the manufacturers continually improve video cards. What I end up with, as hardware attrits, is a mish-mash of hardware rather than an easily-administered standard configuration. But the Windows guys have the same problem, so it can't be said that this is a reason to choose Windows over Linux.