5 ms·

Ubuntu's best on servers IMHO. Can't beat PPAs for installing stuff. It's just the easiest.

krutzger 9y ago
Snaps are even better, but probably not worth the extra memory usage on servers
dozzie 9y ago
I concur, it's very hard to beat the diversity of package retention policies of all the different PPAs. There's no other solution among the package managers that allows you to get your system to the state that you can't replicate on some other server because the versions went missing.
stephenr 9y ago
Well, you can. "PPAs" are just ubuntu-hosted Apt repos. I've yet to find a server-focussed package that is both not sufficiently up-to-date in the main or back ports repos and there isn't a vendor repo for it. Sure, adding a 1 line text file in `/etc/apt/sources.list.d` and a gpg keyring to `/etc/apt/trusted.gpg.d` is probably slightly more work than running `apt-add-repository`, but if that's what defines how you pick a server distro, I'd like to very much never work with you please.
- pbhjpbhj 9y ago
  PPAs make me very nervous. They're often on Launchpad (which appears to offer credibility) but AFAIK there are no checks on them, they're private repos the owner has given access to. Sure there are some, like inkscape-dev that I've can trust without too much issue. AIUI installed packages get to run scripts with superuser privileges. This to me says "Danger Will Robinson!".
  - stephenr 9y ago
    This is kind of my view. Some are definitely operated by smart people e.g. Ondřej Surý offers his PHP packages for Ubuntu via a PPA (and via a regular apt repo for Debian). As for the packages: they're literally just regular .deb packages, which means they're installed as root, which means yes they could do anything. Of course you can also examine/extract them just like with a regular repo, but it's definitely an issue of trust for most people. I trust that e.g the Varnish project, or Percona or the aforementioned Ondřej Surý are not putting shifty shit in their packages. I can't trust JimmyB on Launchpad the same way.
  - JdeBP 9y ago
    Since the headline here is Debian 9, it is worth nothing that changes in Debian 9 address a small part of this overall problem. One can nowadays at least not give one repository owner the power to sign impostors of every repository that one has configured, by associating a public key directly with an individual repository rather than placing it into a global keyring. * http://jdebp.eu./Softwares/package-repositories.html#Debian http://jdebp.eu./Softwares/package-repositories.html#Debian The rest of the problem still exists, though. Only one package manager that I know of even tries to address it, by having pre/post-install/upgrade/remove actions use a specialist declarative language for things like making directories and dedicated user accounts. But even that has a loophole that allows arbitrary scripts to be executed from within that language. * https://freebsd.org/cgi/man.cgi?query=pkg-create#PLIST_FORMAT https://freebsd.org/cgi/man.cgi?query=pkg-create#PLIST_FORMA... * http://man.openbsd.org/pkg_create#PACKING-LIST_DETAILS http://man.openbsd.org/pkg_create#PACKING-LIST_DETAILS The loophole exists because the provided language simply isn't sufficient for everyday needs. It's quite hard to come up with one that is, whilst not being as worrysome as general-purpose shell script, too.

Snaps are even better, but probably not worth the extra memory usage on servers

I concur, it's very hard to beat the diversity of package retention policies of all the different PPAs. There's no other solution among the package managers that allows you to get your system to the state that you can't replicate on some other server because the versions went missing.

stephenr 9y ago

Well, you can. "PPAs" are just ubuntu-hosted Apt repos. I've yet to find a server-focussed package that is both not sufficiently up-to-date in the main or back ports repos and there isn't a vendor repo for it. Sure, adding a 1 line text file in `/etc/apt/sources.list.d` and a gpg keyring to `/etc/apt/trusted.gpg.d` is probably slightly more work than running `apt-add-repository`, but if that's what defines how you pick a server distro, I'd like to very much never work with you please.

pbhjpbhj 9y ago
PPAs make me very nervous. They're often on Launchpad (which appears to offer credibility) but AFAIK there are no checks on them, they're private repos the owner has given access to. Sure there are some, like inkscape-dev that I've can trust without too much issue. AIUI installed packages get to run scripts with superuser privileges. This to me says "Danger Will Robinson!".
- stephenr 9y ago
  This is kind of my view. Some are definitely operated by smart people e.g. Ondřej Surý offers his PHP packages for Ubuntu via a PPA (and via a regular apt repo for Debian). As for the packages: they're literally just regular .deb packages, which means they're installed as root, which means yes they could do anything. Of course you can also examine/extract them just like with a regular repo, but it's definitely an issue of trust for most people. I trust that e.g the Varnish project, or Percona or the aforementioned Ondřej Surý are not putting shifty shit in their packages. I can't trust JimmyB on Launchpad the same way.
- JdeBP 9y ago
  Since the headline here is Debian 9, it is worth nothing that changes in Debian 9 address a small part of this overall problem. One can nowadays at least not give one repository owner the power to sign impostors of every repository that one has configured, by associating a public key directly with an individual repository rather than placing it into a global keyring. * http://jdebp.eu./Softwares/package-repositories.html#Debian http://jdebp.eu./Softwares/package-repositories.html#Debian The rest of the problem still exists, though. Only one package manager that I know of even tries to address it, by having pre/post-install/upgrade/remove actions use a specialist declarative language for things like making directories and dedicated user accounts. But even that has a loophole that allows arbitrary scripts to be executed from within that language. * https://freebsd.org/cgi/man.cgi?query=pkg-create#PLIST_FORMAT https://freebsd.org/cgi/man.cgi?query=pkg-create#PLIST_FORMA... * http://man.openbsd.org/pkg_create#PACKING-LIST_DETAILS http://man.openbsd.org/pkg_create#PACKING-LIST_DETAILS The loophole exists because the provided language simply isn't sufficient for everyday needs. It's quite hard to come up with one that is, whilst not being as worrysome as general-purpose shell script, too.