[I've made some big cuts. If I cut out anything you think I should have
addressed then feel free to bring it up again.]
On Fri, 2 Apr 1999, Ed Cogburn wrote:
> Bruce Sass wrote:
> > On Thu, 1 Apr 1999, Ed Cogburn wrote:
> > > <...> 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.
It is those kinds of differences that make Debian superior to RH
(or so I've read ;) ).
<...>
> > 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.
Programs that hard code file locations are poorly written <period>.
OSS programs that do so will be replaced by versions that do not.
Non-OSS programs that do that will not be widely accepted in the Linux
world because they cause too many problems.
This is just one more issue I see as self regulating.
Remember, this is the UNIX world, not the MS "one" world (although
you'd never know it by looking at some of the programs out there).
> 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.
This is a problem, environment variables are the solution.
A program that is so closely tied to another that it needs to parse the
config files itself will probably have synchronous releases (and perhaps
even close coordination between them). Dpkg is a special case, either
it needs to know the gory details about every package installable, or
leave the config stuff up to the program it is installing (which is what
it does).
Trying to force programmers to use a specific format for config files
will not work, identifying what needs to be exported so that the
software can coexist with other tools on the system will.
The real problem is not the multitude of config methods and file formats
around, it is a lack of understanding on the programmers part with
respect to the UNIX philosophy.
> 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. <...>
This is not an issue because a properly written UNIX/Linux program will
fit into any UNIX/Linux system with only minor tweaking.
> > > 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.
Nothing, unless you think that your way is better than the other ways.
<...>
> > 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.
If OSS goes mainstream it will be because the commercial world CEO's see
an advantage to doing so, the programmers will have little choice in the
matter.
> > > > 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.
ditto
> > > 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.
Instead of making money off the software, they will make money off the
manuals that go with it. It is really just an extension of one of the
solutions to the pirated software problem that existed in the early and
mid-80's. Think about it... what is more important, the code that can
be reproduced for next to nothing, or the knowledge of how to make use
of the code. If I was doing such a project I would give away the
program and charge for the documentation and online help.
> > > 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.
Hmmm, I think you missed the point...
Why are they even looking at RH when MS does what they want (wrt apps)?
> > > > 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.
>
<...>
> 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.
You can take the default RH packages and install them on Debian, then
they will both have the same "look-n-feel"... if that is the only
difference between the two distributions then what is the point of
choosing between RH and Debian (aside from the philosophical).
I think we have covered just about everything, so I am going to
summarize why I don't think we (the Linux community) need to worry
about RH becoming the MS of the Linux world.
RH is a Linux system and Linux (being a UNIX work-alike) has mechanisms
and standards that ensure compatibility between its different flavours.
If RH was to break with the UNIX/Linux way of doing thing they would end
up annoying their users, who have probably switched to Linux because
they see an advantage to the UNIX/Linux way. There is the possibility
that greed takes over and RH tries to dictate how things should be, but
this is precisely the major complaint I have heard about MS, and I find
it unlikely that RH will make that same mistake. Technically there is
not much RH could do to squeeze out other Linux distributions, they
could force other distributions to either adopt their way or jump
through a bunch of hoops so that users of the other distributions can
run RH developed applications... this is really no different than the
current situation where most applications are developed without a
specific distribution in mind. So, if RH does manage to become the
defacto standard of the Linux world, it will probably be because they
have worked harder in the marketing arena than the other distributions.
Later,
Bruce
