Re:Linux & *BSD aren't UNIX (technically)
on
SCO does Linux
·
· Score: 1
> Actually, SCO owns the copyright to the word > "UNIX".
BZZZZZZZZt. Thanks for playing. The correct answer is the Open Group. We have some lovely parting gifts for you though.:)
SCO briefly held the trademark, but transfered it to the Open Group a long while back.
Re:Ironic? In more ways than one.
on
SCO does Linux
·
· Score: 2
SCO currently offers three operating system lines - Openserver 5.0.x, Unixware 2.1.x, and Unixware 7.x. They did not write any of them in their entirety.
Openserver 5 is based on the SVR3.2 kernel. They haven't done any real modifications except for new hardware support and bugfixes for nearly a decade. Not to mention that portions of OSR5 are purchased from outside companies, e.g. Panorama, their X desktop.
This product has no real advantages over Linux except for a large legacy application base. Sales are currently impressive due to an upgrade rush prompted by the Year 2000.
SCO is planning on dropping this product after one or two more revisions. Unfortunately for them, it is also their current cash cow and it will hurt their gross profits immensely when they do.
Unixware 2 is based on the SVR4MP kernel. No real modifications to this product since its purchase from Novell.
Another product that really only has a market for legacy applications. Sales are typically upgrades or for itsy bitsy teeny weeny niche markets. To be honest, I have no idea why this product is still being sold.
Unixware 7 is based on what SCO is calling SVR5, since they now own the AT&T codebase. It adds some "enterprise" features that are lacking in the Unixware 2 product line and merges in admin tools from Openserver 5.
This is where SCO would have everyone go in the future. Sales have been tepid, but are starting to pick up some.
Personally, though it has potential, I still wouldn't touch it. As it is a brand new product line it still is buggy as hell, the interface is a nightmarish cross between Unixware 2 and Openserver 5, they currently don't have their own support personel trained on it and its pricing structure makes it as expensive (if not more) as the traditional high end *nixes.
Re:16-node clustering, journaled file system....
on
SCO does Linux
·
· Score: 1
Let's take a look at that feature list again.
Failover clustering is wonderful, when it gets released and you can actually get your hands on it. Not the case with Unixware.
Thirty-two way SMP is nice as well, if your hardware will support it, which x86 currently doesn't.
So, in reality, at this point you can do *maybe* single node, 8-way SMP.
Though a RISC processor doesn't have to deal with a wide array of instructions or variable length instructions, it also has to preform many more operations to get the same results.
It's not all about "little words" vs. "big words"; it also has to do with bredth of vocabulary. A simplistic analogy would be the difference between saying "great" vs. "doubleplus good".
A single pipeline CPU running RISC would almost certainly be bested by a CISC machine. However, RISC does make pipelining a _lot_ easier; hence the advantage.
I am not saying CISC is better, but it is not as braindead an idea as you make it out to be. When it was designed it was a godsend.
>Matthias Ettrich wrote: With abiword and gnumeric >there are now two overhyped gtk projects that >both have a far superior counterpart in the KDE >office suite. >... >Without wanting to discourage you: Do you really >think that's worth it? I mean, Abiword right now >can't do even half of what kword can do! Why >fiddle around with these over-hyped C-sources >without functionality, if kword is nicer >designed, more powerful and object-oriented?
Strange, seems to me last time I looked at the Abiword source code it was in C++.
Not to mention that it is not gospel truth that C++ is the end all be all of computer languages. Neither is C, Java, Eiffel, etc, etc.
There are other considerations in the speed of Abiword development, such as cross-toolkit compatibility rather than sticking to only one (QT in the case of KWord.
KWord also does not list on its feature set a Word imported, which is available on AbiWord, though it is not perfect yet.
As for Gnumeric, I've been using it since the.1x series and have found it to be extremely stable, have it to have a fairly large feature set for such a young application, and it has the ability to load Excel spreadsheets. Again, not perfect, but it is enough that I don't need to use Excel for the majority of basic spreadsheets at work anymore.
The "over-hyped" comment is completely out of line, as there has been little mainstream coverage of either comment outside the casual mention in articles about each desktop enviorment.
The "far superior" comment is a MATTER OF OPINION, as both have features unique to themselves.
And even these being true would NOT be a reason to abandon two projects which are progressing very nicely and will only lead to more choice in the free software community.
My only hope is that there will be some consensus on file formats, preferably an XML derivative.
> No large files support (files over 2Gb). This is > required for any work with medium-large > databases or digital video editing.
Well, I could argue with its necessity in database support, where a raw partition would make more sense, but I concede it would be nice on the digital video front.
This has started to be addressed in the early 2.3 kernels unless I'm mistaken.
> Poor support for RAID - hot spares, hot swap, > etc.
In software yes. But I don't see this as an obstacle, since hardware RAID options are cheap on the x86 platform.
And if you want controller redundancy, set up two RAID 5's off the back of the box and use either MD or LVM to mirror those.
>Poor NFS performance (speed and locking)
I would actually say that speed is no longer the issue with the 2.2.x series of kernels; it's NFSv3 compatability. The patches to make it such are out there and are going to be integrated RSN from what I've heard.
>Poor desktop environment
Compared to *what*?
CDE is a joke. Inflexible, bloated and ugly.
4DWM is okay, but it uses X extensions not available on all platforms, and it doesn't really provide anything that outstanding.
NT is okay. Major strength there is consistancy and decent inter-application communication.
Gnome is already more flexible and usable that CDE and 4DWM, and has already integrated the drag and drop protocal, a CORBA infastructure and the release of the COM is right around the corner.
And, as someone else has probably pointed out, this is irrelevant in terms of a server OS.
>No high availability clustering (Beowolf is cool >but completely unrelated to this)
MOSIX was just GPL'ed. This is a good foundation.
Not to mention that NT's clustering is abysmal and SCO's barely exists, yet both of those have a presence in the enterprise.
> SCO's not going to compete in the long run. The > only reason they've not (and probably will not) > go under is all the legacy telephony SCO > software.
Unfortunately SCO has a much larger legacy market than just telephony.
I support Openserver and Unixware professionally (feel my pain, brothers!:) The majority of customers I deal with are small businesses running accounting apps, custom software, and vertical market applications.
Probably the quickest death to most of SCO's customer base would be Linux support of applications like MAS/90 or Realworld.
>PC hardware failure problem spots in my >experience have been:
> CD-ROMs (really flaky)
Depends on what you buy. A lot of machines ship with piece-of-carp EIDE Mitsumi's or La Cie's.
On the other hand, buy a Toshiba SCSI and you get the exact same product you would in an HP 9000 or Sun Sparc.
Buy a Plextor and you get the best CD-ROM on the face of the earth.:)
> RAM
Depends on the manufacturer. Though I have not noticed this being more of a problem on PC's than RISC boxen. Most of the problems that arise are people using the wrong memory (which isn't helped by the ridiculous variety of RAM out there and that finding out what you SHOULD use is harder than on a Sun platform).
> SCSI cards
If you go with the garbage put out by Symbios, sure. Or if you get a bad driver from Ami (notoriously bad under Openserver and Unixwar).
But the DPT cards are rock-solid and they don't needlessly change the interface to their cards (with the introduction of the V series, there are only three driver interfaces for virtually all their cards).
I have an anchient ISA full-length card of their (a 9011B) that has been going for 9 years without a hiccup.
> Motherboards
This I'll agree with to some degree. Why expect decent performance and quality from a no-name motherboard you picked up for $40 though? Buy Tyan, Asus, or Micronics.
I think the "problem" with the PC platform is that, since it is open, there is more opprotunity for garbage. But if you know what you're buying, you have, overall, a very good platform.
Actually, the availability of I2O Linux drivers for the SmartRaid V series of controllers from DPT were just release (look at the Pengiun on their front page.)
Likewise, Mylex has full support for RAID under Linux and HP has developed AmiRD drivers as well.
Being HP-UX certified myself, I'll admit that the lack of a stable LVM at this point is a fairly big minus for large servers, as is the lack of a journeled filesystem for quick recovery in a crash situation.
On the other hand, there are some stability problems in HP-UX 11.00 that I have noticed. After heavy modifications to a volume group, I was able to reboot my system simply by activating it. This was even after rebuilding the LVM structures on the drive. When I reported it, the answer was "well, we haven't heard that one before, so it's too rare to worry about."
The network subsystem also seems to have some odd bugs - the telnet program will/NOT/ connect properly to an Openserver system (it hangs, though I get a response to an AYT), after several days of continuous use I lose all network connectivity and have to reboot.
Installing the cumalitve lan patches that I assumed would fix some of these problems turned out to be a misadventure, as two of the patches depended on one another, so I had to unpack the patches and combine them into a single swdepot so they would install.
The ldd command is simply broken on 32 bit systems - it exits with a message that the file is not a 64 bit executable.
And the support technicians are not nearly as competant as I would hope - I had to guide the one sent out to replace a bad motherboard in my B160 through removal of the drive cage as well as the commands for the PDC. And the first two replacement motherboard were bad - one was completely gone and the other one did not have the LAN ID cleared at the factory. Another one I dealt with flat out refused to do a processor upgrade without a minimum of 1.5gb installed, when the manual clearly stated that 1gb was the requirement.
All in all, I'll admit the feature set is more rich, the hardware design can be nicer to work with (I love that expansion cards have a hard set hardware path and you can list the hardware that isn't currently claimed by a driver). But the physical layout of the hardware is often very bad (the B series have front panel switches soldered directly to a portion of the motherboard held on by a piece of plastic only a few centimeters thick), the OS has more bugs than Linux, and there _ARE_ problems with stability.
From all reports I've heard, that is the case, so I won't argue with that.
But on the other hand, when I did try it on a 486/50 with 32MB of RAM it crawled. Gnome ran without a problem on the same machine, as far back as 0.13 and as recently as 1.0.1.
> It's also based on CORBA, and has applications > like StarOffice that use it.
Is there an ORB as part of the KDE downloads? Is there a document object model or applet framework as part of the KDE downloads? No.
MICO is only installed currently as a support app for Koffice, a alpha/beta suite of applications.
I'm not saying that this isn't going to be expanded in the future, but considering that the current desktop runs independant of CORBA, I would not say that KDE is "based on CORBA".
The StarOffice announcement includes some minor concessions (a link on the panel and a handful of icons), some features that will work with Gnome as well (dnd interoperability), some features that should not be a consideration (SO tries not to cover kpanel - this is a WINDOW MANAGER issue), and one real integration (the KDE control center being available in the SO settings menu.)
> The UI toolkit - Qt - is rock solid and > documented up the wazoo (there's even an > O'Reilly Qt book already released in Germany).
GTK documentation has been an issue in the past, since it's been a moving target during the 1.1 series.
But things are becoming a lot better. Eric Harlow's book has been released by NewRiders, Redhat is gearing up for it's own reference manuals, and the online documentation project has been accelerating ever since the code freeze of both GTK and Gnome.
> It's got themes: > GNOME seems sexy when you see all the themed > screenshots, but when you realize you can > customize KDE the same amount, then start > looking below the surface...
Themability in Gnome includes the ability to have replacement rendering engines for the Widgets, this is far more configurable than KDE is currently.
> Right now GNOME is a sham. I've already seen > press reviews of GNOME comparing it's crashes to > Window's blue-screen-of-death... It'll be a real > shame if Linux gets written off as being as > buggy as Windows because of the politically > motivated "1.0" release:(
Gnome is far from a sham. I'll agree that the 1.0 release had a handful of bugs, but a large portion of the "bugs" people report are in fact configuration problems.
Initial installation is still a bit too difficult, I'll agree, but Gnome is more ambitious than KDE - the base installation includes an ORB, a CORBA naming service, an implementation of IIOP, a set of C convienence functions (memory allocation, data structures, cross-platform compatibility functions), a generic plug-in interface, a thin wrapper for X, a graphics library, an image manipulation library that can handle almost any format, audio support libraries, a network aware audio server, high level graphics libraries, an xml parsing library, a cross-platform system monitoring library, a vt emulation library, http access functions, truetype font libraries, etc, etc, etc...
And that is just support libraries, not applications.
Not to mention that the acid test for Gnome will be the release of Redhat 6.0, when the majority of users are exposed to it, not the 1.0 release.
On the whole, the 1.0 release has gotten the name out, gotten a lot of people to try it finally and submit bug reports, etc, etc. Even the Linux kernel goes through such "brown paper bag".0 releases since a lot of users don't install a new project until it hits the major version.
I'm a self-respecting Unix person who works for Ingram Micro supporting SCO (as well as HP-UX and Linux in an unofficial capacity).
I'll admit that my we haven't had a huge amount of experience with Unixware, as most customers are staying with Openserver, but what experience I have had does not impress me.
First, why is it that you cannot set up dial-in and dial-out on the same port? And why does the first serial port always reset to PPP irregardless of what you have configured it as?
And why don't the ported administation tools reflect differences in the two operating systems (e.g. the username field in the accound administrator only accepts 8 character usernames whereas the rest of the tools accept 256 iirc.
And on that note, why is there little to no error handling in the tcl admin tools. I've had to go through dozens of tcl stack dumps from admin tools that wouldn't even start, only to discover it was because of a bad entry in a config file.
Openserver is even worse - the 5.0.5 print subsystem is 100% fubar, fixing a mistake in adding a device often requires editing half a dozen files some of which are C code, the amird driver in rs504c and 5.0.5 somehow screws up all console logins except for X's login, etc.
It is understandable why you would suggest skunkware tools over your own, as SCO tar doesn't have support for backup of empty directories or special files; cpio in one of its incarnations (I do not recal which) hangs when piped to more, etc.
And SCO has a major problem with support. A fair amount of techs working on the priority lines are definitely talented, but a lot of the front line support is imho (as well as most people I deal with) utter carp.
Slashdot Mirror
> Actually, SCO owns the copyright to the word
:)
> "UNIX".
BZZZZZZZZt. Thanks for playing. The correct answer is the Open Group. We have some lovely parting gifts for you though.
SCO briefly held the trademark, but transfered it to the Open Group a long while back.
SCO currently offers three operating system lines - Openserver 5.0.x, Unixware 2.1.x, and Unixware 7.x. They did not write any of them in their entirety.
Openserver 5 is based on the SVR3.2 kernel. They haven't done any real modifications except for new hardware support and bugfixes for nearly a decade. Not to mention that portions of OSR5 are purchased from outside companies, e.g. Panorama, their X desktop.
This product has no real advantages over Linux except for a large legacy application base. Sales are currently impressive due to an upgrade rush prompted by the Year 2000.
SCO is planning on dropping this product after one or two more revisions. Unfortunately for them, it is also their current cash cow and it will hurt their gross profits immensely when they do.
Unixware 2 is based on the SVR4MP kernel. No real modifications to this product since its purchase from Novell.
Another product that really only has a market for legacy applications. Sales are typically upgrades or for itsy bitsy teeny weeny niche markets. To be honest, I have no idea why this product is still being sold.
Unixware 7 is based on what SCO is calling SVR5, since they now own the AT&T codebase. It adds some "enterprise" features that are lacking in the Unixware 2 product line and merges in admin tools from Openserver 5.
This is where SCO would have everyone go in the future. Sales have been tepid, but are starting to pick up some.
Personally, though it has potential, I still wouldn't touch it. As it is a brand new product line it still is buggy as hell, the interface is a nightmarish cross between Unixware 2 and Openserver 5, they currently don't have their own support personel trained on it and its pricing structure makes it as expensive (if not more) as the traditional high end *nixes.
Let's take a look at that feature list again.
Failover clustering is wonderful, when it gets released and you can actually get your hands on it. Not the case with Unixware.
Thirty-two way SMP is nice as well, if your hardware will support it, which x86 currently doesn't.
So, in reality, at this point you can do *maybe* single node, 8-way SMP.
You are glossing over the advantages of a CISC.
Though a RISC processor doesn't have to deal with a wide array of instructions or variable length instructions, it also has to preform many more operations to get the same results.
It's not all about "little words" vs. "big words"; it also has to do with bredth of vocabulary. A simplistic analogy would be the difference between saying "great" vs. "doubleplus good".
A single pipeline CPU running RISC would almost certainly be bested by a CISC machine. However, RISC does make pipelining a _lot_ easier; hence the advantage.
I am not saying CISC is better, but it is not as braindead an idea as you make it out to be. When it was designed it was a godsend.
>Matthias Ettrich wrote: With abiword and gnumeric ...
.1x series and have found it to be extremely stable, have it to have a fairly large feature set for such a young application, and it has the ability to load Excel spreadsheets. Again, not perfect, but it is enough that I don't need to use Excel for the majority of basic spreadsheets at work anymore.
>there are now two overhyped gtk projects that
>both have a far superior counterpart in the KDE
>office suite.
>
>Without wanting to discourage you: Do you really
>think that's worth it? I mean, Abiword right now
>can't do even half of what kword can do! Why
>fiddle around with these over-hyped C-sources
>without functionality, if kword is nicer >designed, more powerful and object-oriented?
Strange, seems to me last time I looked at the Abiword source code it was in C++.
Not to mention that it is not gospel truth that C++ is the end all be all of computer languages. Neither is C, Java, Eiffel, etc, etc.
There are other considerations in the speed of Abiword development, such as cross-toolkit compatibility rather than sticking to only one (QT in the case of KWord.
KWord also does not list on its feature set a Word imported, which is available on AbiWord, though it is not perfect yet.
As for Gnumeric, I've been using it since the
The "over-hyped" comment is completely out of line, as there has been little mainstream coverage of either comment outside the casual mention in articles about each desktop enviorment.
The "far superior" comment is a MATTER OF OPINION, as both have features unique to themselves.
And even these being true would NOT be a reason to abandon two projects which are progressing very nicely and will only lead to more choice in the free software community.
My only hope is that there will be some consensus on file formats, preferably an XML derivative.
> No large files support (files over 2Gb). This is
> required for any work with medium-large
> databases or digital video editing.
Well, I could argue with its necessity in database support, where a raw partition would make more sense, but I concede it would be nice on the digital video front.
This has started to be addressed in the early 2.3 kernels unless I'm mistaken.
> Poor support for RAID - hot spares, hot swap,
> etc.
In software yes. But I don't see this as an obstacle, since hardware RAID options are cheap on the x86 platform.
And if you want controller redundancy, set up two RAID 5's off the back of the box and use either MD or LVM to mirror those.
>Poor NFS performance (speed and locking)
I would actually say that speed is no longer the issue with the 2.2.x series of kernels; it's NFSv3 compatability. The patches to make it such are out there and are going to be integrated RSN from what I've heard.
>Poor desktop environment
Compared to *what*?
CDE is a joke. Inflexible, bloated and ugly.
4DWM is okay, but it uses X extensions not available on all platforms, and it doesn't really provide anything that outstanding.
NT is okay. Major strength there is consistancy and decent inter-application communication.
Gnome is already more flexible and usable that CDE and 4DWM, and has already integrated the drag and drop protocal, a CORBA infastructure and the release of the COM is right around the corner.
And, as someone else has probably pointed out, this is irrelevant in terms of a server OS.
>No high availability clustering (Beowolf is cool
>but completely unrelated to this)
MOSIX was just GPL'ed. This is a good foundation.
Not to mention that NT's clustering is abysmal and SCO's barely exists, yet both of those have a presence in the enterprise.
>If you'd rather do software RAID then you have
>never worked in an enterprise environment where
>speed and reliability are a concern.
Actually, you're wrong here. HP 9000 systems use software raid heavily (MirrorDisk/UX and LVM).
>Why somebody would use software RAID when
>hardware devices are available at low costs
>COMPLETELY blows my mind.
What happens if your raid card goes? Use software raid to mirror accross two controllers and you've eliminated a single point of failure.
It's out there.
http://linux.msede.com/lvm/
It is not considered production code yet, but I haven't had a problem with it yet.
Very similar to the HP-UX implementation of the Veritas volume manager, though IMO the Linux implementation is shaping up to have better tools.
> SCO's not going to compete in the long run. The
:) The majority of customers I deal with are small businesses running accounting apps, custom software, and vertical market applications.
> only reason they've not (and probably will not)
> go under is all the legacy telephony SCO
> software.
Unfortunately SCO has a much larger legacy market than just telephony.
I support Openserver and Unixware professionally (feel my pain, brothers!
Probably the quickest death to most of SCO's customer base would be Linux support of applications like MAS/90 or Realworld.
>PC hardware failure problem spots in my
:)
>experience have been:
> CD-ROMs (really flaky)
Depends on what you buy. A lot of machines ship with piece-of-carp EIDE Mitsumi's or La Cie's.
On the other hand, buy a Toshiba SCSI and you get the exact same product you would in an HP 9000 or Sun Sparc.
Buy a Plextor and you get the best CD-ROM on the face of the earth.
> RAM
Depends on the manufacturer. Though I have not noticed this being more of a problem on PC's than RISC boxen. Most of the problems that arise are people using the wrong memory (which isn't helped by the ridiculous variety of RAM out there and that finding out what you SHOULD use is harder than on a Sun platform).
> SCSI cards
If you go with the garbage put out by Symbios, sure. Or if you get a bad driver from Ami (notoriously bad under Openserver and Unixwar).
But the DPT cards are rock-solid and they don't needlessly change the interface to their cards (with the introduction of the V series, there are only three driver interfaces for virtually all their cards).
I have an anchient ISA full-length card of their (a 9011B) that has been going for 9 years without a hiccup.
> Motherboards
This I'll agree with to some degree. Why expect decent performance and quality from a no-name motherboard you picked up for $40 though? Buy Tyan, Asus, or Micronics.
I think the "problem" with the PC platform is that, since it is open, there is more opprotunity for garbage. But if you know what you're buying, you have, overall, a very good platform.
Actually, the availability of I2O Linux drivers for the SmartRaid V series of controllers from DPT were just release (look at the Pengiun on their front page.)
/NOT/ connect properly to an Openserver system (it hangs, though I get a response to an AYT), after several days of continuous use I lose all network connectivity and have to reboot.
Likewise, Mylex has full support for RAID under Linux and HP has developed AmiRD drivers as well.
Being HP-UX certified myself, I'll admit that the lack of a stable LVM at this point is a fairly big minus for large servers, as is the lack of a journeled filesystem for quick recovery in a crash situation.
On the other hand, there are some stability problems in HP-UX 11.00 that I have noticed. After heavy modifications to a volume group, I was able to reboot my system simply by activating it. This was even after rebuilding the LVM structures on the drive. When I reported it, the answer was "well, we haven't heard that one before, so it's too rare to worry about."
The network subsystem also seems to have some odd bugs - the telnet program will
Installing the cumalitve lan patches that I assumed would fix some of these problems turned out to be a misadventure, as two of the patches depended on one another, so I had to unpack the patches and combine them into a single swdepot so they would install.
The ldd command is simply broken on 32 bit systems - it exits with a message that the file is not a 64 bit executable.
And the support technicians are not nearly as competant as I would hope - I had to guide the one sent out to replace a bad motherboard in my B160 through removal of the drive cage as well as the commands for the PDC. And the first two replacement motherboard were bad - one was completely gone and the other one did not have the LAN ID cleared at the factory. Another one I dealt with flat out refused to do a processor upgrade without a minimum of 1.5gb installed, when the manual clearly stated that 1gb was the requirement.
All in all, I'll admit the feature set is more rich, the hardware design can be nicer to work with (I love that expansion cards have a hard set hardware path and you can list the hardware that isn't currently claimed by a driver). But the physical layout of the hardware is often very bad (the B series have front panel switches soldered directly to a portion of the motherboard held on by a piece of plastic only a few centimeters thick), the OS has more bugs than Linux, and there _ARE_ problems with stability.
> It's rock solid.
:(
.0 releases since a lot of users don't install a new project until it hits the major version.
From all reports I've heard, that is the case, so I won't argue with that.
But on the other hand, when I did try it on a 486/50 with 32MB of RAM it crawled. Gnome ran without a problem on the same machine, as far back as 0.13 and as recently as 1.0.1.
> It's also based on CORBA, and has applications
> like StarOffice that use it.
Is there an ORB as part of the KDE downloads? Is there a document object model or applet framework as part of the KDE downloads? No.
MICO is only installed currently as a support app for Koffice, a alpha/beta suite of applications.
I'm not saying that this isn't going to be expanded in the future, but considering that the current desktop runs independant of CORBA, I would not say that KDE is "based on CORBA".
The StarOffice announcement includes some minor concessions (a link on the panel and a handful of icons), some features that will work with Gnome as well (dnd interoperability), some features that should not be a consideration (SO tries not to cover kpanel - this is a WINDOW MANAGER issue), and one real integration (the KDE control center being available in the SO settings menu.)
> The UI toolkit - Qt - is rock solid and
> documented up the wazoo (there's even an
> O'Reilly Qt book already released in Germany).
GTK documentation has been an issue in the past, since it's been a moving target during the 1.1 series.
But things are becoming a lot better. Eric Harlow's book has been released by NewRiders, Redhat is gearing up for it's own reference manuals, and the online documentation project has been accelerating ever since the code freeze of both GTK and Gnome.
> It's got themes:
> GNOME seems sexy when you see all the themed
> screenshots, but when you realize you can
> customize KDE the same amount, then start
> looking below the surface...
Themability in Gnome includes the ability to have replacement rendering engines for the Widgets, this is far more configurable than KDE is currently.
> Right now GNOME is a sham. I've already seen
> press reviews of GNOME comparing it's crashes to
> Window's blue-screen-of-death... It'll be a real
> shame if Linux gets written off as being as
> buggy as Windows because of the politically
> motivated "1.0" release
Gnome is far from a sham. I'll agree that the 1.0 release had a handful of bugs, but a large portion of the "bugs" people report are in fact configuration problems.
Initial installation is still a bit too difficult, I'll agree, but Gnome is more ambitious than KDE - the base installation includes an ORB, a CORBA naming service, an implementation of IIOP, a set of C convienence functions (memory allocation, data structures, cross-platform compatibility functions), a generic plug-in interface, a thin wrapper for X, a graphics library, an image manipulation library that can handle almost any format, audio support libraries, a network aware audio server, high level graphics libraries, an xml parsing library, a cross-platform system monitoring library, a vt emulation library, http access functions, truetype font libraries, etc, etc, etc...
And that is just support libraries, not applications.
Not to mention that the acid test for Gnome will be the release of Redhat 6.0, when the majority of users are exposed to it, not the 1.0 release.
On the whole, the 1.0 release has gotten the name out, gotten a lot of people to try it finally and submit bug reports, etc, etc. Even the Linux kernel goes through such "brown paper bag"
I'm a self-respecting Unix person who works for Ingram Micro supporting SCO (as well as HP-UX and Linux in an unofficial capacity).
I'll admit that my we haven't had a huge amount of experience with Unixware, as most customers are staying with Openserver, but what experience I have had does not impress me.
First, why is it that you cannot set up dial-in and dial-out on the same port? And why does the first serial port always reset to PPP irregardless of what you have configured it as?
And why don't the ported administation tools reflect differences in the two operating systems (e.g. the username field in the accound administrator only accepts 8 character usernames whereas the rest of the tools accept 256 iirc.
And on that note, why is there little to no error handling in the tcl admin tools. I've had to go through dozens of tcl stack dumps from admin tools that wouldn't even start, only to discover it was because of a bad entry in a config file.
Openserver is even worse - the 5.0.5 print subsystem is 100% fubar, fixing a mistake in adding a device often requires editing half a dozen files some of which are C code, the amird driver in rs504c and 5.0.5 somehow screws up all console logins except for X's login, etc.
It is understandable why you would suggest skunkware tools over your own, as SCO tar doesn't have support for backup of empty directories or special files; cpio in one of its incarnations (I do not recal which) hangs when piped to more, etc.
And SCO has a major problem with support. A fair amount of techs working on the priority lines are definitely talented, but a lot of the front line support is imho (as well as most people I deal with) utter carp.