Distributions considered harmful
Russell Nelson
software works because the users can be programmers, and everyone can
cooperate. But with the various distributions, we have
noncooperation. Guys, that's what the SysV people do, not us. They
feel a need to differentiate their product from the base System V
distribution from USL. So when they fix a bug, or add a feature, they
*don't* send it back to USL.
We can do better than that.
We've got at least four different package conventions (SLS, Slackware,
Debian and Yggdrasil). Why? No good reason I can see. FTP sites
carry these different distributions, most of which differ only slightly.
I feel that there is need, and room, for two Linux distributions, one
conservative, and the other radical. The conservative distribution is
probably the harder, and potentially more money-making, distribution
to do. It is marketed at Linux "users". People who don't want to
have to fiddle. People who are willing to pay for the software to
"just work". So the conservative distribution has its work (and
profit) cut out for it.
And there's plenty of money to be made on the radical distribution,
because it's obvious that some people out there want the latest and
greatest, and they're willing to pay for it. "Who has the latest CD"
is the subject of a recent Usenet message.
And multiple distributions are not good, because they tend to fragment
the market. The Linux market is small enough as it is -- we don't
need to make it smaller! If I'm running Slackware, I don't feel like
I can purchase SLS's support package. Or if I've bought Yggdrasil's
CD-ROM, can I install an slackware package? And not break everything?
And Adam's not doing himself any favors by not creating an FTPable
Yggdrasil distribution. In the free software market, you create
business by giving away your software to create a need for your
services. The less you give away your software, the less your
services are needed.
And Debian, while it has the support and name of the FSF, is just
plain not needed. Much, much better to fix the problems with
Slackware, SLS, or Yggdrasil.
We should start with a merger between SLS and Slackware. Send your
requests for same to Peter and Patrick, imploring them to cooperate
for the betterment of all. Yes, they've had words, but they should
still be able to work together.
So who am I to be giving out all this free advice? Why, just someone
who's been supporting himself for 2.5 years by selling support for
free software.
--
-russ <nel...@crynwr.com> ftp.msen.com:pub/vendor/crynwr/crynwr.wav
Crynwr Software | Crynwr Software sells packet driver support | ask4 PGP key
11 Grant St. | +1 315 268 1925 (9201 FAX) | Quakers do it in the light
Potsdam, NY 13676 | LPF member - ask me about the harm software patents do.
Jeff Epler
>I don't think the current state of Linux distributions is good. Free
>software works because the users can be programmers, and everyone can
>cooperate. But with the various distributions, we have
>noncooperation.
I don't have that much of a problem with the fact that there are
different distributions. Of course, I may not like some of them
much...
We've got MCC, the small system. Slackware, the complete system.
SLS, the broken system with exactly one feature that might be nice to
have elsewhere. Debian, the release that doesn't really exist yet.
Yggdrasil and the other CDrom distributions, for those with slow or
nonexistant linkage to the net..
They all have their place, and the fact that there are so many doesn't
really detract from them.
>Guys, that's what the SysV people do, not us. They
>feel a need to differentiate their product from the base System V
>distribution from USL. So when they fix a bug, or add a feature, they
>*don't* send it back to USL.
I don't know that this is really the case with the Linux
distributions. The only thing I can think of that could be called
'truly innovative' is the SLS Modular Kernel. I don't know if it's
not a part of the standard kernel because it is still quirky (I see
many posts about people trying to compile the SLS kernel, but I
haven't read any of them), because the SLS maintainer doesn't want the
mainstrean kernel to have these features (This would likely violate
the GPL), or because Linus just doesn't want those drivers there...
Are there other such situations you're thinking of?
>We've got at least four different package conventions (SLS, Slackware,
>Debian and Yggdrasil). Why? No good reason I can see. FTP sites
>carry these different distributions, most of which differ only slightly.
It would be nice if there was a standardization that allowed
installation of a package from any distribution, even if you don't
have that distribution. However, I don't think we're that far from
it. On my MCC system I was able to effortlessly install the
Ghostscript and Ghostview binaries from Slackware. Slackware easily
accepted tinyX and ran it admirably. Slackware used to recommend
using the TeX package from SLS because it didn't have its own. The
differences are primarily cosmetic, and have probably lessened since
FSSTND. Usually the procedure is:
cd /
tar xzvf PACKAGE.tar.gz
<remove junk files particular to distribution PACKAGE comes from>
Three steps isn't very much at all...
>I feel that there is need, and room, for two Linux distributions, one
>conservative, and the other radical. The conservative distribution is
>probably the harder, and potentially more money-making, distribution
>to do. It is marketed at Linux "users". People who don't want to
>have to fiddle. People who are willing to pay for the software to
>"just work". So the conservative distribution has its work (and
>profit) cut out for it.
If you're asking for this, why not just have one distribution with two
personalities? Slackware and SLS come close to this with the concept
of 'disk sets', and with MCC it's easy to pick and choose which
packages you want since it is somewhat less than rigid in its disk
packing. Perhaps the "users" version would be a stable libc, a 1.0.x
kernel, X 2.1.1 and formatted man pages, while the "radical"/"hacker"
version would include the necessities of GCC, 1.1.x kernel, one of the
unsupported X 3.0's floting around, etc.
>And there's plenty of money to be made on the radical distribution,
>because it's obvious that some people out there want the latest and
>greatest, and they're willing to pay for it. "Who has the latest CD"
>is the subject of a recent Usenet message.
I don't think that keeping on the bleeding edge is something best done
by buying a new CD -- FTP is a much beter idea, for those who have it.
Installing new libc, gcc, kernel, or X is a pretty painless process..
The same for most software that will let me 'make install'.
>And multiple distributions are not good, because they tend to fragment
>the market. The Linux market is small enough as it is -- we don't
>need to make it smaller! If I'm running Slackware, I don't feel like
>I can purchase SLS's support package. Or if I've bought Yggdrasil's
>CD-ROM, can I install an slackware package? And not break everything?
Well, the answer to this is to take a chance that you might break
everything...
>We should start with a merger between SLS and Slackware. Send your
>requests for same to Peter and Patrick, imploring them to cooperate
>for the betterment of all. Yes, they've had words, but they should
>still be able to work together.
I don't need The One True Distribution (But if I made my own, it would
be TOTDOLinux probably), and especially not as a union of SLS and
Slackware. I'm sure someone does, but the fact that I don't want it
and can proceed to not have it but still have Linux is what makes the
idea of many distributions a good idea.
Of course, my views here are more of the hackerish sort, not ones
suitable for those who are going to use Linux in an atmosphere where
there are overworked admins and users who don't understand. The vast
majority of the software I have here comes not from the MCC 0.99.10+ I
installed long ago, but from source code I found, liked, and compiled
myself. Most of the rest is binary replacements of large packages,
such as libc, XFree86 or gcc, packaged independantly of any
distribution. And while it has made a bit of a wilderness out of my
/usr, it has what I need 95% of the time.
The distribution isn't the be-all or end-all of Linux... They're a
base from which your personal Linux machine will grow. Very few Linux
users can really say 'My computer is Slackware' or 'My computer is
MCC', because most everything gets taken out and replaced... But it's
still nice to start out with a Linux that is close to your particular
'personality'. And the diversity of distrubutions is the best way to
get that right now.
Jeff
--
Jeff Epler echo "kill -9 -1" | su jep...@herbie.unl.edu
____ "Nuke the unborn gay whales for Jesus"
\bi/ -- Never seen on a protest sign
\/ 1.5<kinsey<2.5 Running Linux 1.1.11 -- DOS is to boot DOOM!
Dave Safford
<I don't think the current state of Linux distributions is good.
While I understand your point, and respect your frustration, let me
offer a counter viewpoint.
I think any of the major linux distributions are outstanding efforts
that are as good as, if not superior to commercial distributions
such as Solaris. The fact that linux users have a choice among several
strong distributions is certainly better than having no choices.
On a Sun there is no operating system distribution competition, and
as a result, you see almost no movement toward including significant
features/tools that we have come to expect in any decent linux
distribution. Why does Solaris still not have emacs, mosaic, archie,
ftptool, mtools, perl, tcl/tk, gnu tar, tn3270, gzip, and patch,
or at least put out a catalyst cdrom with these as binary and source packages?
<We've got at least four different package conventions (SLS, Slackware,
<Debian and Yggdrasil). Why? No good reason I can see. FTP sites
<carry these different distributions, most of which differ only slightly.
There are substantial differences in the distributions, particularly in content,
organization of source code, installation method, and kernel module support.
The good news is that the FSSTND effort has been accepted by all major
releases, so that users will see a consistent file layout between
distributions, while still enjoying their differences.
<And multiple distributions are not good, because they tend to fragment
<the market. The Linux market is small enough as it is -- we don't
<need to make it smaller!
1. Multiple distributions increase the market. Different users have different
needs and preferences that are not currently (and may never) be met by any
one release. If we don't offer what they want, they will go elsewhere.
If one distribution does offer everything to everyone, then it will
succeed, and the others disappear anyway.
2. Competition between the releases has been a tremendous force for
innovation and progress. It is a story that keeps repeating -- one
distribution adds a new feature, and if it works, it soon shows up
in the others. Do you think that Slackware or Debian would be where they
are now without learning from their predecessors?
<We should start with a merger between SLS and Slackware. Send your
<requests for same to Peter and Patrick, imploring them to cooperate
<for the betterment of all. Yes, they've had words, but they should
<still be able to work together.
I fear that a forced cooperation would serve only to slow down their
efforts, and reduce a user's choices.
My vote is for free competition, rather than coerced standardization.
dave safford
Daniel Quinlan
Brandon Allbery wrote:
(about iBCS binary "standard paths")
>> [...] (I brought this up once on FSSTND and was bluntly told that
>> that was unimportant. I haven't bothered to mention it since; it
>> may not be important to them, but in my environment it's essential.)
Daniel Quinlan responded :
> If you haven't bothered to bring something up a second time, then
> don't blame it on FSSTND. In my FSSTND archives, I have a *single*
> message from you (buried in over 6MB of other messages), mentioning
> iBCS standard paths -- dated Dec 19. And now, May is almost over.
> The first public version wasn't even released until February. You
> are being somewhat unrealistic if a single message about it is going
> to start a discussion.
I should add that I am more than willing to discuss something that
concerns you, Brandon. You've already given quite a bit to the
discussion, IMO, and it is probably worth some amount of attention.
In other words, pouting over a five month old message isn't going to
get anyone anywhere.
Dan
--
Daniel Quinlan <qui...@spectrum.cs.bucknell.edu>
Daniel Barlow
In article <NELSON.94M...@crynwr.crynwr.com> nel...@crynwr.crynwr.com (Russell Nelson) writes:
>... multiple distributions are not good, because they tend to fragment
>the market. The Linux market is small enough as it is -- we don't
>need to make it smaller! If I'm running Slackware, I don't feel like
>I can purchase SLS's support package. Or if I've bought Yggdrasil's
>CD-ROM, can I install an slackware package? And not break everything?
Two points I'd make here:
(a) I can't see that it matters too much. If the distributions are
only slightly different, why does it matter which you install? If
you're running Slackware and SLS won't sell you support, buy it
somewhere else. (One of) the point(s) of the GPL is after all that
you get your software where you like and pay whoever you want for
service (subject to their having offered support, of course :-)
(b) What do you mean 'the market'? All the distributions are
sufficiently similar that programs written for one will work on the
others - hell, probably even the *Novell* distribution will run
everyone else's binaries :-)
>We should start with a merger between SLS and Slackware. Send your
>requests for same to Peter and Patrick, imploring them to cooperate
>for the betterment of all. Yes, they've had words, but they should
>still be able to work together.
We could start with a merger between SLS and the kernel. I don't know
how much of their module stuff has been incorporated into the standard
kernel, but given that I had to recompile it the other day to get
parallel printer support, probably not much.
Daniel
--
Daniel...@sjc.ox.ac.uk dba...@teaching.physics.ox.ac.uk
"He'd never wanted much, except perhaps to be left alone and not woken up
until midday" -- Moving Pictures, Terry Pratchett
Alan Cox
>nel...@crynwr.crynwr.com (Russell Nelson) writes:
>
>>I don't think the current state of Linux distributions is good. Free
>>software works because the users can be programmers, and everyone can
>>cooperate. But with the various distributions, we have
>>noncooperation.
>
>I don't have that much of a problem with the fact that there are
>different distributions. Of course, I may not like some of them
>much...
This suggests to me that we need a more detailed FSSTND and a standard
for package formatting.
Alan
Daniel Quinlan
jep...@herbie.unl.edu (Jeff Epler) says:
>> using the TeX package from SLS because it didn't have its own. The
>> differences are primarily cosmetic, and have probably lessened since
>> FSSTND. Usually the procedure is:
Most Linux distributions *still* have an out-of-whack TeX directory
structure. /usr/TeX is not standard, it's a relic from SLS.
b...@kf8nh.wariat.org (Brandon S. Allbery) writes:
> In any case, I'm no longer worrying about distributions that much
> because FSSTND (and Debian in particular) seem to be h*ll-bent on
> disenfranchising folks who need to be compatible with other systems
> for network mounting or use of iBCS software which wants iBCS
> standard paths. (I brought this up once on FSSTND and was bluntly
> told that that was unimportant. I haven't bothered to mention it
> since; it may not be important to them, but in my environment it's
> essential.)
If you haven't bothered to bring something up a second time, then
don't blame it on FSSTND. In my FSSTND archives, I have a *single*
message from you (buried in over 6MB of other messages), mentioning
iBCS standard paths -- dated Dec 19. And now, May is almost over.
The first public version wasn't even released until February. You
are being somewhat unrealistic if a single message about it is going
to start a discussion.
Dan
--
Daniel Quinlan <qui...@spectrum.cs.bucknell.edu>
Alan Cox
>This one will run and run!
>We could start with a merger between SLS and the kernel. I don't know
>how much of their module stuff has been incorporated into the standard
>kernel, but given that I had to recompile it the other day to get
>parallel printer support, probably not much.
I have stuff for adding modules support to network drivers that has
been contributed by Bjorn Eckwall (sp ?) of the DE600 driver fame. Until we
have nice working module drivers I'm not going to start modularising the
protocol layers.
Alan
David Marples
This suggests to me that we need a more detailed FSSTND and a standard
for package formatting.
Yep, seems entirely reasonable. Putting stuff in standard directories
as specified by a (more detailed) FSSTND and also making a note of
where you've put stuff (in a standard format) in another standard
place so that you can take it back out..... Thumbs in for that.
That way I can take what packages I want from wherever I want and hook
them together to make the <Dave> installation - arguments about what is
best go away. I can also have a standard tool for getting rid of them
again, turning it into the <Daves_Boss_is_Around> installation. Hell,
I could even make a CD of all the things I think are wonderful, take
lots of orders and then not produce it.....
It wouldn't be that difficult to do either - an extension of make
install for a source package and a tar -zxvf for execs - no fancy
tools needed.
comment anyone?
DAVE
D.J.M...@strath.ac.uk
Stuart Herbert
: I don't think the current state of Linux distributions is good.
Okay, that's a reasonable point.
: Free
: software works because the users can be programmers, and everyone can
: cooperate.
Forgive me - what is your definition of 'free'? Given your previous plea
to use the GPL, I'll assume that one.
: But with the various distributions, we have noncooperation.
In what way? I don't doubt your assertion - I'd just like more information.
: Guys, that's what the SysV people do, not us. They
: feel a need to differentiate their product from the base System V
: distribution from USL. So when they fix a bug, or add a feature, they
: *don't* send it back to USL.
And these virulent bouts of featuritis are the reason that 'standards' are
such a mockery.
: We can do better than that.
Sorry - *who* can do better than that? ;)
: We've got at least four different package conventions (SLS, Slackware,
: Debian and Yggdrasil). Why? No good reason I can see. FTP sites
: carry these different distributions, most of which differ only slightly.
It's called freedom of choice. You forget that these distributions are
NOT Linux - they are a collection of software which has been packaged
together with the Linux kernel. (Over-simplification, I know :)
: I feel that there is need, and room, for two Linux distributions, one
: conservative, and the other radical.
Two distributions? Hrm ...
: The conservative distribution is
: probably the harder, and potentially more money-making, distribution
: to do. It is marketed at Linux "users". People who don't want to
: have to fiddle. People who are willing to pay for the software to
: "just work". So the conservative distribution has its work (and
: profit) cut out for it.
So, what goes in this 'conservative' distribution? Saying that it is
aimed at Linux 'users' does nothing to define its content. Define a
Linux 'user'.
: And there's plenty of money to be made on the radical distribution,
: because it's obvious that some people out there want the latest and
: greatest, and they're willing to pay for it. "Who has the latest CD"
: is the subject of a recent Usenet message.
So, let me get this straight. You're saying that there should be two
distributions, one of which is a later one than the other (nothing else
is inferred in your post). Correct me if I'm wrong, but aren't most of
the modifications to software which is included actually necessary to
maintain compatability (I've just been reading a thread about how fast
things break on Linux ...)
: And multiple distributions are not good, because they tend to fragment
: the market.
Why? Everyone who uses one of those distributions has to be using Linux.
Linux itself is common to all of those distributions.
: The Linux market is small enough as it is -- we don't
: need to make it smaller!
You're not. By offering a choice, there's something for everyone, and
people will find what's right for them.
: If I'm running Slackware, I don't feel like
: I can purchase SLS's support package. Or if I've bought Yggdrasil's
: CD-ROM, can I install an slackware package? And not break everything?
Ah, now we're getting to what all this is about ... it's not the *content*,
it's the inter-operability.
There is a solution to that ...
: And Adam's not doing himself any favors by not creating an FTPable
: Yggdrasil distribution. In the free software market, you create
: business by giving away your software to create a need for your
: services. The less you give away your software, the less your
: services are needed.
Right, we get back to this definition of 'free'. You're a champion of the
GPL. The GPL does NOT define free software as software that you HAVE to
'give away'. The definition of freedom is built around access to the source
code itself.
It is one business practice to 'give' your software away, and sell support,
but having a commercial distribution, where you PERHAPS sell support on top,
is just as viable a business. Adam is obviously making enough to keep him
in business :)
: And Debian, while it has the support and name of the FSF, is just
: plain not needed. Much, much better to fix the problems with
: Slackware, SLS, or Yggdrasil.
Why is it not needed?
FYI, Debian looks like being adopted by at least one corner of the Linux
community that, instead of sitting on USENET complaining at these people
who have put in a LOT of hard work so we can enjoy Linux, are actively
seeking to expand the Linux community. I've used machines which have had
Debian installed, and I've found it okay, and I look forward to its
completion.
: We should start with a merger between SLS and Slackware. Send your
: requests for same to Peter and Patrick, imploring them to cooperate
: for the betterment of all. Yes, they've had words, but they should
: still be able to work together.
Mmm ... you're not quite hitting the nail on the head.
What we need aren't so much complete distributions, but a standard way of
packaging the Linux software. That means a standard installation system,
standard documentation conventions, standard minimum utilities, which
everyone adhears to.
Slackware has a nice installation system, which copes with uninstalls as
well. I've not played with any other distribution in this area. Standard
documentation - sorry, but that's becoming a joke. You've got man and FSF's
info, and there's interest in using html for more documentation. This needs
consolidating. Minimum utilities? I have to admit that I've no idea whether
anyone has made such a standard. If not, it's needed.
My point to you is that we shouldn't be relying on a small group of people,
who do a fantastic job, to be producing packages. The people who write/port
packages should take the time to make what's necessary to support a *standard*
installation utility.
: So who am I to be giving out all this free advice? Why, just someone
: who's been supporting himself for 2.5 years by selling support for
: free software.
And that's your problem. 'Supporting himself'.
Stuart
--
Stuart Herbert -- S.He...@shef.ac.uk
Andrew R. Tefft
>In article <2rbcg5$p...@news.tamu.edu>, drs...@net.tamu.edu says:
>+---------------
>| On a Sun there is no operating system distribution competition, and
>| as a result, you see almost no movement toward including significant
>| features/tools that we have come to expect in any decent linux
>| distribution. Why does Solaris still not have emacs, mosaic, archie,
>| ftptool, mtools, perl, tcl/tk, gnu tar, tn3270, gzip, and patch,
>
>Your argument here falls flat with one counter-question: Why doesn't SCO
>provide emacs, Mosaic, archie, ftptool, mtools, perl, tcl/tk, ...? After all,
Gee, the reason nobody includes this stuff is probably because they aren't
willing to support it without ownership of the code, and the authors aren't
about to give that away (or sell it).
---
Andy Tefft - new, expanded .sig - tef...@cs690-3.erie.ge.com
Matt Welsh
The Debian development project hopes to solve this problem.
We are working on a distribution of Linux that should resolve
all of the issues of incompatibility, version control, and
release stability shared by current distributions.
Note that this does not preclude the need for other distributions;
specifically, I hope that folks like Yggdrasil will continue to
make their distributions available with support. However, we hope
that Debian will emerge as the de facto standard. Things are already
moving forward by leaps and bounds.
Debian is currently in beta development, so I don't suggest it for
general use at this time. If you're a hacker and want to work on a
new distribution, you should look into Debian, however.
If you have questions about the Debian development project,
read the various documents on sunsite.unc.edu in
/pub/Linux/distributions/debian/info. I'll also field questions
about Debian, although the overall coordinator of the project
is Ian Murdock, aided by many others. But I won't solicit e-mail on
their behalf.
>And Debian, while it has the support and name of the FSF, is just
>plain not needed. Much, much better to fix the problems with
>Slackware, SLS, or Yggdrasil.
I disagree, Russ. If you would take a look at the work that
has been done on Debian I think you'd agree that this is the
best route to take. Debian takes a very different development
philosophy than Slackware and SLS---it is developed and maintained
in an open, distributed environment. This is an extremely vital
aspect of the project, with benefits that SLS and Slackware
simply can't partake in.
Don't knock it until you've tried it, eh? If you're interested
in fixing the state of Linux distributions, please help us to
develop Debian.
Wayne Schlitt
> In any case, I'm no longer worrying about distributions that much because
> FSSTND (and Debian in particular) seem to be h*ll-bent on disenfranchising
> folks who need to be compatible with other systems for network mounting or use
> of iBCS software which wants iBCS standard paths.
Pardon my complete ignorance on what FSSTND specifies, but in what way
does it cause problems with networks? I thought it was supposed to be
very similar to SunOS/SVR4/Solaris.
-wayne
--
Vg'f _nznmvat_ ubj znal crbcyr jvyy eha fghss guebhtu ebg13 vs gur grkg
ybbxf tneoyrq, vfa'g vg?
Mike Jagdis
DM> Yep, seems entirely reasonable. Putting stuff in standard directories
DM> as specified by a (more detailed) FSSTND and also making a note of
DM> where you've put stuff (in a standard format) in another standard
DM> place so that you can take it back out..... Thumbs in for that.
Did this for the Purple Distribution back when SLS was a baby and boot 'n
root disks were the order of the day.
Packages live in their own directory hierarchies and have a map file that
describes how they fit in to a system (along with version numbers for
conflict resolution).
A (reasonably) simply tool keeps track of what packages are installed and
builds the target structure using the package maps. Multiple targets are
possible so /usr/X386 could be built separately for example (and possibly
mounted from elsewhere).
It's easy to uninstall packages.
It's easy to slide in upgrades.
It's easy to give a package to someone else - just tar it off your running
system (one of the main reasons I did it this way as it happens).
It never made it to an Internet site though. Every so often this thread
crops up and people say this is the sort of thing they might like. But every
time I say it exists the result is total apathy. It *may* make it to the all
new ftp.linux.org - but I'm on a modem here and it isn't likely to happen
unless there are others willing to use the format for their releases (i.e.
include a map file and some reasonably smart setup scripts).
DM> That way I can take what packages I want from wherever I
DM> want and hook them together to make the <Dave> installation
Exactly. It shouldn't be a case of having a particular distribution. Just a
case of having a collection of packages that you can put together and pull
apart like lego(tm).
Mike
David Marples
Hey, this is a good thing (tm).
* In a message originally to All, David Marples said:
DM> Yep, seems entirely reasonable. Putting stuff in standard directories
DM> as specified by a (more detailed) FSSTND and also making a note of
DM> where you've put stuff (in a standard format) in another standard
DM> place so that you can take it back out..... Thumbs in for that.
Did this for the Purple Distribution back when SLS was a baby and boot 'n
root disks were the order of the day.
Packages live in their own directory hierarchies and have a map file that
describes how they fit in to a system (along with version numbers for
conflict resolution).
A (reasonably) simply tool keeps track of what packages are installed and
builds the target structure using the package maps. Multiple targets are
possible so /usr/X386 could be built separately for example (and possibly
mounted from elsewhere).
It's easy to uninstall packages.
It's easy to slide in upgrades.
It's easy to give a package to someone else - just tar it off your running
system (one of the main reasons I did it this way as it happens).
That's the very fellow. How many times have I just wanted to upgrade
one package/port it onto a new machine/just get rid of it 'cos I'm out
of room?
It never made it to an Internet site though. Every so often this thread
crops up and people say this is the sort of thing they might like. But every
time I say it exists the result is total apathy. It *may* make it to the all
new ftp.linux.org - but I'm on a modem here and it isn't likely to happen
unless there are others willing to use the format for their releases (i.e.
include a map file and some reasonably smart setup scripts).
DM> That way I can take what packages I want from wherever I
DM> want and hook them together to make the <Dave> installation
Exactly. It shouldn't be a case of having a particular distribution. Just a
case of having a collection of packages that you can put together and pull
apart like lego(tm).
OK - What do we do to make it happen? Seems to me that your
distribution *has* to end up on the net if it's going to go anywhere.
Does anyone have any objections to this kind of standardisation - if
so, why? Surely, it's in everyone interests to have systems which are
consistant and upgradable. Apart from anything else, I *want* to pick
and choose what ends up on my box...
Stephen White
: My point to you is that we shouldn't be relying on a small group of people,
: who do a fantastic job, to be producing packages. The people who write/port
: packages should take the time to make what's necessary to support a
: *standard* installation utility.
That seems to be the general motivation behind the Debian package. However,
packages are so diverse that no general strategy will cover all situations.
The general trend of the Debian mailing list is that each package prepared
for Debian will have to manage some of its own installation. We're just
working out the specifics.
As for the people who say that Debian is useless... I feel this is a little
unfair, since Debian hasn't been released yet.
lilo (SpRiNg 94 GpA 3.64)
> We've got at least four different package conventions (SLS, Slackware,
> Debian and Yggdrasil). Why? No good reason I can see. FTP sites
> carry these different distributions, most of which differ only slightly.
Russell,
What we have is four separate, non-overlapping support systems. That's
GOOD. Without any disrespect, the Debian release could go belly-up at any
time after it is released. Peter MacDonald was pulled away from SLS for an
extremely long time and has only recently come back into the fray, with a
release that some would say lacks stability (for the moment!).
Having separate distributions is a good thing. It provides a safety net.
> I feel that there is need, and room, for two Linux distributions, one
> conservative, and the other radical. The conservative distribution is
> probably the harder, and potentially more money-making, distribution
> to do. It is marketed at Linux "users". People who don't want to
> have to fiddle. People who are willing to pay for the software to
> "just work". So the conservative distribution has its work (and
> profit) cut out for it.
Why try and nail Linux distributions down and connect them all together? It
will only ossify them and give us less variety and safety.
> And there's plenty of money to be made on the radical distribution,
> because it's obvious that some people out there want the latest and
> greatest, and they're willing to pay for it. "Who has the latest CD"
> is the subject of a recent Usenet message.
> And multiple distributions are not good, because they tend to fragment
> the market. The Linux market is small enough as it is -- we don't
> need to make it smaller! If I'm running Slackware, I don't feel like
> I can purchase SLS's support package. Or if I've bought Yggdrasil's
> CD-ROM, can I install an slackware package? And not break everything?
No, you can't. But you can always reinstall. Which I've had to do going
from MCC to SLS to MCC to Slackware, etc. Nonetheless, I've always gone
with what *I* considered to be the most current, most useful distribution.
And everyone has the right to make the same choices.
> And Adam's not doing himself any favors by not creating an FTPable
> Yggdrasil distribution. In the free software market, you create
> business by giving away your software to create a need for your
> services. The less you give away your software, the less your
> services are needed.
If it's a free market, he's free to market (and define) his product in
whatever way he sees fit. If one Linux distribution takes the market by
storm, it can only help the distribution of the others, if they are
considered quality work.... Variety means something for everyone. ;)
> And Debian, while it has the support and name of the FSF, is just
> plain not needed. Much, much better to fix the problems with
> Slackware, SLS, or Yggdrasil.
Not so! Each and every one of these distribution has pioneered slightly
different approaches and features. If the various authors get requests for
features of other distributions, they'll incorporate them.
> We should start with a merger between SLS and Slackware. Send your
> requests for same to Peter and Patrick, imploring them to cooperate
> for the betterment of all. Yes, they've had words, but they should
> still be able to work together.
They shouldn't merge the releases! We need the redundancy much more than we
need some sort of "standardization" in this area.
> So who am I to be giving out all this free advice? Why, just someone
> who's been supporting himself for 2.5 years by selling support for
> free software.
That's good, and we all appreciate your efforts. But let's not ossify the
distribution of Linux! :)
lilo
Rob Janssen
>As for the people who say that Debian is useless... I feel this is a little
>unfair, since Debian hasn't been released yet.
Could *that* just be the reason it is being called useless?
Rob
--
-------------------------------------------------------------------------
| Rob Janssen | AMPRnet: r...@pe1chl.ampr.org |
| e-mail: pe1...@rabo.nl | AX.25 BBS: PE1CHL@PI8UTR.#UTR.NLD.EU |
-------------------------------------------------------------------------
Paul Etzell
I have been following this thread with interest and I share some of the
same impressions that Mike has.
When our group began using Linux in a commercial environment almost two years
ago my first reaction was that some method of standardized package
maintenance was essential. We were in the process of building a network
to support our Cancer Center and maintaining anything more than a couple
of machines using ad-hoc methodologies was going to be doomed to failure.
Coming from a minimalist mindset our design strategy was to have something
that was capable of installing packages, documenting packages, removing
packages, verifying packages and of course generating packages. We
weren't interested in fancy menus, full-screen interfaces and the like, we
were primarily concerned with reliability and a utility that required a
minimum toolset to function with. Also fundamental to the design was a
system of hooks which could be used to provide customization of both the
installation and removal process.
The outcome of the design and coding process was a utility which we called
StopAlop (Stop A Lot of Problems, Stop Alopecia [oncology joke]). This
utility has functioned extremely well for us and has greatly simplified
the installation and maintenance of our Linux workstations.
It was apparent to me at the time that StopAlop was developed that the
Linux community at large would benefit from a standardized method of
package generation/installation/removal. To this end I announced the
package and stuck it on both sunsite and tsx-11. I also sent mail to the
Linux developers with the request that they evaluate the utility and
consider a standardized methodology of packaging.
Like Mike's experience our efforts were met with somewhat resounding
silence. Mr. McDonald responded by sending me a design brief on his
packaging tool. Others commented that they wanted something like the
SysV pkgtool and said that they were starting work on something, most
with the intention of adding some type of curses interface... :-)
Two years later we are in the midst of another round of discussions on how
to package stuff up for Linux. I am all for free-market competition and I
firmly believe that this competitive pressure has produced and will
continue to produce products that meet or exceed the quality of offerings
from the commercial marketplace. It is my opinion that a standardized
tool would not impede this environment.
I suspect that the move towards 'proprietary' installation/packaging
techniques may be driven somewhat by the desire of the package
maintainers to distinguish their products in the marketplace. I believe
that the goal of a standardized packaging technique and 'proprietary'
installation methodologies are not mutually exclusive.
I could really give a rip whether StopAlop ever gets consideration for
this type of role. I simply use it as an illustration of how the two
goals mentioned above are compatible. StopAlop provides both pre and
post-installation hooks which are automatically incorporated into the
installation script when the package is generated. A pre-removal hook is
also provided. StopAlop could care less what the user decides to put into
these hooks, it is simply very diligent about making sure that they get
included into the package and get called at the appropriate time.
Using this type of methodology the developer is free to include whatever
customization he/she wishes, StopAlop simply provides a consistent
framework for installation, removal, verification and documentation. In
modern management parlance this is of course a win-win situation. The
developers can provide fancy installation scripts, menus and windows to
their hearts content and the end-user has some assurance that packages
obtained from different sources etc have some hope of mutual coexistence.
Looking onto the horizon there are probably future benefits from a
standardized packaging methodology. Considering the almost exponential
growth in interest in Linux there is probably the potential for another
group of developers what I somewhat euphemistically refer to as the
'after-market' developers.
Warner Losh is probably an example of this type of developer. An entity
or group which has a utility or program set which is aimed at an
application market that has already made a decision on a 'base' release of
Linux. A standardized method of packaging would insure that their
application would fit on top of and be compatible with whatever flavor
'base' was installed on a particular machine. An assurance of
compatibility and standardization would IMHO offer an image of maturity to
the application developers whose efforts are essential to the widespread
acceptance of Linux as an alternative to commercialized operating
environments.
As I mentioned previously I am not out to stump StopAlop as this
universal solution. Anyone who develops software of course will tell you
that they never mind seeing something succeed and be successful... :-)
In fact the version of StopAlop on the archive sites is probably a couple
of versions behind because our group didn't feel that their was
sufficient interest in the Linux community for this type of utility. If
anyone is interested in experimenting please feel free to drop me a
note. It would not require much effort to post our current release.
Note that followups via mail should be addressed to the address in my
.sig. My new newsreading account is still in the works.
My thanks as always to everyone who strives to make Linux the superior
product that it is proving itself to be.
> Mike
>
As always,
Dr. G.W. Wettstein
Oncology Research Division Computing Facility
Roger Maris Cancer Center
820 4th St.
Fargo, ND 58122
e-mail: wind!gr...@plains.nodak.edu
David Marples
In article <2s3a9r$i...@sbi.sbi.com> b...@std.sbi.com (Bennett Todd) writes:
{Snippage}
- builtin checksums, and ability to verify a package or an
installation, and to do an incremental update efficiently, only
copying in the files that have actually changed
- central database keeping an inventory of which packages have
been installed
- ability to remove packages
- ability to specify arbitrary scripts to be run before and/or after
installation and/or removal (all four permutations), and the
ability of these scripts to compute new files to be installed as
part of the current package
I agree with all of these requirements, particulally the ones about
ability to remove packages and the database.
I expect that inside of 10 years we'll see widespread standardization on one
or more relatively general-purpose packaging standards. I doubt it'll happen
in 5; it takes people longer than that to learn why it's needed.
I think this is the problem. There are only a few people who are
*using* their Linux boxes in situations where they cannot be
re-installed if required. THIS ISN'T FLAME BAIT. Yes, I know that
there ARE people who are doing real jobs, but for the most part people
who are using Linux are committed to the "cause". They're quite
prepared to take the hit of a re-installation - How long does it take?
Perhaps an evening, perhaps two. That equates to one to two work
days. I guess I should clarify using to mean administering before
lots of people start saying things like 'well, I've got 75 users and
they're all dead happy'. I personally prefer to live with out of date
packages unless I need the new functionality just because I need
something that isn't a moving base in order to do my job.
I honestly believe that if Linux is going to do well outside of the
environment where people are prepared to put the work in (i.e. if it
is going to be liked by overworked sysadmins) then these are the sort
of tools that will be needed. Of course, there is no point in having
the tools if people aren't going to use them - an earlier poster on
this thread said that they'd produced a set of tools because of
exactly these problems, released it to the net and then had very
little feedback.
I hope someone is archiving this - I'd like to be able to come back in
three years and say "I told you so...."
Bennett Todd
emerged (aside from the trivial ``tar file to extract from root, compressed
with gzip''). When someone new looks at the problem, if they check out the
work that has been done by others they see two kinds of packaging proposals.
Some are simple --- and fail to address the precise problem they have in
mind. Others address their precise problem, plus everybody else's --- and
are horribly complex (as a consequence!).
I started off despising the System V packaging tools, because they were so
grotesquely complex. Over time I've seen use for more and more of their
features; I now appreciate why they have so many features. I still despise
them, because they were designed and implemented by bozos who knew nothing
about Unix, and it shows. But I have come around to believing that any
viable universal solution will need to have many of the features of the
System V packaging tools, including:
- builtin checksums, and ability to verify a package or an
installation, and to do an incremental update efficiently, only
copying in the files that have actually changed
- central database keeping an inventory of which packages have
been installed
- ability to remove packages
- ability to specify arbitrary scripts to be run before and/or after
installation and/or removal (all four permutations), and the
ability of these scripts to compute new files to be installed as
part of the current package
Anything that implements a sufficiently rich set of features will be more
complex than something that doesn't, and so it will only be appreciated by
people who've been fighting this war for a while.
I expect that inside of 10 years we'll see widespread standardization on one
or more relatively general-purpose packaging standards. I doubt it'll happen
in 5; it takes people longer than that to learn why it's needed.
-Bennett
b...@sbi.com