Re: why debian - longer
On Friday 12 November 2004 22:24, Alvin Oga wrote:
thanks for your response ....
> > Well, first, some very general things:
>
> just some comments ...
>
> > 1. Debian is not a commercial organization, but a protected non-profit.
> > This means they cannot be bought out.
>
> 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.
> > a. Debian provides the most stable linux environment, both as a target
> > for development and for daily work, of any linux distributor.
>
> "stable" meaning as in woody ???
> - that can be good and bad ... it's too too old for me or for
> me to show/demo to potential customers
>
> - customers usually want latest greatest widgets and features
> and they want *you/us* to fix the bugs/problems ..
> and if not, they'd stay with what they know works for the past
> few years, losing the chance for upgrades and changes
Home users, yes. In any organization, however, stability is prized above all
else. Most organizations prefer a a 24 month release cycle at best. I agree
this is painful for the home/casual user. I won't make any excuses for sarge;
at 28 months or so, it really needs to get out the door.
> > b. Debian provides mechanisms for ease of administration and management
> > like nothing else I've ever seen. Almost everything is done uniformly
> > and sensibly. This goes far, far beyond "apt-get".
>
> uniform across windoze ( 95, 98, 2k, xp, solaris, hp, sgi, linux ... )
> - not a trivial problem .. but easily manageable as long
> long as the pointy haired execs don't make random changes
>
> - apt-get won't help you in the majority of cases
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
is such a chaotic mess I won't even belabor the point. Solaris has very long
release cycles and patches that break things - i.e., they include
enhancements along with security fixes. Debian does not do this: security
only, if you like. apt-get does help, obviously software managements a big
issue here, right?
> > d. Debian is enormous; sarge will be approximately 15 cd's or 2 dvd's.
> > Almost the entire free software repository is at the users fingertips.
>
> "size" ( number of cd's ) is not an issue
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
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.
> 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.
For instance, debian has a type of dependency named "provides". 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.
> > e. Debian keeps up with security very, very, well;
>
> probably a good strong poiint ...
>
> but it will ask the user some silly questions once in a while
> ( not a good thing ... keep the user's original config )
Sometimes (rarely) this simply has to be done (I recall the sshd exploit that
was fixed by a change in the sshd_config)
> > d. security is made a easy as possible;
> there is more too it...
>
> - there is the install issue ...
> - there is the get it working for what they want
> - there is the keep it working once its up ...
> - there is the patches and new apps to install after-the-fact...
> - there is the security updates
> ...
>
> 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.
> > Let's look at some of the details and niceties the above policies and
> > attitudes have engendered:
> >
> > 1. debsums - check md5sums of files on filesystem with debian packages.
>
> good thing to have .. but all distro and files can also have the same
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.
> > 2. apt-get - easy package management (SECURITY made easy -as it *should*
> > be)
>
> 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.
> > 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?
> > 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.
> > 5. apt-listbugs - query the bug tracking system
> > 6. apt-listchanges - notification of what your updates did
>
> good for developers but users and consumers wont be pickign thru
> bug listings and fixes and status
Good for *administrators*
> > 7. separating configuration files from the files in the package (making
> > it easy to update without disrupting operation, among other things) see
> > concept of "conffile" in a debian package
>
> in my book, any upgrade or update that asks the user "answer this
> question" and sits and waits is NOT a good thing .. esp if the user
> doesn't know how to reply ...
> - seen too many of those problems from "worried users"
>
> - worst would be to overwrite the users config files
> ( i'm paranoid so i save any/all config files for each machine )
You are confusing home user targeted distro with admin targeted distro - two
separate worlds.
> > 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.
> > 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.
> > 10. wonderful way of abstracting kernel and kernel module building (also
> > apples to other packages in general)
>
> if you mean cat /proc/config.gz
> - that's true of every distro that supports 2.6 kernels
> ( inheriting existing kernel options seldom worked in 2.4 kernels)
> it's trivial to make dep ; make bzlilo ; update lilo/grub
> and straight forward ..
> - too many extra hoops for the debian way ...
> - too many kernel module problems in the debian kernel
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.
>
> > 11. politely splitting up of packages when appropriate (e.g., snort-mysql
> > vs snort-pgsql and snort-common, same for many, many others)
>
> most packages are split accordingly too .. depending on who the person
> or distro was at the time ...
> - dependency and prerequisite problems will always exists ...
>
> come to think of you ... you should add the "dependency" checking
> on your list of features ...:-)
Who else does anything like this?
> > 12. apt-build - build packages on the fly from source
>
> thats nice ... and in other distros ...
> ./configure && make && make install will do the same
apt-build grabs the build dependencies and so forth. Huge difference. This
isn't slackware. C'mon.
> except that not all packages come with configure or a sensible
> default config files
>
> > 13. auto-apt - install packages automagically when a (missing) file is
> > accessed (great for ./configure; make ; make install freaks)
>
> i have yet to see all that stuff work right ..
Works for me? It will work better on stable, when sarge goes stable. It
doesn't work perfectly with testing/unstable, since files are constantly
changing.
> > 14. reportbug - easy way to report bugs to the BTS
>
> good thing for developers... not sure how many users will file
> correct bug reports vs just the typical "my system is broken"
> which drives everybody batty
again, admins. No one else has this. It contributes directly to debians'
quality.
> > There are dozens of others, I'm getting tired. Someday perhaps I'll
> > compile a reasonably complete list of niceties :). Anyone care to add?
> >
> :-)
>
> 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?
thanks for you response ...
--
_ _ _ _ _ _ _ _ _ _ _ _ _
/ \ / \ / \ / \ / \ / \ / \ / \ / \ / \ / \ / \ / \
( t | i | m | @ | i | t | . | k | p | t | . | c | c )
\_/ \_/ \_/ \_/ \_/ \_/ \_/ \_/ \_/ \_/ \_/ \_/ \_/
GPG key fingerprint = 1DEE CD9B 4808 F608 FBBF DC21 2807 D7D3 09CA 85BF
Reply to: