[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: RedHat = MS-Linux



Bruce Sass wrote:
> 
> On Thu, 1 Apr 1999, Ed Cogburn wrote:
> 
>
> [snip]
>
> > I don't want
> > to see RH disappear any more than I want to see Debian disappear.
> > I want to see enough cooperation between distros that allows app
> > makers to write software that will work on most distros without
> > major effort on the app maker's part.  I'd like to see healthy
> > competition between the distros, but not at the expense of
> > application compatibility.
> 
> I suspect that we have a difference of opinion about what a "major
> effort" is and when compatibility is broken.  In my mind a computer is a
> tool, not an appliance. Either you learn how to use the tool and make it
> do what you want, or you complain to the developers until they do it for
> you.


	On compatibility, you're right.  My major problem is a general
lack of knowledge about other distro types.  I used RH for a very
little while a *long* time ago, and have used no other distro.  I
have to depend on what others have said.
	The tool/appliance issue is much more difficult.  One the one
hand understand the need to learn about some thing before being
able to use that thing effectively, yet I know very smart people
who will not do something like learning Linux if it requires a
significant learning curve.  They just want to get something done,
and basically they are satisfied with the point-n-click interface
of Win and the apps that are important to them.  I guess I can
empathize with both sides.


> 
> <...>
> >       There are differences between RH and Deb, primarily in the
> > directory tree layout, and especially in places like /etc./ and
> > /var/ (I think).  Its not clear to me what the percentage of RH
> > packages that can't be easily converted would be.  Anybody with
> > better knowledge like to speak up here?
> 
> ditto that question.
> 
> Filesystem differences are trivial, that is what "ln" is for, right?


	For the issue of a software package that needs to get a daemon 
running at bootup, I don't think the problem is trivial.  The
layout and use of the /etc/init.d and /etc/rc*.d dirs is (I've
read) far from compatible between RH and Deb.


> 
> >       I don't think we need to invent a 'patent' issue to effect that
> > kind of fragmentation.
> 
> I was just trying to rationalize how a piece of software could be
> unavailable and not reproducible by the OSS community.  I didn't invent
> a patent issue, it just seems to be the only thing to prevent the
> creation of an OSS version of any piece of software.


	If the objective is an RH clone, and you can find a critical mass
of developers willing to hack away, then there wouldn't be too
much of a problem.  RH would have to go to extraordinary means to
keep the OSS people from duplicating anything that RH does.  The
objective of the LSB though is not to establish one Linux distro
with the same identical dir structure and system maintenance tools
and look-n-feel, the objective is to allow apps to be loadable on
otherwise different distros that adhere to an underlying common
base structure.


> 
> > As the 'Heinz ketchup' manifesto talked
> > about, its brand name recognition and user perception that matters
> > in a commercial market.  All it takes is a user perception that RH
> > is the only distro that matters, and we'll end up seeing companies
> > releasing software meant for RH, and not bothering to support any
> > distro that isn't RH compatible.
> 
> But what would make the software incompatible.
> Whose yardstick.
> i386 RH and i386 Debian are compatible.
> I installed a pine 4.04 .rpm, using _RPM_, on my Debian system.
> It worked just fine.  Once I told dpkg about it (by modifying the dpkg
> DB entry for the pine 3.96 .deb) you couldn't tell it was an alien
> unless you looked at the location of the config files.
                           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^

	Now imagine a situation where a lib or program is only available
as an RPM, which has other programs that depend on its config
files and/or their location.  Are there not several .debs that
have an install script that needs to look at or modify another
packages config stuff?  At the very least, .deb scripts would have
to know about the multiple locations of config files and possibly
even different syntax for config files.  Is this problem solvable?
Sure, with a quite of bit of hacking.  Can you always get enough
programmers/developers to work on this kind of problem every time
RH decides to change something to a non-standard method?  Even if
the answer here is yes also, Deb will always be a step behind,
which might be exactly where other distros (RH) would want us to
be.
	Please keep in mind, though, that my main concern beyond
technical incompatibilities is a situation where RH is so
dominant, app makers simply decide not to even support other
distros.  I know most Deb users probably aren't concerned with
what happens on the commercial side of Linux market, but a few of
us are.


> 
> [snip]
> 
> > Also, if RH tries using
> > proprietary libs on their system, its entirely possible for a
> > group of Debian hackers to bang heads and come up with GPL clone
> > of those libs, but this, to me, would be a bad signal anyway, as
> > it would in essence suggest that Debian is becoming a clone of RH
> > out of necessity.
> 
> The way I see it...
> If you could take any package and install it on any system, and it works
> without tweaking stuff, then those systems are clones of each other on a
> very basic level.


	In the case of *applications*, whats wrong with compatibility at
a 'very basic level'?  System and utility packages can be
different for different distros, but for apps the whole idea of
LSB is to allow app packages be usable on different dists.


> 
> > Its the *perception* of Linux by folks
> > *outside* the OSS community that matters, for my concerns.
> <...>
> 
> I've never been hampered by what others think. :) ;) :O
> I hear you, it is just that the commercial world has never held much
> interest for me and I don't get worked up about it or its failings.


	I understand you here.  I will always be a Debian fan regardless
of what happens to Linux in the commercial world.


> 
> >       OSS can work, I see that in things like the kernel, GIMP, and
> > even Debian itself.  OSS doesn't work everywhere though, because
> > the successful examples of opensource have to appeal to
> > significant number of developers for the critical threshold of
> > user/developer support to be reached.  What would the kernel look
> > like today if Linus was still working on it alone?
> >       For me, I want access to the commercial side, even if I end up
> > using an OSS equivalent (like AbiWord over Wordperfect).  The
> > single most obvious shortcoming of OSS is the absence of
> > sophisticated gaming software, something that OSS may never be
> > able to overcome due to an overall lack of developer interest.
> 
> Until, of course, OSS hits the mainstream in a big way, and OSS
> developers can make money/fame off of gamers.


	OSS will be a power to be reckoned with in the commercial world,
but, despite being a supporter, I'm not sure if OSS can hit the
*mainstream* in a 'big way'.  The biggest problem is something you
said above, "the commercial world has never held much interest for
me".  I suspect most programmers in the OSS feel the same, and
thus will not push OSS hard into the mainstream basically because
of a lack of interest.


> 
> >
> >       I don't trust anyone with unchecked power, and as far as the
> > commercial side of the Linux market is concerned, RH already has
> > it.
> 
> At least we have one thing in common. :)


	Great, we're making progress ... I think.  :-)


