Slashdot Mirror
Pitfalls and Options For Business-Desktop Linux
swhiser writes "Tom Adelstein dispassionately surveys the remaining fixes that will put desktop Linux through in the enterprise. Peer-to-peer networking, functional printing, laptop support, single sign-on to Active Directory and a better Device Manager (with a driver-get mechanism) are among the things companies are asking for. He says, 'The Linux desktop could fail if companies continue to pilot programs and conclude that it's less trouble to buy Microsoft. Everyone loses in that scenario.'" Pre-loaded systems are no longer a pipe dream or an obscurity, though; read on for one reader's mini-survey of Linux systems from large computer vendors.
Acidus writes "I called around today to the big OEMs (Gateway, Dell, HP, IBM) seeing who offered systems with Linux pre-installed, and the results were good. 3 of the 4 offered Linux on workstations. While no one offered Linux preloaded on laptops, Dell has some references nn how to install Linux on their laptops, while IBM has a scattering of docs on their website about installing Linux on systems. The reps at Dell, even though they have a series of Linux workstations, had to ask me what Linux was, and how to spell it. "Is that L-Y-N-I-C-S?""
From the article:
"Broader WiFi card support needs to be introduced to Linux. WiFi card support for the large and important group of laptop users hardly exists. The expedient solution here would to use something like Linuxant's DriverLoader which has the elegance of being a single point solution that's applicable to the great majority of user/device scenarios."
This is the single reason that stopped my from installing Linux on my laptop. Until I discovered ndiswrapper, that is, which wraps windows wireless drivers...
Now if ndiswrapper worked out of the box, that *would* be a step forward.
A stable driver API is one of the things that is much needed. This is even a problem for server environments. In a perfect world, all drivers would be open source and easy to include, but that is just a pipe dream at the moment. There is a need for binary only drivers for several reasons, where a) support and b) it includes patented/licensed code are two of the biggest.
As it is now, Linux on the Desktop is only feasible for very specific desktop environments. And on laptops? Power management and wireless networking are not automatic, and with several different hardware versions and with users that roam the world... it's a pain.
Linux is getting there though, but slowly. The support cost for linux on desktops and laptops in corporations today would be too high I fear.
//TheToon
We use NIS so that workstations are completely interchangable. Had an EE harddrive meltdown, grabbed a spare machine, ran the kickstart, and the user logged back in via NIS within 15 minutes with no data loss! Could have had him backup instantly if he wanted to go to a spare office.
I can't believe how much easier workstation admin is now that we use Linux.
This way to the egress...
http://h10010.www1.hp.com/wwpc/us/en/sm/WF06a/3219 57-64295-89315-321838-f33-395654.html
- Just my $0.02, take with a grain of salt, your mileage may vary.
What's the point of using Linux, 'just because'?
Cost of licensing? Upward compatibility? Freedom of choice? Hardware requirements? Ability to customize workspace? Freedom from Microsoft inspections, like the ones MS has forced on city buereaucrats before? Better security?
Do I need to continue? I can...
Check out my sysadmin blog!
Risk vs. reward for the decision-maker is going to be a key factor. If I am a CIO or CTO I am likely unwilling to bet my career on the risk of the unknown. There are possibly great cost advantages to deploying Linux on the desktop in the enterprise, but if that's not a primary focus area for the head of corporate technology then it is better to stay with what is know to work. Security factors are another big consideration, but in both of these cases it's a bit of a leap of faith. Windows is the known quantity and there is a massive budget in place around it. In other words, the main technology decision-maker is not likely to be rewarded as a hero for the advantages that Linux might bring, but would be sacrificed for any unforeseen downsides. One does not have to be too risk-averse to see why Microsoft remains entrenched.
The only thing that I am waiting for is a Linux Domino Client and Admin Client (not iNotes). One would think IBM could get this taken care of.
Sure... like just
- keep fighting terrorism
- losing indivdual freedoms
- stop thinking
For christ sakes... just because something isn't point click and done doesn't make it any less viable.
1. Windows Network Neighborhood visibility and UNIX/Linux visibility in the same panel.
XANDROS 2.0, Lindows, Lycoris, MEPIS
2. Active Directory password management which includes single sign-on and password expiration policies.
Novell Evolution embraces mail, calendar and address book standards to ease data sharing.
Supported mail protocols include IMAP, POP, SMTP and Authenticated SMTP, as well as Microsoft Exchange 2000 and 2003. Novell GroupWise support is currently in our development branch.
3. Interoperability with Exchange 5.5 and Exchange 2000.
See above
4. Font compatibility with Microsoft Office and Openoffice.org and/or StarOffice.
Crossover
5. Windows Terminal Server clients using RDP out of the box for home grown applications and special Windows applications.
Xandros, Lycoris, SUSE, RedHat... or just install VNC...
6. Ability to click on a file in a Windows or Samba share and initiate the associated application.
Fille association is not a roadblock. Simply a minor configuration issue.
7. Device management for hardware compatibility.
XANDROS 2.0, Lindows, Lycoris, MEPIS, RedHat, Suse
8. Compatible Windows Media player Codecs.
Crossover, MPlayer, XINE
If you read a lot of Polish press - I do - you will often find this kind of reasoning, especially whenever Polish national soccer team coach explains his latest failure (and in Polish soccer, there's always a failure to explain). My favorite is "we actually won the first half, but...". There ARE some important issues with Linux in corporate environment - laptop support, printing and device managing among the most important ones. Don't comfort yourself with easy explanation that corporations reject Linux migration only because someone is "tech-knownothing". Maybe they know something - namely that the overall cost of the whole hit-and-miss game with installing Linux on laptops might cancel the benefits of such migration?
The way Linux will make inroads on the corporate desktop is not by some big push to get it over the top, but by steady, incremental improvement. Not to mention any names (lest I be accused of flamebaiting) but targeted super-projects will not work.
Reacting to the perceived needs of corporate users is fine, but that's not a good fit for the Open Source way. You need someone who has enough pull with a developer to get a single feature or bug worked on. In the early stages of a project, that person is the developer or people he knows personally, with the circle expanding outward as the project grows.
Companies with perceived needs for a Linux desktop can sponsor development of those needs. Sure, the rest of us can try to guess what to create based on surveys and hearsay, but it's way better for the people close to the problem to come up with the solution.
The best way to promote Linux on the desktop is with apps. If a killer app appears, people will adopt Linux and be motivated to fix whatever perceived flaws they find.
sigs, as if you care.
Article Myth: Linux doesn't do P2P networking.
Fact: Linux just doesn't have a Net Neighbourhood/Places GUI. There is nothing that requires Linux (or BSD) to have to have a domain controller. In the past week, I've provided support in online forums where the problem is stated that on Windows they can't see the other Windows box - because they are using Network Places, which relies on NetBIOS and can take up to 45 min for a computer to show up in. This is the reality of the userbase - GUI.
Myth: Printing sucks
Fact: No argument - it sucks. No central tie-in into the system so all programs use the same printing config. I shouldn't have to setup CUPS, and then setup each and every program I want to use to use CUPS.
Myth: Laptop support is non-existant
Fact: There's sites dedicated to it; as long as the hardware is available, for the most part there is no trouble booting linux on a laptop. Rather, the article says that there's just not enough wifi support in laptops...
Myth: No Terminal Services client
Fact: rdesktop worked fine for years now
There's other issues, but those are the most visible. Not to say the article isn't overall wrong in it's assertion - that in order for Linux to get to the point where drivers are listed with hardware along with Windows, the hobbyist programmer mantra of "it works for me, so fsck you" keep stagnating Linux where it is today - where it's been for the last couple of years ever since "this will be the year of the Linux desktop...No, THIS will be..."
It's not acceptable to have to install 3+ programs in sequence to get an app to work - bundle the bloody stuff already, quit being lazy. Funny from the crowd who chastizes closed source about how bad their software design is...
Tech know nothing PHBs know something you don't: if it's going to cost 2000 man hours of work at a $30 an hour average to redesign internal systems, templates, and procedures to work on a non-Microsoft system, that more than wipes out the cost of licensing the desktop systems. That doesn't include the cost of the lead up in which you have to test, deploy, and integrate all of your servers and desktops, plus the lost productivity from people needing to be retrained or retraining themselves on the shortcuts to use Linux.
People here act like a platform migration of this scale is simple as flipping a switch, and I think that really highlights how little experience in practical technology the Slashdot collective really has. You can reformat your system at home and install Linux in an hour depending on options and system speed. It's not that simple when you're talking about a business with 20 locations and 5000 workstations to migrate. It's not that simple when you have internal customer service apps to migrate. When you have internal template and procedures to rewrite. When you have to audit your hardware to ensure compatibility and then repurchase anything that might be too much hassle to fiddle with.
Migration to Linux isn't speading like wildfire for the same reason Windows shops don't jump ship to run to the superior UNIX systems even when that's cheaper: it's not as simple as you people think. It's not free. It's not even necessarily cheap. If it's going to cost you $250,000 to migrate and you're only going to be saving an average of $25,000 in license fees and support each year, it will take you ten years just to break even. Linux is not a magic bullet. You people whine and whine like little babies, but I'm willing to put my money where my mouth is that 99% of you only whine because you don't have the slightest clue what you're talking about. And the more you whine about your complete and total lack of knowledge, the more steam you give to other companies to muscle in on place where Linux could be making inroads.
What you need to do, if you really want Linux to succeed that badly, is address its single biggest shortcoming: the difficulty in migrating systems from Windows to Linux. No, it's not your fault that it's so hard. Microsoft intentionally makes it difficult to leave the nest. However, since you keep bitching about it, it IS your problem.
Quit being a whiny little bitch and contribute some code, documentation, consultation, or just shut the hell up. Your whining isn't going to change the fact that Linux just plain isn't a good solution for a lot of shops, but if you'd actually do some freaking work you chould change that.
Alito: A vote for Alito is a punch in the eye to put that bitch back in her place!
Well, when looking at the above list, I can't help but be frustrated. The majority of those things are already available. Let's go down the list item by item:
Windows Network Neighborhood visibility and UNIX/Linux visibility in the same panel.
Huh? What are these people using, FVWM? With Samba it's easy to set up a Windows network on a Linux box that can be viewed on both GNOME and KDE. In the same place as Windows shares. GNOME (and probably KDE, not sure) can even display different manual networks, such as FTP servers in its network place.
Active Directory password management which includes single sign-on and password expiration policies.
Can't comment on this, I'm not familiar with Active Directory.
Interoperability with Exchange 5.5 and Exchange 2000.
Am I completely crazy, or can't Ximian Connector & Evolution already do this?
Font compatibility with Microsoft Office and Openoffice.org and/or StarOffice.
Again, I ask the same question -- "huh?" -- if you want to use the Microsoft core fonts, install them! It's not that hard. It's not a fault of OpenOffice.org or StarOffice, it's just a case of the fonts that come on a Linux distro by default -- there's not Arial, Times New Roman, etc. because those are Microsoft fonts and Linux distributors can't distribute them. Might I ask a daring question: why don't Windows users install the Bitstream Vera fonts? I find it annoying that "Microsoft Office" doesn't have compatibility with "OpenOffice.org" (even though the office suites are not the problem in the first place).
Windows Terminal Server clients using RDP out of the box for home grown applications and special Windows applications.
Again, excuse my ignorance, but ... what's wrong with VNC? Why not switch to an open solution?
Ability to click on a file in a Windows or Samba share and initiate the associated application.
I don't agree that that's the problem: KDE (and GNOME maybe, I'm not sure though) can open the desired application just like normal but it does it in an undesirable way, IMHO -- it doesn't open the file from where it is, it copies it to your home directory and opens it from there. I think that that should be improved.
Device management for hardware compatibility.
That's very vague. Do they mean a GUI? If so, what's wrong with distro-specific hardware GUIs such as YaST (which is very good IMHO). A universal distro-independent solution is not a good idea, as is exemplified by LinuxConf. If you want a GUI for hardware management, pick a distro that has one.
Compatible Windows Media player Codecs.
That's the dumbest one yet, and the answer's right here: http://www.mplayerhq.hu/
Let me get this straight.
Gradually migrate desktops to Linux. Make them do sign on and authentication to a Windows server.
End result: Linux on the desktops, Windows as the server.
That way, each platform is being used for what it is best at.
Those who would give up liberty in exchange for security and DRM should switch to Microsoft Palladium!
repeat with me:
backward compatibility.
again:
backward compatibility.
backward compatibility.
backward compatibility.
got it ? it may not be important to you, but some big companies have _decades_ of data stored in their systems, some of this data only accessible through aged proprietary apps written in clipper, cobol, VB 3.0, whatever (some of those only exists in binary form. sources are long gone)... heck, once i went to a stock brokerage office and they had an access 2.0 running under OS/2 (by M$ recomendation) because access 2.0 was the only thing their PBX supported, and they had by force of law to record every phone call, internal or external.
it's easy for me or you to ditch windoze from our home machines because we don't have such worries. most of our valuable data are stored in open formats or easy-to-break proprietary ones and in small volume. now try to imagine GE. GM. Siemens. Toyota. Citibank. US gov.
i'm old enough to remember the reluctance of compnies in migrating from DOS to windows 3.0, or moving away from wordperfect. it only happend when M$ word/excell became stable enough, with reasonably good WP/Lotus 123 converters. that was between 10-12 years ago.
now that linux is starting to mature as a desktop environment, companies can start evaluating it. but since IT people in big enterprises abhors sudden and traumatic changes (it can cost them mora than millions, it can cost billions if something goes terribly wrong), they'll firts demmand a high level of compatibility. then as old applications are phased out, compatibility becomes a seccondary issue.
a friend o'mine recently said me he was stuck with windows in his small company (he's owner and only empoyee) because of some old clipper apps. then i showed him flagship and sugested that he could run the DOS binaries in dosEMU while adapting them to compile under flagship. he did that and is pretty happy. he knew about linux desktop but delayed the move because of 10 yr old clipper apps. and he's only one. now imagine GE's 300.000 employees...
What ? Me, worry ?
Mac OS X meets almost all of the criteria that the article suggests for Linux compatibility... ...except that Mac OS X is not Linux. (That, and the Windows codecs, although the popular VLC application does the trick in all but the stickiest non-QuickTime codec.
So, taking a page from both Apple and Microsoft's business handbook, what can the Linux community "steal" from Microsoft and Apple to make Linux a stronger enterprise player?
Getting things from the Apple side isn't very hard since its resources come from the FreeBSD world, which is open source. Samba works great in OS X, which means stronger integration in Linux is needed to match OS X's performance, which I suspect does nothing particularly special.
Same is true for AD authentication. Mac OS X uses a plug-in its Directory Services that understands this LDAP-variant...surely this is something that would work in Linux, or does it lack a refined mechanism for handling multiple directory services as OS X?
Ximian already provides Exchange compatibility in its mail product, and Exchange 2000 works with IMAP provided that Outlook Web Access (WebDAV) is running. Special features of Exchange (and its Outlook client) may be missing, but Mac users are still missing features from Entourage, the successor to the Outlook client on Mac OS X, so this is not quite the biggie. Linux/Intel users can run VMware (as Mac users would run Virtual PC) to use the actual Outlook client if needed.
The Microsoft Office component is a toughie. Mac OS users have a genuine Office client. Microsoft knows that holding back creation of a Linux client would sap power from its enterprise drive.
No easy answers in this, really. I think, however, that Linux could use a central business owner, although I know its nature makes that impossible. But wait--isn't that what Apple's doing with OS X by licensing or using BSD components?
What if a company licensed a Linux distro and took the reins to make a Linux-compatible OS with the same functionality, but also the "one-click" simplicity, application strength, and security that Mac OS X enjoys in its Mach/BSD fusion?
Of course, we know that this appears to have been done, with Red Hat, et al. But has it really been done well?
Vos teneo officium eram periculosus ut vos recipero is.
If you want to migrate away from windows you need to start divorcing MS. Take a look at how Novell is doing their internal migration for example.
1) Do away with office. Replace office with openoffice the desktops (still windows).
2) Do away with outlook/exchange. Lucky for novell they have groupwise.
3) Set up a CMS system (novell used thei ifolder product) which keeps track of documents the employees create. This trains the employees to go to an abstract location for all their documents rather then "my documents".
4) Set up a desktop distro with open office, groupwise, ifolder and you are done.
It could be done with small gradual steps. Novell has done it, IBM is doing it and neither one of them is a small company.
evil is as evil does
Linux has awesome DB engines readily available - unquestionably - but that power is not accessible to your average office cube dweller. That is the genius of Access; simple DB applications are easy, while amazingly complex ones are still possible, given patience and time. And that is how many of the more complex Access apps are developed; more functionality is added over time, as needs change and applications a tested against daily experience. This is easily done, because - Access is easy. Get that right, and a whole new class of businesses could come over to Linux. Without it, I think trying to sell Linux into the small business venue is just pissing into the wind.
One other area where Linux falls down is input methods for other languages. For instance, try entering Korean in a Linux system set up for English, using Open Office. Good luck trying. Ami (the app that is supposed to enable Korean input) doesn't even begin to work. You end up having to hand-insert each character from a font table, which is numbingly slow. It is awfully hard to share Linux in this direction or that when you can't get the thing out of its English entry state. I have not had occassion to try to enter Chinese yet, but I don't look forward to it based on my experiences with Korean. Windows, on the other hand, "just works."
Don't get me wrong. I'm a huge Linux fan, but these things have been brick-wall problems for my companies (three of them.) I think other business owners have very likely run into the same issues.
I've fallen off your lawn, and I can't get up.
I think Linux printing is ready, but just recently. That means that things don't come preconfigured to use CUPS yet, which means there's significant setup effort.
/sys/bus/usb/drivers/usblp/*/../product, and look up the right info. Then it will look in /sys/class/printer.
The way things go with Linux is that things start out unsupported. Then they get flawed support. After a bunch of development, the right solution is made, but it requires a lot of configuration to set everything up. Then it comes preconfigured and everything just works.
(When I started using Linux, in '96, in order to get X working, you had to write a mode line with the timings you wanted to get things just right. Then X started coming with mode lines for all the nice modes. Now you don't need mode lines at all; the server will come up with the right information itself. Imagine my surprised when my new X server, with nothing in the config file other than my monitor's capabilities (old monitor; new monitors report their own capabilities), instead of coming up in 1280x1024, came up in 2048x1536 because that's what it could do.)
Today you have to tell CUPS what your printer is. But tomorrow, you won't because the software will read
The article is thinking in the microsoft way about getting drivers. Why should you have to click on an unsupported device in order to get a driver for it? Just try to use it and it should fetch (or build, or just load) a driver. If it doesn't know what the device is, it should use a cddb-like system to report the lack of support, and let users who get it working report what they did.
Is OpenLdap kerberized? (in other words, can you tie Kerberos security to permissions on the retrieval and setting of LDAP attributes?) (hint: the answer is NO)
Er, the answer is YES. I have it working here. You can use the Kerberos tickets to authenticate to OpenLDAP and have ACL's in the LDAP server to define the permissions. It's done trough SASL and it works transparently.
And because of this, OpenLdap authentications solutions are NOT secure, as they pass credentials in CLEARTEXT. Yes, you can use certificates but now you've introduced the thorny issues of key distribution.
Not so. Understand that this is however seperate from the availability of Kerberos. Other methods can be used to pass the crendentials (Digest MD5, etc). Aditionally you can force the use of SSL, so even cleartext passwords are not problematic. You can actually define that the server won't accept cleartext from non-TLS connections.
I use OpenLDAP integrated with Kerberos and both integrated with the authentication and authorization of several different things (including machine logon). I also have a cross-realm trust relation between AD and the Unix LDAP which allows AD users to use their Windows tokens in the Unix environment (user "bar@WINDOWS.NET" assumes "bar@UNIX.NET" identity trough cross-realm). Aditionally, as a last resort for use in non-kerberized apps one can use the password '{KERBEROS}boo@UNIX.NET' or '{KERBEROS}boo@WINDOWS.NET' to make the LDAP server check the user supplied password in the Kerberos server.