| sean finney on 18 Aug 2004 03:08:02 -0000 |
|
okay, i just have to throw in my $0.02 :) On Tue, Aug 17, 2004 at 08:49:06PM -0400, Tobias DiPasquale wrote: > IMO, Debian is a server-only distro. I suffered under a Debian > (stable!) desktop for about a year, and that was the most hacked-up, > non-standard desktop you ever saw because I couldn't get a package from > the mirror that was more recent than 1995. After a while, I sat back > and wondered "what the hell am I doing running 10-year old software on > a desktop???" That kind of stability is great for a server, but anethma > for a desktop. ...which is exactly the point of having different branches, for different needs. if you want something geologically solid, the stable branch is designed for that in mind. if you want to ride the bleeding edge (or something a bit short of that), having a testing/unstable mix can cover most of your needs. trying to make one the other is sure to lead to frustration. > >Whereas with debian, if we want our standard server to have something > >that's deviated from the main deb branch - we create our own custom > >package. That way - if/when the main branch has it we can use that > >package instead. > > I find that to be sometimes the case, and sometimes not. I've had to > make not a few custom packages for software the Debian doesn't have and > when they do come out with a package finally, it tends to not look > anything like the package that you made. Sometimes its a smooth > upgrade, but most of the time I stick with my own package. have you taken a look at "equivs"? it's great for cases where you want to have a certain piece of software installed from source, but still want it to register with your package management system (in order to meet other dependencies, for example). using equivs + stow is a great combo for those corner cases. > >It's been very easy. I never had this type of luck with RedHat or > >SuSE - unless I wanted to stick strictly to what the vendor gave me. > > To be fair, that is exactly what those distros are designed for: using > the stock distro without very much modification for many, many desktops > and servers by medium to large organizations with a staff that are > generally not Linux gurus. it also makes support much easier for them to provide, because if they limit what you can run and how you run it, the scope of what they have to provide support for is much smaller/cheaper, and thus gives them the ability to specialize and focus. for example, the anaconda installer is a top-notch gui installer, making it easy for even an mcse to install... but then afterwards you're still stuck with a redhat system to administer/re-install :) > dpkg is simpler than RPM, once you get the hang of it. However, Gentoo > ebuilds are a 20-30 line build solution that, if your software doesn't > change that much between versions, practically ensures smooth updates > for new releases (if you're familiar with BSD ports, you know the idea > behind Gentoo's Portage system). Plus, you don't really need to make as > many ebuilds, due to the good availability of software on Gentoo. As > well, they don't generally manage configuration files, which means that > once you set them up how you like them, they won't get blown away > during an upgrade because some developer forgot to put them in > debian/conffiles (WARNING: sometimes APT will overwrite your config > files even if they DO appear in debian/conffiles; APT is smart like > tractor; you've been warned). i don't see how "not managing" config files, in combination with not adhering to a strict policy of what and where constitutes a config file can guarantee the same wouldn't happen in gentoo. while there's always the possibility that a .deb maintainer script will do something Really Dumb, if it does, it's without doubt a serious bug, and the developer can't argue this when you point at the clause in the debian policy. > I've had a lot of experience with Debian and also with Gentoo and as > far as package availability goes, Gentoo kicks Debian's ass up and down > the street. More recent versions are available much more quickly than > Debian will ever have. The trick with Gentoo is making sure you hold > packages _back_ from newer, unstable versions. This is opposite of > Debian: having to make custom packages for versions or software that > Debian has and is too old, or just plain doesn't have (availability of > non-GPL software under Debian is not the greatest). what do you mean by package availability? i'd hate this to turn into a whose-is-bigger argument, but there's over 8,000 different software packages in debian stable, and twice that in the upcoming release candidate. if anything, i'd say one of debian's weaknesses is the overabundance of availability, because if you're not familiar with the software in question you have to spend the time researching and picking out the right one. who else will give you the choice between 19 different web servers, 13 different mail servers, 18 ftp servers... as far as up-to-datedness goes, i'll again state that is not the goal of debian stable... testing/unstable very much matches the ethos of the gentoo "hold back" approach, and provides what i would guess to be a very similar collection of software versions. sean Attachment:
signature.asc
|
|