One of the more frustrating undertakings that I have recently started is the process of cleanly integrating Linux clients with an Active Directory and Exchange 2003 environment (without third party software). This undertaking came about as part of a sub-task in at the tail-end of a large AD and Exchange 2003 migration/deployment that I served as the technical lead for.
As I mentioned in an early post, the sister-task to this was integration of MacOS X Panther (10.3) and Entourage 2004 with the previously mentioned environment. I handed this task to one my coworkers who was able to test and proof-out the solution in fairly-short order, using the native DS/Access, Kerberos and Samba 3 support in Panther. A testament to Apples hard work with regards to cross platform compatibility in Panther.
With that said, it turned out to be a major ordeal getting Fedora Core 2 to authenticate against AD natively (using native AD protocols). I will post the technical details about how I got it working with winbind in my next post. What I want to talk about here is the status of Fedora Core 2 and Linux in general.
Linux = Not an OS
Linux isn’t really an OS, per se, it’s a kernel surrounded by a lot of other open-source stuff. The actual OS is the packaged distribution of components and each “distro” is almost a completely different OS, unified by a common set of API’s and system call interface. Same parts, but assembled differently (think Cadillac Escalade EXT versus Chevy Suburban; same platform, two different vehicles).
The current 2.6 Linux kernel is not a bad kernel at all. In fact, as of the current generation, it is quite competitive with commercial kernel’s including NT 5.x and Solaris. It supports relatively fine-grained kernel locks, has a numa aware scheduler (though not memory manager) and many other enterprise level features. It’s still missing some features I would like to see, such as per-process working sets and more modularized (e.g. layered) driver model, but all in all, the Linux kernel has come a long way in a fairly short period of time.
With that said, it is the rest of the system where progress has been much slower. Of course, every distro offers a different experience, but there are some serious short comings that are carried across different releases.
X Sucks
The first, and to me at least, the most obvious problem in Linux land is X. The X Window System is just as big and horrible a mess as it has ever been. The recent XF86 to Xorg split has made this situation all the more frustrating (just ask anyone who has tried installing Fedora Core 2 in VMWare recently). Longer-term, there are just so many basic problems with X that I think the only reasonable solution is to simply ditch it.
So what are these problems that I am referring to? Well, for starters, non-commercial X servers are a pain to configure for even the most rudimentary changes (like bit depth). I shouldn’t have to restart my windowing subsystem for such changes. Then there is the issue of X lacking even the most basic base-line UI guidelines and widgets, resulting in multiple competing window managers, each of which can be configured in about 1 billion ways. Yes, dorks with nothing better to do love this crap, but in the real world it makes the UI highly inconsistent across applications and distros and leads to situations where even if you only want to use one window manager (KDE) you may need the libraries from another (Gnome). At a more fundamental level, combine the lack of basic modern UI facilities with the nix’s generally loose object handling and it becomes clear why X still has problems with cut & paste functionality mastered by virtually every other platform.
X proponents, of course love to tout such features as network transparency and the configurability offered by X. Let me be blunt, piping your apps display across the wire to a local X server has turned out to be nothing more than a cool parlor trick, especially when you figure on how most ‘nix boxes are used. I remember when this was relatively useful back in the early to mid-90s when I used to have DEC X-Term on my desk, but nowadays, it’s just not necessary or particularly desirable. Yes, M$’s Avalon is going to offer similar transparency for next generation terminal services, but given how much more prevalent server based computing is in the Windows world, it makes a little more sense (though I think screen-scrape technology is just fundamentally more secure and easier to support).
If you want proof of just how much better a ‘nix OS’s user experience can be, look no further than MacOS X. Quartz, largely derived from NextStep’s windowing environment, so clearly illustrates just how much better a windowing subsystem can be. From font handling to fit and finish, OS X shows how desktop ‘nix SHOULD be done.
Other Problems
But the generalized problems with Linux don’t stop with just the complaints about X and the windowing environments. There are some more fundamental issues, like basic interoperability; something the Linux world claims to have in spades. Guess what, configuring a Linux host to act as an AD client is simply too difficult. Between nsswitch, PAM and Samba/Winbind, even if you have a clear roadmap to the conf files, it still takes far too many steps and far too much time. Don’t blame Microsoft, Apple had the same cards dealt to them and doesn’t supposedly have the “many eyes” of the Linux community, yet in X 10.3 it’s fairly straightforward to setup AD authentication and file sharing.
There are other annoying, and in some cases, downright infuriating issues in the Linux (and broader ‘nix world). Why aren’t file system layouts standardized? Why aren’t conf file structures standardized? For that matter, why are we still battling conf files!? Say what you will about the registry, but it sure as hell is a better solution than text based configuration files. Don’t like the registry, fine, but DO SOMETHING BETTER than CONF files?!?! Last but not least, why aren’t core services implementations standardized between Linux distributions?! If you want your desktop to be different, fine, but the set of services/daemons and their configurations should look roughly the same no matter what distro I use. If need be, the Linux standard communities need to come up with standard classifications for distro’s so that we have a reasonable idea of what the foot print of a distro will look like regardless of which vendor is boxing it.
Documentation
Perhaps the biggest impediment to any solutions success is documentation and support, and it is here that I find open source to be really lacking. For major components like PAM or Samba, for example, the documentation and MAN pages available are generally either outdated, incomplete or just plain poorly written. I don’t have any idea how this will be rectified, but someone had better do it. Hell, if a vendor would just fully document their distro end-to-end, it would be a start (and would give that vendor a huge advantage over competitors).
RedHat and the Fedora project
Fedora Linux, the project that serves as the new base development effort for RedHat’s commercial offering, is a good example of how a good idea can go very wrong. Fedora Core 2, if you strip out the all the management tools, is not a bad distro at heart. It’s fairly solid guts running on a latest and greatest 2.6.x kernel.
The problem is when you lump in all those nifty RedHat-ish GUI tools, you get something less than insanely great. Here is a bit of wisdom for all the vendors and distribution projects out there: if your whiz-bang graphical tool DOESN’T WORK then DON’T INCLUDE IT. No tool is better than a broken tool. For example, the DNS management applet included with various Red Hat and Fedora releases is really only good for mangling zone files. Another example would be the authentication configuration tool that comes with Fedora; it is horribly broken and mangles smb.conf badly. There are other numerous examples of where RedHat/Fedora have tried to match the empire’s array of GUI tools and failed miserably. I am not saying don’t include these tools as an optional package, just flag them as beta tools that may or may not work. That way, I don’t have to waste time figuring out they don’t work as advertised and can just go back to emacs and doing it the old fashioned way.
So does Linux suck?
No, it doesn’t. But putting aside Slashdot/ABM zealotry and political grandstanding, the reality is that Linux has a long way to go before it catches up with traditional commercial OS offerings. Linux may be having a field day gouging the low-end ‘nix market, but in the enterprise space and on the desktop, the Linux community AND the distro vendors have their work cut out for them.
