Re: Paketvarianten (gentoo alike)
Am Sonntag, 18. Dezember 2011 schrieb Enrico Weigelt:
> * Martin Steigerwald <Martin@lichtvoll.de> schrieb:
> > Hast Du ein *konkretes* Beispiel?
>
> readline:
> * multibyte/wchar support
> * curses vs. termcap based
Okay, eine Auflistung von Optionen.
Wozu brauchst Du das? Was ist der *konkrete* Vorteil? Was ist der konkrete
Anwendungszweck? Klar, kann ich mir auch meinen eigenen Kernel
kompilieren. Und ich habs lange Zeit auch gemacht wegen TuxOnIce. Aber das
bot mir zeitweilig konkret wahrnehmbare Vorteile wie schnelleres
Einschlafen und Aufwachen sowie höhere Zuverlässigkeit. Und nach den
Werten, die ich für eine Intel SSD 320 von Milan Oravec in der tuxonice-
Mailingliste jetzt las wie
I/O speed: Write 481 MB/s, Read 658 MB/s.
ist der Geschwindigkeitsvorteil selbst gegenüber 3.2-rc4 mit
Multithreading bei der Kernel-Implementation immer noch gegeben¹. Ich
bekomme schreibend nämlich nur 370-400 MB/s, lesend hab ich bislang noch
nicht mitbekommen. Und ja, das macht bei 8 GB RAM von denen vielleicht 3-4
GB gespeichert werden, einen Unterschied.
Das ist was Spürbares. Ein wahrnehmbarer Vorteil. Anstelle eines
Kompilierens als Selbstzweck. Auch okay. Aber das mache ich nur, wenn ich
wirklich Rumspielen möchte.
[1] http://lists.tuxonice.net/pipermail/tuxonice-devel/2011-
December/007114.html
> glib2:
> * multithread-support
> * gc-friendly
> * mem-pools
> * debugging
> * fam support
> * selinux support
> * xattr
> * regex
>
> usw, usw.
Ditto. Eine Liste von Optionen. Doch wozu?
Habe ich alles noch nicht konfigurierbar gebraucht.
Ob nun selinux / xattr support und Ähnliches mit drin ist, scheint selbst
meinen ASUS DSL-Router nicht sonderlich zu interessieren.
Meines Wissens lädt der Linux Kernel ohnehin nur die benutzten Teile eines
Binaries komplett in den Speicher (on demand paging). Und der 2 GB USB-
Stick reicht so oder so locker aus.
Das einzige was sich sparen ließen ist das dynamische Linken an für die
Aufgabenstellung nicht benötigte Pakete. Das wäre evtl. ein Argument. Aber
ob das bei Konsolen-Programmen mit wenigen Abhängigkeiten wirklich eine
große Rolle spielt… Für KDE linkt sich "kdeinit" ja einmal gegen die
Standard-Bibliotheken, um das dann weiterzuvererben.
Und eventuell ein paar Abfragen aka if(selinux) then …
Aber deshalb ja: Wozu? Was ist der konkret spürbare, wahrnehmbare und im
Praxisalltag *relevante* Vorteil?
Ich will dich / euch nicht dran hindern, zu tun, was euch Spaß macht. Und
wenn Debian dadurch neue Funktionen und Möglichkeiten bekommt, ohne sich
dadurch gravierende Nachteile einzuhandeln, warum nicht? Doch ich begreife
schlicht und ergreifend den Zweck dahinter nicht.
Die oben genannten Optionen sind doch kein Selbstzweck, oder etwa doch?
"Ich hab mir mein Superschlau-Tool mit der dupersuper-mäßigen Foobar-
Option kompiliert, kewl eh?"
Oder gibt es im Embedded-Umfeld konkrete Anwendungsbeispiele mit konkreten
Vorteilen?
--
Martin 'Helios' Steigerwald - http://www.Lichtvoll.de
GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7
Reply to: