Re: why debian - longer
hi ya tim
yup.. i agree most everything .. including the differences
On Sat, 13 Nov 2004, Tim Kelley wrote:
> On Friday 12 November 2004 22:24, Alvin Oga wrote:
>
> > people can and will jump ship for any number of reasons ...
>
> Strength in numbers, etc. If enough debian developers "jumped ship" as you
> say, there would have to be a damn good reason to do so.
$$$$
> Home users, yes. In any organization, however, stability is prized above all
> else.
thats true for just about everybody .. including home users
maybe techie users might be more tolerant of bugs and "oops"
> Most organizations prefer a a 24 month release cycle at best.
some longer... some shorter cycle
- just depends on what the app is that they are trying to do
24 mon release cycle for webservers will be a disaster
if one happens to be using the buggy versions
24 mon release cycle for X11 + kde or x11 +gnome will be
disasterous ( since mose everybody expects to get to see
webpages and send/receive emails )
- other X11 things being buggy can go un-noticed
equally well
> Debian provides a stable target that will not change; that's rather a big
> deal, Red Hat and SuSE cannot say the same (9.0 vs 9.1 vs 9.2, etc). Windows
i do not see the "any version" differences ...
timeline is meant for those versions that started
at roughly the same time period ..
frequency of changes or upgrades or new version name is good and
bad ...
redhat: fedora rh-9 rh-8 rh-7 ...
suse: 10.x 9.x 8.x 7.x ...
debian: sid .. sarge woody potato ...
slack: 11.x 9.x 8.x 7.x ...
whatever versions that corresponds to each other's distro
or skip a generation/version release
> It is a tremendous issue. Who wants to maintain a local source tree of
> hundreds of programs? Nobody who has done it I warrant. The enormity of
one has to be insane to maintain a local source tree of everything
or one has to be (more likely) sane to maintain a local mirror ..
either way can be viewed good or bad ... nothing to do with number of CDs
> debian gives instant access to all manner of very useful programs that simply
> don't make it into mainstream distros. This is very important to an admin,
> at least to me.
you always have most 99%(?) all packages in *.deb, *.tgz or *.rpm
> > people just want the minimum stuff ...
> > - a webserver ...
> > - a dns server ...
> > - a firewall ..
> > - a mail server...
> > - users workstation ( kde/gnome ) ..
>
> Not once they've had a taste of all the useful programs that are out there.
i doubt if anybody has ... too many packages and apps and new ones
everyday leaving aside new versions with bug fixes of existing ones
> For instance, debian has a type of dependency named "provides".
other claim to have solved the dependency issue too ..
- but i always find a way that it doesn't work in this case or that
> Therefore,
> debian can ship all manner of webservers which "provide" "httpd". thus
> programs which need a web server to operate, don't depend on "apache", they
> depend on "httpd" which is provided by some dozen packages. This sort of
> thinking underlies debian's infrastructure.
lots of equivalent packages .. also available in all other distro
- some more heavily support in one distro than another
- most commercial entities will probably go w/ apache
and tomcat or zope .. etc ..
- exim/postfix/sendmail/qmail/... endless wars..
- bind/djbdns/... endless wars...
- which browser... endless wars...
- which window manager ... endless wars ...
> > apt-get is NOT the answer to all the user's problems
>
> Users are not the issue here, admins are, or more properly, people who tend to
> others systems.
admins are users too though a different bunch of users ...
newbie admins vs windoze admin vs old-time unix admins vs new linux admins
all want different requirements or just different enuff
> Yet they don't. If I suspect my "find" command's been hacked, I can compare
> what's on the filesystem to what is in the debian package. Not so with any
> other distro; at least not so easily.
sure you can .. just as trivially ... but yes, you there is one more step
that non-debian-ites do need to do to make it equally trivial and
reliable ( making a bootable cd with all the md5sums which can apply to
debian too to have exactly the same degree of security and confidence vs
doing an online check which is subject to "suspect" )
> > everybody has their own variation of the same functions though
> > some are more cumbersome to use ...
>
> Much more cumbersome. they are in fact *bolt ons* to an inferior
> infrastructure, whereas in debian apt-get is the *result* of a well
> engineered infrastructure.
yup, there is some differences in infrastructure between the distro ...
basic infastructure is the same ..
- mirrors for original packages and cd
- (automatica or manual) way to download patches
- self checking of the install packages
- a different app to install depending on the distro
- a different app to maintain the machine once installed ..
...
> > > 3. apt-cache - search / browse available packages
> >
> > searching can be ez or hard .. depending on if you know what it's called
> > - same problem with all distro
>
> This solves a problem. What else do you want?
if you know what the pkg or binary is called... yup its solved..
but its a major headache if you dont know what its called
and want something that does foo and looks like bar version of the other
*ix stuff
> > > 4. equivs - bypass the packaging system while satisfying it
> >
> > danger danger will robinson :-)
>
> Debian does not presume to know what's best, so if you want to compile your
> own MTA, you can, and you can give it the "provides mail-transfer-agent"
> dependency, without compromising the system at all.
that's true for any and all distro .. you can always compile stuff
yourself
the problem is does the distro understand to NOT use its newer
version to replace the manually installed ones and mroe importantly,
tested and released to their customers
- too many opps with overlapping versions where the
pkg managers get confused ..
> You are confusing home user targeted distro with admin targeted distro - two
> separate worlds.
yup.. many different sets of users and requirements
- one way is not always better than the other for all users
or the pointy haired important folks that cut the checks
> > > 8. wonderful docs; for example, all package changes are listed
> > > in /usr/share/doc/package/changelog.Debian.gz, and all upstream changes
> > > in /usr/share/doc/package/changelog.gz. /usr/share/doc also contains
> > > useful examples where appropriate. you thus have a complete history of
> > > the upstream package and the changes the packager made to it, separated
> > > neatly.
> >
> > that's true of just about every distro ...
>
> No, it isn't. I cannot get a complete history of the Red Hat packagers
> modifications to the package at all.
depends on how hard one wants to look and more importantly, what would
be the point of going back 10 years of history of one app
when the app is NOT standalone, and requires other dependencies
that they all have to interact and be nice to each others apps
and if you go back far enuff ... even debian's apps came from those
same originating sources ( GPL authors/teams )
> > > 9. installs only what you tell it to (c.f. Red Hat)
> >
> > you can tell most any distro what files or what package or what "server
> > it defined for itself" that their distro installer allows you to do ..
> > most are gui based ..
>
> And they do not work. Tell Red Hat you don't want samba or cups in the
> installer and see what happens. Debian's base install is around 50MB. Red Hat
> and other rpm based are around 600MB.
depends on how you tell it ... and that applies for most package managers
including debian as i have stuff i didnt want that is loaded ...
remove it and things complain or break ... so for now,
live with those inter-dependencies .. and i dont particularly
care if theres a few rag-tag apps floating around that hasn't
been cleaned up
> Oh no. Debian gives you the ability, easily, to compile kernels for other
> types of machines, in a consistent and easily manageable way. The module
> packages are separate, and work with any kernel.
unlucky for me, i don't do any crosscompiling ... i always compile on the
target machine that will be running it
- done 20+ years of emulating/simulating this and that, and it
aint worth the extra headaches if it's not needed
> > come to think of you ... you should add the "dependency" checking
> > on your list of features ...:-)
>
> Who else does anything like this?
the point was .. everybody has a package manager .. everybody claim
to fix the dependencies .... i can say i see and can verify that
some dependencies are NOT fixed .. even in debian ..
- is it an issue ... no ... get used to it and work around it
> > add cost of ownership ...
> > - but, usually it's just the admin problem of the admin themself
>
> How 'bout we start talking about "cost of stupidity"? :) this is really an
> issue that is completely overlooked. What is the cost of having some nitwit
> run your network? Why does no one do studies on this?
problem is tooooo many of the networks (and machines) is run and managed
by "newits"
- another day for that flame war ..
- as long as they pay for their mistakes ... by signing
checks and invoices .. maybe one day they will take a 2nd look
at changing status quo
oh well ...
have fun
alvin
Reply to: