on Fri, Jul 23, 2004 at 12:03:54AM -1000, Ryo Furue ([EMAIL PROTECTED]) wrote:
> Paul,
>
> Thanks for your comments.
>
> > > I'm using the Intel Fortran Compiler (IFC). Its version 7 runs on
> > > Debian without any problem whatsoever, although Intel doesn't support
> > > Debian. But, last year Intel released a total rewrite of the
> > > compiler, version 8, with which my Fortran programs don't work at all
> > > (*). Since Debian isn't supported, even if I paid (which I don't),
> > > Intel wouldn't fix my problem. (If paying would fix it, I would pay.)
> > > This is a big headache. Uniformity is sometimes good.
> >
> > However, as explained above, uniformity does not exist. Quick, tell me
> > which RPM I need, as a Debian user, to easily and cleanly install the
> > software like the packager intended: Mandrake, Red Hat, Fedora, SuSE...
>
> At least, Intel supports RedHat 9.0 (or whatever version Intel
> mentions.
RH 9.0 is a few revs out of date. The current product is RHEL (Red Hat
Enterprise Linux), and it's had a few releases yet. RH is chasing
MSFT's "update early and often...and for a charge" model. Pity they
haven't clued into their NC neighbor and followed SI's subscription
model (though SI hardly gets everything right).
> I don't remember correctly.). As long as you use that version of RH,
> Intel will support you.
You want to spend an hour or so Googling very cogent comments by Linus,
Don Marti, and others, on the inherent limitations of binary lock-in.
What if Intel, Nidiot, Oracle, and Peoplesoft all require different
minor revs of the kernel, HW, or OS release level? Sorry, I left *that*
hell behind some years ago.
> (If you replace the kernel, libc, or other "critial" part of the OS,
> your support is void, of course.) And "most" people use RedHat
> anyway.
Demonstrably false.
Red Hat remains the leading tracked distribution in most surveys, but
it's got a plurality, not a majority. Share is ~40% IIRC. Debian's in
the top three, and I think SuSE's got the number-two slot, in numbers I
saw in the past couple of months. Counting Linux installs is a bit like
counting kangaroo rats, however: it's hard to see, they're all over the
place, and they're multiplying like mad.
"Most people" really isn't a meaningful metric. Your CIO really doesn't
care what gamers are running, and an embedded HW manufacturer likely
can't afford the overhead of pretty much _any_ full-fledged distro
(though HP's iPaq is based on Debian, and includes a stripped package
update system).
> (In my workplace, all the Linux users except me use RH, it
> seems.) That's kind of uniformity, isn't it? Not as uniform as
> Windows XP, though.
Small-pond uniformity, sure.
> > > I also heard from a programmer that her company develops software
> > > only for Windows because it's so uniform and ubiguitous.
> >
> > I usually feel sorry for people like that. They miss the fact that unix
> > is everywhere, has been everywhere for decades, and will probably be
> > around long after the commercial software fad fades back into relative
> > obscurity.
>
> I suspect you miss my point. Perhaps, I wan't clear enough. Although
> Unix is everywhere, it's not trivial to write a significant piece
> of sotware which runs on all the major Unixes out there.
Wrong.
Google for "oracle just type make".
That was the entire porting process for getting the world's leading
enterprise database software to run on Linux. Not one code edit
required.
Whether or not subsequent tuning was performed is another question (and
I strongly suspect it has been ;-).
However: the discipline of writing for a range of Unix-standard
platforms, and Linux's own standards compliance, *did* mean that the
port was trivial to implement.
My understanding is that SAS had a similar experience, though there was
more work that went into the production release. Possibly related to
the fact that the company uses its own proprietary compiler (again,
non-free => non-standard). Then again, the company is sufficiently NIH
that it provides and uses its own monospace font.
I can report that SAS's pre-release Linux product ran successfully and
relatively satisfactorially on Debian, though it was targeted for Red
Hat, after creating a nonstandard tmp/ directory somewhere (either /var
or /usr, I don't recall which).
I am familiar with a dependency on the part of PeopleSoft on specific
kernel revs (personal conversations with a LuGOD member contracting at
same). Again, largely speaking to specific software design, and a
failure to adhere to standards.
And again: for sufficiently tailored enterprise-class software, you'll
pick your platform to fit the app, and dedicate hardware to that one
task. But there's very little software that falls into this class
that's not at least substantially substitutable, and insisting on such
an architecture is a dead end.
> The example I gave in my last message about the Intel compilear is a
> piece of evidence which supports my opinion.
You *really* enjoy single-point extrapolation, don't you?
I'd recommend against a career in statistical analysis.
Alternatively, I'll let you plot the points, if I can pick the angles.
> > > Unfortunately, uniformity and community efforts don't come together.
> >
> > Riiiiight. That's why all the open browsers are standards compliant,
> > and IE is not. Why pretty much every network service out there has
> > a free, standards compliant implimentation, yet Microsoft still
> > insists on breaking the uniformity and charging infinitely more for
> > it.
>
> I don't like what MS does, either. But, that doesn't obscure the
> fact from me that Windows XP is more uniform than Linuxes.
Let's rewrite that:
That doesn't obscure the fact that a single operating system product
release is more uniform than a vast family of operating system
releases from widely varying companies or community-based
development, running on hardware ranging from wristwatches to
mainframes.
Well, gee, that sort of changes the perspective.
But the funny bit is, it's *still* not right.
First off, which WinXP are you referring to? Would that be WinXP HE or
WinXP Pro? Or the embedded product?
...and is it running standalone, Workgroup, or Domain mode? Riddle me
this, but I've got apps which will run standalone/workstation, but break
in a domain logon (Frozen Bubble and Ad-Aware, to name two).
What's the user-level permission? I've got apps which will *only* with
administrator privs (and they're *not* system admin tools). Ad
nauseum.
If you move to server space, you'll find, for example, that Windows 2000
Server isn't a "product", it's a "family". Says right there on the boot
screen. Which I watched a dozen or more times between 22:30 and 7:15
Monday night / Tuesday morning as I attempted applying SP2 and found
myself in an immediate BSOD/reboot. Hell, Debian unstable doesn't break
like that. Hitting an eWeek forum, I found my experience was not at all
rare. Longhorn, not yet released, is already spoken of in at least a
half-dozen flavors.
> The Intel compiler which runs on RedHat doesn't run on Debian, whereas
> Acrobat reader which runs on a Windows XP machine will run on another.
It will run on most Linuxes as well -- the same binary -- under WINE.
Your point?
> That's not a fair comparison.
Glad to see you comprehend that. Let's discard it then.
> By the way, the Intel compiler doesn't run on Debian because our
> thread library doesn't comply with the POSIX standard. At least so
> I heard.
How about a little less of "so I heard" and a little more of just
fscking Googling it, eh?
> Standard compliance on this level is a faraway goal.
> If there were a single, comprehensible standard of Unix,
It's called GNU/Linux.
> and every brand of Linux/Unix follows it,
It's called LSB.
Incidentally, you might want to look up the many, many statements by
various RH execs (I'm trying to remember the name of the Brit or
'Strayan guy, heard him say as much in person at an SVLUG meeting
~1999/2000. Robert Hart, IIRC.
RH *is* now LSB compliant (or advertises same), but resisted the push
for a long time. Debian's status is reported periodically, last I
recall it was missing only a very few points, though this may be out of
date.
http://people.debian.org/~taggart/lsb
LSB compliance in Debian is, in fact, supported by a package. I'll give
you a hint in searching for it: it contains the letters L, S, and B.
> source programs of open source software wouldn't need those ugly
> "#ifdef _SOLARIS_9_" etc.
Oh yeah, and Solaris is *so* free software.
I'd give you a clue, but I'm waiting for the market price to climb for
maximum ROI.
> That's why commercial software vendors say something like
> "Supported OSs: Solaris 9 and 10; Aix such-and-such; . . .".
> That's understandable. They have to test their program
> extensively before its release and they have to get ready to
> receive questions and complaints from the customers. That incurs
> a LOT of resources (money and manpower), I guess.
You're moving goalposts here.
*Binary* support (which you've been talking about to date) is markedly
different than _user_ support.
The former is a matter of sticking to standards and writing code that
will build and run on a given platform. Which despite your various
vacuuous protestations, really ain't that tough.
End-user support is the giant sucking chest wound of the software
industry. It's expensive. Users vary all over the map, from to smart
for their own good to barely smart enough to breath. Walking someone
through a problem over a phone line pretty much completely sucks at
best. My own experiences range from dealing with other programmers,
DBAs, and GNU/Linux experts. I've talked friends and cow-orkers through
various problems -- some get it, some don't (and Mom is absolutely
impossible). I spend a fair bit of time on the #debian IRC channel,
where some people just need a one liner, some need a remote system
recovered (I'm averaging about 50% success there), and others exhibit
undeniable signs of a brain-host rejection syndrome. I work with kids
aged 6-18 now, and see in general a huge range of aptitudes, ability,
and experience.
For large support organizations, front-tier tech support is largely
script-driven, and relies on behing able to walk any old idiot off the
street through point-and-drool menus. End-user support is uniformly
atrocious. By contrast I've had excellent experiences with SAS's
support (particularly once you're not dealing iwth legacy MS Windows
support staff). But their organization is geered at enterprise support
and has staff with a decade or more's experience. Many of whom are
genuinely wonderful to talk to (thanks again, Gretel ;-). WRQ talked me
through an X server configuration on Win95 some years back, for about an
hour, and it turned out I *was* talking to a brain surgeon (well,
neurobiology grad student). Those are exceptional cases.
So, yes, there *is* an argument against providing support across a wide
range of cases, *if* you subscribe to the phone-script oriented model of
user support.
However, this neglects two additional observations I've made over the
years:
- Vendor support is virtually *always* inferior to _user_ support.
The exception is in some instances of application bugs in
closed-source software. The reason is simple: support staff rarely
use the application they support, and harely ever in ways that the
userbase is accustomed to it. It's users who have the day-to-day,
in-the-trenches experience with the product and its application. As
a consequence, newsgroup, mailing list, and IRC support is virtually
always more targeted, faster, and more accurate than vendor support.
It's also considerably less expensive for the vendor.
- Windows is sufficiently non-programmatic that it's very difficult to
make assessments of the user's environment and/or what the
application is doing. By contrast, there's a long tradition in Unix
environments of automating system discovery, ranging from systems
such as automake to the "system-info" script I wrote based on the
Kernel bug report document. In the case of the latter, I realized
that all the information requested in the document was determinable
from various system commands, files, or /proc features, and rewrote
the document as a "here" document shell script which effectively
writes itself. Knoppix is an example of scripted system discovery
which works sufficiently well to be able to boot a CD-based Linux on
a very wide range of x86 hardware. Tools such as strace and ltrace
allow one to determine the execution path of applications, and with
proper support, you can attach a debugger to an application and step
through its execution.
But, you say, the end-user doesn't know how to use those tools.
The end-user doesn't *need* to know how. The vendor can simply
provide a script which automates a debug and info-gathering run.
The customer runs the script (or for mouth breathers, support runs
it remotely via SSH or similar), and a report log is generated and
sent to the vendor.
Why this last mode hasn't been picked up by more ISVs I really don't
know. Probably too much fascination by shiny aqua gadgets. However, an
LSB-compliant Linux base offers far better scaling opportunities for
end-user support than Windows would.
> Some open source software like GNU emacs runs on most Unixes.
> I bet a LOT of resources went into it.
*MOST* core free software runs on pretty damned near *every* Unix.
Hell, much of it runs on legacy MS Windows (Cygwin, MS SFU, MKS, and
various third-party ports), VMS, Mainframe, OS/2, Mac....).
> By the way, I know apt is much better than rpm. I'm not saying RH
> is technically "better" than Debian. I'm not saying Windows XP is
> better than Linux. I'm trying to explain why commercial vendors
> are reluctant to develop software to run on all Linuxes, or on all
> Unixes, for that matter.
Darwinian selection at work.
Peace.
--
Karsten M. Self <[EMAIL PROTECTED]> http://linuxmafia.com/~karsten
Ceterum censeo, Caldera delenda est.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
