On Wed, 11 Dec 2002, John wrote: > On Sun, 8 Dec 2002, Lee Maschmeyer wrote: > > If you ask this group to compare Windows and Linux > > at any time for any purpose in any version > > whatsoever, guess who's gonna win! And for good reason! <grin> > > This isn't surprising since the members of this > > group generally know Linux better than Windows. There are some very experienced admins on this list who deal with largish heterogenous networks. > > People feel better about and are more comfortable > > with things they know well. True, and in spite of this, the movement of the IT industry to Linux is so far the most rapid in history, but it still takes time. > > Moreover, since Linux is an inherently simpler > > system and tries to do less for you, things are > > likely to be more straightforward. Humm.... One of the common criticisms of linux and other *ix type systems is the difficulty of learning it all, and the lack of GUI menu utilities that can handle all the extensive configuration possibilities (which can be reached through plain text based configuration files). But this is in large part because of the sheer power and vast number of configuration combinations. Try to buy a M$ system with all the utilities, development tools, communications server daemons, and clients, languages, and many other things, that come standard with a linux system, and it would cost you many thousands of dollars. But you can't have all this power and configurability, and choice, without a certain degree of complexity: there is, in fact so much there, that a fully functional GUI front end to all of it would be a massive, unnavigable maze, and impossibly expensive to boot (many attempts have been made to build fully comprehensive GUI front ends to *ix type systems, and all have failed). This is not to say that there are not some very nice front ends to all of the common, routine things. But no one person can reasonably hope to learn the entire rich toolset that comes with a major linux distribution in a lifetime; you just take what you need, and learn how to look up things in the extensive reference documentation when needed. > > Uninstall _programs_ are _programs_. Just like any > > other programs they can have bugs, and the > > emotional investment of programmers being what it > > is, it's highly likely uninstall programs receive > > relatively little testing. As other posters have pointed out in some detail, this is overcome very nicely by switching to a completely different, more capable paradigm of package maintenance, which does both the installation and removal, along with a whole bunch of other system monitoring, logging, package integrity, and consistency checking functions. M$ installation schemes are generally primitive by comparison. > > ... Personally, I've always liked the Windows > > model of putting the whole component (aside from > > shared system libraries) in one tree; executable, > > libraries, help files, manuals, DLLs etc. are more > > than likely all in the same place. Delete that > > tree, you delete everything. Vendors who want to use this format may use the /opt directory hierarchy, which is a defined filesystem standard for this purpose. Some distributors use this extensively, some very little, if at all: probably because with a decent package management system, such primitive methods just tend to make things harder to track and find, except in very special cases. But the method you mention may make proprietary license management easier on some networks with shared filesystems: many of us aren't very comfortable with such hassles. > > In Unix, though (and I assume Linux), you've got > > binaries under some flavor of /bin or /usr/bin or > > /usr/local/bin, manuals under /usr/man or related > > (or unrelated) entities, libraries under /lib or > > ... There is also a special area for locally installed stuff (/usr/local/*), and a special area for stuff which can readily be shared on a network, which is loaded with stuff -- manuals and other documentation, along with icons, text support files, help systems, etc, are now kept in /usr/share (such as /usr/share/man). LCR -- L. C. Robinson reply to no_spam+munged_lcr@onewest.net.invalid People buy MicroShaft for compatibility, but get incompatibility and instability instead. This is award winning "innovation". Find out how MS holds your data hostage with "The *Lens*"; see "CyberSnare" at http://www.netaction.org/msoft/cybersnare.html _______________________________________________ Blinux-list@redhat.com https://listman.redhat.com/mailman/listinfo/blinux-list