Stephanie Daugherty <sdaugherty@???> wrote:

> They did, but out of all this design by committee, hidden between all the political bullshit and bikeshedding, they also created the most brilliant, most comprehensive set of standards for quality control, package uniformity, license auditing, and of course. the most robust dependency management, at least among binary distributions.
>
> More importantly than that, they backed these standards up with automated tools that are nearly as robust as the standards themselves. You don't see packages interfering with one another very often in the Debian world, because this is caught right away by scripts that check that every file installed by a package, or automatically created by that package belongs to EXACTLY ONE package, otherwise all the packages have to use some approved mechanism to cooperate. You also see this effort it in difficult to configure packages that set themselves up and work out of the box, and in the modularized configuration that's common to many packages.
>
> Most importantly, this rigid attention to detail is why for more than a decade now, in place upgrades have been fully supported, officially recommended and for the most part, Just Work(tm(. It used to be said, back in the day that the installer was still horrible, "thank god you only ever have to see it once"

That's how I see it too - I've been using Debian by choice for a lot of years - in fact, the only systems I run that aren't debian are where I've used a "packaged" setup, specifically I have a couple of PBX "appliances" which only support (at the time they were built) being setup on Centos.



On 15 Aug 2015, at 21:33, Laurent Bercot <ska-devel@???> wrote:

> And their package management features:
>
> - no way to have several versions of the same package installed on
> your machine
> - no atomic upgrades for single binary packages: if you have stuff
> running during an upgrade, things can break.
> - no possibility to rollback.

The rollback is a bit of a pain. In spite of the quality control, I have had one or two issues in the past where an upgrade has broken a combination of stuff - as in X runs on language Y and uses Z for some of it's functions, but after an upgrade it "doesn't work" and then have to start manually installing older versions of X, Y, and Z to figure out which combination work.

> I'm sure there's a lot of good to say about the way Debian does
> things, but quality of their package management isn't a part of it.
> When you're running production servers and need reliability when
> upgrading software, you just can't use Debian.

I've found it pretty reliable - certainly not as bad as certain commercial ecosystems I have dealings with.
My expectations of "problems" during upgrades is less with my Debian systems than it is with anything else. That's not to say I've not had problems.


Hendrik Boom <hendrik@???> wrote:

> THe way I heard the story, in the ncient days when Apple was choosing
> the kernel for OS X, they were originally planning to use Linux, but
> they changed their mind for copyright reasons. THey didn't want to risk
> any of their proprietary software becoming free software because of
> GPL contagion.
>
> The BSD licence allowed them to do what they wanted.

You do realise that they do in fact use a lot of GPL software don't you ? In fact they have contributed some very useful software back into the community under GPL.
I'm more inclined to think they just decided the BSD kernel was more suitable to their needs.