>>>>> "pg" == Philip Gorwell <philip.gorwell at wosug.org> writes:
pg> Installation CD/USB without the 'desktop' packages (so NO
pg> Accessories, Configuration and Preferences, Localization
pg> (Destkop & System), Documentation, Display, Internet, Office,
pg> Games, Media, Panels and Applets, Sound and Video, Universal
pg> Access, Multimedia Libraries and others) will help, as I can
pg> add required server packages after installation.
I may be the only one, but I've no interest in this ``minimal
install'' fad and think it's a form of OCD NIH-ism. I also don't like
that the people burdened with extra work by the whimsical requirement
of ``minimal systems''---the packagers and Makefile writers and QA
testers---are not the same set of people as the ones engaging in the
fad, the sort of sysadmins who generally aren't able to make their
own packages yet.
I'm more interested in a ``consistent baseline platform,'' and I think
overdivisive packaging interferes with that (ex. by basic tools like
perl, python, C compiler, gzip, vi being missing, or by an individual
package getting split into hundreds of ``options'' like localizations,
documentation, ``modules'', and for BSD/Gentoo-like systems the worst
of all: ``USE'' flags and PKG_OPTIONS).
The biggest imagineable ``consistent baseline platform'' is already
small enough for any common purpose, even on exotic equipment like
SSD/CF/USB/DVD boot. It's not small enough for celfones, which are
beyond reach of an ordinary distribution anyway.
The ones who want minimal systems will give you a variety of
antiquitisms and canards to defend their desire, but I think they've a
secret reason for lusting for them. If you haven't got a package
installed, you don't have to pay attention to security vulnerabilities
for it. If you _have_ got it installed, and there's a vulnerability,
you have two responses:
* determine you're not using the package and not subject to the
vulnerability, and ignore the update. If you're wrong, it's your
ass. If you're right, but then some outside security consultant
staffed with imbecile script kiddies ``audits'' you and says OMGOMG
your zyztems are VULNERABLE, then it's still your ass even though
you're right and they're wrong, and common practice will deliver
your ass even if they don't manage to actually exploit the
vulerability they claim exists.
* CYA. Do the upgrade whether you're using the package or not, just
because it's installed. This means you have to schedule
maintenance, do regression testing, and be prepared to roll back.
ok yeah, these are real problems for people with drudging sysadmin
jobs. but I wonder if there's another more interesting way around
them, because the thousands of microscopic packages answer doesn't get
you out of the mess---the mess that is, basically, your job---it only
means you have to do it less often. and it has a cost.
oversplitting packages leads to:
* surprise bugs from hidden dependencies
* annoyed sysadmins noticing something's missing but not knowing how
to track down the oddly-named microscopic package that provides it
* baroque gyrations of packagers to minimize build and run
dependencies on basic packages that would have been in anyone's
``consistent baseline platform'' anyway (which is why the upstream
developer thought he could count on them and put in the dependency
the packager is trying to remove). In particular building
documentation often requires all kinds of crazy weird tools. If
not minimize dependencies, you probably at least have to _name_ the
dependency to avoid its being hidden, which is too much of a pest
already.
* slow installers and bloated metadata
At the very least, it would be smarter to always install all
localizations, like Mac OS X and Ubuntu do, instead of splitting every
package into this ungodly mess of geographies and languages and
character sets like Windows does. There are rarely security
vulnerabilities specific to the Wolof localization of ssh, so what's
the point?
Installing all localizations would expose some bugs, too---I manually
install them all on my SXCE box, and this makes sshd really slow to
accept connections because it dlopen's a hundred ``modular'' libraries
to enumerate the languages offered to the client. The dlopen behavior
in sshd only exists to split function into separate-file libraries
because of the micropackaging fad. This is dumb. For normal systems,
forget this nonsense and link them all in. For celfones, you need to
do a better job of minifying sshd than just removing Wolof, and the
knobs for doing it will all be at compile time---there will not be any
``modules.''
Wishing for scriptable install tools and text file configuation
instead of XML crappo and wallpapered smit/GNOME bullshit is a
separate discussion from whether or not you install GNOME libraries.
It's totally orthogonal.
pg> Removing packages after installation is very, very painful
pg> process, also some dependencies are difficult (eg why gnu-mc
pg> require gnome-base-libs with all the dependencies...)
which is a great reason not to muck around with removing them, just
because they exist and are called ``packages'' which makes it sound
like you can remove them.
I know there are reasonable people who don't share my view, but I hope
packaging system designers will keep in mind that both approaches have
a cost.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 304 bytes
Desc: not available
URL:
<http://mail.opensolaris.org/pipermail/advocacy-discuss/attachments/20090624/a578c5ec/attachment.bin>