> 
> > > wait awhile
> >
> >       Ok, :-)  how long should I wait for a good equivalent of
> > Wordperfect 8?  How about a Railroad Tycoon II clone?
> 
> Until OSS hits the mainstream in a big way.


	See above, about OSS and the mainstream.


> 
> >       Only if the questions are coming from *developers*.  Developers
> > will work, for free, only on things that interest them, and thats
> > perfectly fine.  Alas, hacking the kernel is fun, but hacking a
> > Wordperfect 8 or MS Word clone is apparently not, otherwise we
> > would have gotten 'GNU PerfectWord' years ago.
> 
> They also work on things that will bring them recognition.
> They don't appear to work on stuff that could ostracize them with the
> rest of the OSS developer community, which appears to have been the GNU
> community (for the most part)... but that will change as OSS hits the
> mainstream and money becomes a factor.


	Hmmm, I don't know about this.  I have a hard time seeing how
money could become a major factor.  The AbiSource project
(commercial company which intends to write GPL'd software,
beginning with a word processor called AbiWord) is interesting,
but I don't know how they can succeed.


> 
> >       What I'm referring to here is what I foresee as a 'split' in the
> > Linux community.  On one side will be us, the OSS believers, the
> > developers (programmers willing to spend free time coding software
> > for the rest of us), the folk who will put up with anything to
> > avoid assisting MS's monopoly.  On the other side will be the
> > Linux commercial interests, RH and similar, the commercial app
> > makers, and many of the more recent incoming folk who will not, at
> > least initially, be put off by a RH dominated Linux world.
> >       Sure the users will start looking for something else, but with a
> > monopoly, can they find it?
> 
> MS has pretty close to a monopoly, and Linux is an alternative that many
> are finding.  Why should that mechanism change if Linux becomes
> dominated by one distribution?  An alternative to MS means a non-MS
> compatible OS, only because MS is not OSS; an alternative to RH could
> easily include a different flavour of Linux because Linux is OSS, the
> compatibility issue then disappears (except for a few special cases).
> 
> > If they can find the [commercial]
> > apps they want on RH, will they even bother to educate themselves
> > about alternatives?
> 
> The MS world has more apps than Linux, why are people looking for
> alternatives now?


	MS and Linux are fundamentally non-compatible, and despite the
Wine project, I don't see any change happening anytime soon. 
People choosing Linux understand that they are giving up all their
Win apps, and have to find equivalent software on Linux, assuming
equivalents actually exist.  The situation between RH vs. all the
other dists is very different from the Win vs. Linux issue.
	OSS doesn't guarantee competition or choice.  People are choosing
RH because of marketing and because everyone appears to be calling
RH the standard.  The presence of a similar alternative won't
change that.


> 
> <...>
> 
> > > I like variety and do not see a problem with it,
> > > unless the deck gets stacked in favour of one distribution over the
> > > others.
> >
> >       I love variety too, which is precisely why I don't want to see
> > the deck all stacked up in favor of RH.
> 
> But you want to see apps that install and run on any Linux system
> without tweaking, right.  In what area of the OS do you want to see
> variety... in distribution name only?
> Variety means differences, that means incompatibilities.
> At least with Linux the incompatibilities are relatively minor.


	There is already several different dists:  dists for other
regions/languages (Pacific HiTech's dist for Japan and Asia), tiny
dists meant for embedded systems (Linux On A Floppy - I still
wonder how the hell they accomplished that), dists which support
different hardware (the dist precompiled for Pentium machines
instead of 80386), dists meant for enterprise servers (Caldera
stuff), and general use dists like RH and Deb.  Among the general
use crowd there is still plenty of room for differentiation,
namely in the installation and maintenance methods, and general
support provided.  The interface to the user can be different as
well (KDE/GNOME/other).  RH and Deb can have a very different
look-n-feel, can appeal to different kinds of users, yet provide a
similar enough of a base that can allow general app packages to be
installable and usable on both.


> 
> later,
> 
>         Bruce
> 


See ya.
-- 
Ed C.


Reply to: