Hi: Great message. I hope SuSE listens and takes this to heart. Also, I really enjoyed looking over your "The Computer Builder" site (<A HREF="http://www.linux-hw.com/config/"><A HREF="http://www.linux-hw.com/config/</A">http://www.linux-hw.com/config/</A</A>>) Regards and happy holidays, Bill Parker
-----Original Message----- From: owner-suse-linux-e@suse.com [<A HREF="mailto:owner-suse-linux-e@suse.com]On">mailto:owner-suse-linux-e@suse.com]On</A> Behalf Of Eric Lee Green Sent: Saturday, November 28, 1998 11:57 PM To: suse-linux-e@suse.com Subject: [SuSE Linux] Day 4: Wrapup
Well, 4 days have passed, and here's what the conclusion is:
SuSE 5.3 is one heckuva general-purpose workstation.
I recommend it unhesitantly to the individual user who wants to use Linux. I still recommend Red Hat for server applications because it's so much easier to install and maintain, but SuSE is definitely superior as a general-purpose workstation. Much of the value is in the 5-CD set -- there is software there to do almost anything that can be done with Linux, all easily accessed via "yast". No more digging through FTP sites all over the world to find that One Perfect Application to do what you need to do -- it's all there, ready and waiting, and "yast" makes it easy to find and install it. Best of all, "yast" even manages the dependencies for you. Shades of "dselect"! (Now all you need to add is the auto-update feature of "dselect", where you can point it at your FTP archive, and it'll automatically flag all the new packages for update for you, for update and installation with a single keystroke). A little more attention to enterprise-scale features, and I'd unhesitantly recommend it for large-scale deployments. Here's some things that need to be considered for enterprise-scale deployments: 1) Routine maintenance tasks need to be distributable across the network without editing script files. Red Hat's /etc/cron.hourly, /etc/cron.daily, /etc/cron.weekly, and /etc/cron.monthly are such a means of doing this. I can use "rdist" or equivalent and zap out a script to all of my sites to do a weekly database cleanup or etc. without disturbing any other scheduled events or editing any files. Similarly, /etc/profile.d provides an easy way to drop in a script to be done at login without disturbing the contents of /etc/profile or the contents of any other login script. 2) Same with authentication information. PAM is a must for centralized authentication in the Microsoft-centric environments here in the United States. Recompiling applications every time Microsoft changes their authentication methods is *NOT* an option. When Microsoft added encrypted authentication to their SMB networking protocol, for example, a PAM module was swiftly written to interface with the fix that the Samba team added to their suite. Thus the NT networking and Linux logins can both use the same authentication database, rather than have two different sets of authentication tokens. Not a single end-user application had to be altered to make this change. 3) An effort must be made to segregate configuration and user information from the rest of the system so that a coherent backup strategy can be formulated. For example, under Red Hat Linux I know that if I back up /etc, /usr/local, and /home I can restore my entire system configuration by reinstalling the system, reinstalling my applications such as applix, then restoring the contents of those three directories. There is no configuration information that lives elsewhere on the system. Even the "X" server link is is set in the /etc/X11 directory so that when I restore my /etc directory, it restores ALL of my configuration info, even the configuration info that denotes where my "X" server lives. The fact that some of this configuration info is in the form of shell scripts or links to executables still does not make it belong somewhere else on the filesystem -- for an enterprise-scale deployment, I cannot go hunting down things stashed in odd corners of the system. That way lies lunacy.
Lest you think these are just minor quibbles: they are *NOT* minor quibbles when you are trying to maintain 250 systems scattered across a 10,000 square mile area in less than 2 hours a day of available time. I have managed enterprise-scale deployments. "minor" things like this swiftly become major when the number of systems involved passes 100. Many of these features were added to Red Hat 4.0 as the result of feedback from people like me, people who were managing large-scale deployments of Red Hat 3.0.3 and who had to add these kinds of things by hand over time in order to make our jobs reasonable. The time for thinking of Linux as an individual user's platform is over. It is now time to think of wide-spread deployment in the corporate environment. Without attention to enterprise-scale features it does not matter how good a workstation SuSE produces -- it won't be deployed in the numbers that it deserves. I hope that SuSE asks for feedback from others who are involved or who have been involved in the past with corporate-wide deployments of Linux, because I know that you can probably come up with some stuff that'll blow Red Hat in the weeds there. But it won't happen without someone making it their job to make it happen.
In the meantime: I am unhesitantly recommending SuSE Linux to our customers who are buying Linux machines for personal use. I'd like to see it get to the point where we could sell a couple hundred copies to someone deploying on a corporate-wide basis too.
-- Eric Lee Green eric@linux-hw.com <A HREF="http://www.linux-hw.com/~eric"><A HREF="http://www.linux-hw.com/~eric</A">http://www.linux-hw.com/~eric</A</A>> "Linux represents a best-of-breed UNIX, that is trusted in mission critical applications..." -- internal Microsoft memo
- To get out of this list, please send email to majordomo@suse.com with this text in its body: unsubscribe suse-linux-e
- To get out of this list, please send email to majordomo@suse.com with this text in its body: unsubscribe suse-linux-e