4 ms·

A bit of a tangent but: take another look at FreeBSD folks. If we re-did our infrastructure from scratch we'd look at either FreeBSD or Alpine Linux. Both woul

by api 8y ago

A bit of a tangent but: take another look at FreeBSD folks. If we re-did our infrastructure from scratch we'd look at either FreeBSD or Alpine Linux. Both would offer an escape hatch from the needless bloat that mainstream Linux has become.

hpcjoe 8y ago
Dependency radii of packages in CentOS are horrible. Your minimal installs are hovering above 1GB. Debian are better at 400MB or so. Alpine is great, in that you can get this down to well under 100MB. This has been a long standing complaint of mine[1], and an argument I've had with many proponents of "software must come packaged only from the provider of the distro" people. Physical and logical footprint is a real thing. Ridiculous secondary/tertiary dependencies are a waste of that precious resource, and an unneeded/unwanted installation of useless bits. [1] http://scalability.org/2018/04/distribution-package-dependency-radii-or-why-distros-may-be-doomed/ http://scalability.org/2018/04/distribution-package-dependen...
- mmt 8y ago
  Although I agree with you that this bloat is undesirable, I'm not convinced it's actually a problem with the distro. (My primary experience is with Ubuntu, and to a lesser extent, mostly by extension, Debian) Rather, I think it's a problem with the package maintainers themselves. I certainly admit that for very many packages, this is a distinction without a difference. However, my point is that this dependency bloat isn't based on some kind of policy that the distro is encouraging or even enforcing. Rather, the problem is merely that too many source packages create too few targets, perhaps because the original packagers never foresaw the need (for, e.g., both an X version of some graphics or GPU-related library and a non-X one for pure server work). I've occasionally gotten around this problem by custom-building a local version of the package that avoids the dependency bloat. That violates the "software must come packaged only from the provider of the distro", unless one considers the local superset a forked distro. > Physical and logical footprint is a real thing. Ultimately, I think you and I are in a vanishingly small minority here. Virtualization (even the full, pre-container kind, with a full copy of the kernel on every instance) gained a startling level of a popularity, and was even lionized as a money-saving tool (which, of course, it was, for some "IT" shops).

by api 8y ago

hpcjoe 8y ago

Dependency radii of packages in CentOS are horrible. Your minimal installs are hovering above 1GB. Debian are better at 400MB or so. Alpine is great, in that you can get this down to well under 100MB. This has been a long standing complaint of mine[1], and an argument I've had with many proponents of "software must come packaged only from the provider of the distro" people. Physical and logical footprint is a real thing. Ridiculous secondary/tertiary dependencies are a waste of that precious resource, and an unneeded/unwanted installation of useless bits. [1] http://scalability.org/2018/04/distribution-package-dependency-radii-or-why-distros-may-be-doomed/ http://scalability.org/2018/04/distribution-package-dependen...

mmt 8y ago
Although I agree with you that this bloat is undesirable, I'm not convinced it's actually a problem with the distro. (My primary experience is with Ubuntu, and to a lesser extent, mostly by extension, Debian) Rather, I think it's a problem with the package maintainers themselves. I certainly admit that for very many packages, this is a distinction without a difference. However, my point is that this dependency bloat isn't based on some kind of policy that the distro is encouraging or even enforcing. Rather, the problem is merely that too many source packages create too few targets, perhaps because the original packagers never foresaw the need (for, e.g., both an X version of some graphics or GPU-related library and a non-X one for pure server work). I've occasionally gotten around this problem by custom-building a local version of the package that avoids the dependency bloat. That violates the "software must come packaged only from the provider of the distro", unless one considers the local superset a forked distro. > Physical and logical footprint is a real thing. Ultimately, I think you and I are in a vanishingly small minority here. Virtualization (even the full, pre-container kind, with a full copy of the kernel on every instance) gained a startling level of a popularity, and was even lionized as a money-saving tool (which, of course, it was, for some "IT" shops).