Re: No longer supporting Unixware / Open Server
From: FyRE (FyRE_at_toktik.demon.ku.oc.x)
Date: 01/30/04
- Next message: FyRE: "Re: No longer supporting Unixware / Open Server"
- Previous message: Emmanuel Jaeckert: "Problem installing oss646b"
- In reply to: Brian K. White: "Re: No longer supporting Unixware / Open Server"
- Next in thread: tony_at_pcunix.com: "Re: No longer supporting Unixware / Open Server"
- Reply: tony_at_pcunix.com: "Re: No longer supporting Unixware / Open Server"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Fri, 30 Jan 2004 16:13:13 +0000
On 30 Jan 2004 04:57:13 -0800, brian@aljex.com (Brian "SCO-Boy" White)
wrote:
[...]
>> Linux does not need 24/7 support. If you think that you are showing your
>> ignorance. On the other hand, I don't see any SCO installations in
>> Netcraft's list of machines with longest uptimes.
>
>You are right it doesn't need 24/7 baybysitting. It only needs
>attention when it crashes or gets holed. The rest of the time, yeah,
>it's fine.
In my experience Linux "crashes" are always due to:
(a) Hardware failures (most often, dying RAM).
(b) Forcing the wrong driver modules in for hardware.
(c) Administer's incompetence/ignorance.
However, if you're not just lying (again) and can actually produce an
example of Linux "just crashing for no reason" I'd be interested in
hearing about it. I won't hold my breath though, based on your
previous articles I suspect all your problems would fall under option
(c) above.
>And it has already been pointed out how silly and irrelevant netcraft
>is to this discussion. Just like the also irrelevant google example, I
>happen to be talking about boxes that operate in a completely
>dissimilar context than google or any other public web server, which
>are the only types of boxes that can ever even show up on netcraft.
...since obviously huge, busy database-driven e-commerce sites and the
World's largest search engine don't require very stable servers...
>The back-room boxes and factory floor boxes and data-logger boxes and
>point of sale boxes etc... most of them don't even see the internet.
>Yet they have some of the longest uptimes you'll ever see in person.
I'll have you know that I *know* for a fact that the vast majority of
robot-controllers and sensor monitoring hardware used on factory
floors are still using DOS (and in some cases Windows 3.1/WFW). That's
when they run any "normal" operating system and not V+, LynxOS etc.
The hardware used is also built to very different tolerances than a
family PC, or rack-mounted server unit.
>Certainly the consistently longest average uptimes if not the longest
>absolute.
Unlikely. In both the situations the machines would be almost
certainly power cycled at least once per year, and probably more
often. Why leave a POS terminal running over xmas when no-one's going
to be using it?
[...]
>Most recently a customer a few months ago wished to install a linux
>box and samba was going to be the main purpose for the box. It needed
Good idea. You realize you can already BUY Linux powered boxes already
set up for this very purpose (plus smtp, pop, www, firewall, net
access etc) with a nice web interface to control everything? Cost well
under 1000 pounds, and any fool can administer them.
>to be very reliable because their core business app was actually a
>windows app that needed a central server to hold database files that
>all pc's update. I recommended, in this order:
...here it comes... ;-)
>1) sco server with the sco version of the app and no more binaries
>running on pc's accessing data over the lan via mapped network drives,
>instead all data & bins running on the server and pc's just running
>terminal emulators.
>This would have been 1000% faster than what they were used to.
Big surprise there. Brian the rabid SCO fan recommends... SCO. Hope he
was wearing dark glasses so the "mark" couldn't see the dollar signs
in his eyes as he tried to push his wares.
>2) If you stay with windows version of app, then stay with a windows
>file server, just beef it up and strip it down and lock it down so
>nothing is running on it but antivirus and windows itself to provide
>the file shares.
Brian, you are truly an idiot. Ever heard of CAL licensing costs?
Security issues, performance issues, stability issues etc. Why on
Earth would anyone ask your advice?!
>Unix, while generally superior to windows in most any way, would most
>likely be a little more prone to unexpected or unusual problems if
>used in this way because in the end, an smb server is an add-on thing
>to unix and even the best ones don't precisely exactly duplicate
>windows's behaviour 100% and with this form of extremely heavy traffic
>made up of lots of little rapid transactions from many pc's to the
>same files at the same time, it's just asking for trouble.
More uninformed rubbish. Of course, Brian won't actually be able to
back up any of his ludicrous claims with facts.
>3) if you insist on a unix server for this, then make it sco +
>facetwin for reliability and the astonishing facetwin lifetime free
>actually knowledgeable support and the general lack of need for it in
>the first place, or possibly linux + facetwin to get linux's better
>disk performance and facetwins impeccable stability (but understand,
>sitting on top of linux instead of sco, it can only be just so
>reliable)
More baseless claims that Linux is not stable. Obviously, no facts
here either. Maybe this would be linked to Brian not making a
percentage on pushing a Linux OS... hmm...
>4) if you insist on linux + samba I am perfectly capable of setting it
>up and resolving any problems,
I'm very sceptical of this. Personally I wouldn't trust you to sit the
right way round on a toilet without someone keeping an eye on you.
>but I predict problems and the time
>spent fixing them may approach or surpass the cost of the sco+facetwin
>option.
If there are problems with Samba, and they can be "fixed" then the
cause of the problems would be your own incompetence.
>He ended up doing 90% of the job with reckless abandon all on his own
>and then calling me when in the middle of his first work day they
>suddenly started having a flood of problems and the app wasn't working
>at all and data was being botched up left and right from all the
>failed writes...
>
>In the end he pretty much lucked out. I resolved an obscure (but
>reasonably well documented and not apparently new) issue with
>fundamental differences in the way a windows box locks files and
>records and the way unix does, and the various subtly different
>behaviours that can optionally be specified in samba to try to satisfy
>applications that fail when moved to a samba share, and it didn't take
>me all day, and he didn't end up having to re-key in too much data.
So, the "obscure" but well documented, old issue was solved by the
guru Brian, eh? Why not point your poor misinformed clients at someone
who actually knows what they're doing in future? Anyone who isn't
aware of the issues with file locking (particularly on mdb lock files)
and the simple switches and force create modes to fix it shouldn't be
fiddling around with the company Samba setup.
>I don't consider that a linux success story.
No, nor would I Brian. I'd call it a tale of the "Greedy SCO reseller
attempting, and failing to push his products at someone who didn't
want them". You've just proven your utter incompetence (again) to
everyone in the group.
>I consider it a close
>call and I garuntee it wouldn't have happened had my first or second
>recommendation been accepted. It was a gamble that paid off. Most of
>my customers do NOT want to gamble with their business if there is any
>possible way to avoid it.
It sounds as though avoiding Brian K White would be a good first step.
I can imagine your sales patter:
Customer: I'd like to implement Samba on Linux to allow
high-performance, cheap network storage (and print services).
Brian: You don't want that mate. Why not pay for some nice SCO
software? Sure, it's grotesquely overpriced and the vendor will send
you threatening letters every so often, and the Samba developers don't
want their software used on the platform. But I make a few dollars,
and it's almost as fast as Linux (if Linux is on a slower machine).
Customer: I'd heard SCO were no longer producing software? Why pay for
that when I can use Linux to do the same job?
Brian: Well, erm, because I know how to set it up, and I can sell you
licenses for each user in your company accessing the Samba server.
Customer: I think I'll do it myself...
>And actually, the gamble is not over until
>that box goes 4 or 5 years without a burp until finally some peice of
>hardware starts to fail the way all the sco boxes have been doing. I
>predict failure there for sure. But his theory there is "when this
>cheap box dies I'll just restore the data from backup onto a new cheap
>box" and what the heck, as long as the backups are known good and as
>long as the setup of a box remains simple, maybe that's not an
>inefficient plan.
Bloody hell. Brian actually "gets it" at last!
>> Even other posters on this newsgroup don't agree with you. How many
>> posts have we seen from multiple posters in this very newsgroup who say
>> that that SCO is dying and they are migrating customers to Linux.
>>
>
>What has that got to do with anything?
Yeah, because obviously convincing your (poor misguided) customers to
use a dead OS is nothing to worry about. Once you have their cash,
what the hell, eh? ;-)
>I myself have been working on a
>pet project off & on for over a year to put together a freebsd based
>replacement for our current sco based package, but *not* because of
>cost, which is what I daresay is the reason most people migrate from
>sco to linux.
Hmm, of course that's the reason, yes. Huge corporations spending
millions on software would obviously plump for Linux to save a couple
of thousand pounds. It's not the support from IBM, SuSE/Novell, HP,
Dell, Redhat or (now) Sun microsystems. It's not the fact it vastly
outperforms SCO (and *BSDs which make compromises for security
reasons), is being developed much faster and isn't sold by a bunch of
stock-pumping, profiteering gluttons. Oh no, it's the price ;-)
>Notice that I do not ask you to support any statements about linux's
>dependability. I don't need to. I actually use both sco and linux and
>you can't say anything that would undo the first-hand comparison I
>have simply and plainly witnessed. (And I assure you, it's not a linux
>knowledgeability issue. Being 34 and picking up unix kind of late, I
>am among the first wave of people who initially learned unix more on
>linux than on anything else. Hopefully that sheds a little perspective
>on my stances.)
So, you've been using Unix since you were what, 33? From what I've
read here, I wouldn't want someone like you anywhere near a server
room full of Linux boxes. You obviously don't know what you're doing,
you admit to telling your customers abject lies, and have an almost
religious fervor for a dead OS.
-- FyRE < "War: The way Americans learn geography" >
- Next message: FyRE: "Re: No longer supporting Unixware / Open Server"
- Previous message: Emmanuel Jaeckert: "Problem installing oss646b"
- In reply to: Brian K. White: "Re: No longer supporting Unixware / Open Server"
- Next in thread: tony_at_pcunix.com: "Re: No longer supporting Unixware / Open Server"
- Reply: tony_at_pcunix.com: "Re: No longer supporting Unixware / Open Server"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
