Slackware lebt von PV, bei Slackware mitmachen is nicht, da gibts PV dann lang nix, dann eine handvoll andere die regelmäßig builds liefern und das is es. Keine öffentlichen Diskussion, keine 'mitmache' Möglichkeit, nix. KLar wennst an bug findest un a Lösung vorschlägst kommst mal aufs changelog, du kannst schaun wie viele das sind. freilich steht es dir frei auf LQ Vorschläge zu machen, da wirst dann sicher nieder gebrüllt weil Änderungen in Slackware geht gar nicht, da gibts die selbsternannten Wächter die mal alles ablehnen was nicht von ihnen selbst kommt, und beleidigt werden wen ihre Vorschläge dann genauso nieder gebügelt werden und das wars dann aber auch.
Slackware ist für Leute, die es schlicht und einfach mögen, so dass sie selbst gut dran basteln können. Und die geringe Personenzahl ist der Garant dafür, dass es so bleibt, denn die paar Leute wollen sich schon aus Selbstschutz nicht "just for Fun" das Leben schwer machen.
Was passiert, wenn jeder mitmacht, sieht man an KDE. Das ist mittlerweile in 3 Subprojekte zerfallen, die Mühe haben, miteinander zu reden, und die Distributionen "dürfen" sich ein funktionierendes Gesamtpaket selbst zusammensuchen.
Das ist IMO dann ein Nachteil, wenn sich P.V. neue Sicherheitslücken anschaut, dann überprüft, ob Slackware betroffen ist, danach entscheidet, dass es keine Updates geben wird und niemandem mitteilt, warum Sicherheitsupdates nun ausgeblieben sind.
Das folgende Glibc-Update zeigt stellvertretend, um was es dabei geht: http://www.slackware.com/security/viewer.php?l=slackware-security&y=2016&m=slackware-security.569827 [slackware-security] glibc (SSA:2016-054-02)
New glibc packages are available for Slackware 14.1 and -current to fix security issues.
Here are the details from the Slackware 14.1 ChangeLog: +--------------------------+ patches/packages/glibc-2.17-i486-11_slack14.1.txz: Rebuilt. This update provides a patch to fix the stack-based buffer overflow in libresolv that could allow specially crafted DNS responses to seize control of execution flow in the DNS client (CVE-2015-7547). However, due to a patch applied to Slackware's glibc back in 2009 (don't use the gethostbyname4() lookup method as it was causing some cheap routers to misbehave), we were not vulnerable to that issue. Nevertheless it seems prudent to patch the overflows anyway even if we're not currently using the code in question. Thanks to mancha for the backported patch. For more information, see: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-7547 (* Security fix *) patches/packages/glibc-i18n-2.17-i486-11_slack14.1.txz: Rebuilt. patches/packages/glibc-profile-2.17-i486-11_slack14.1.txz: Rebuilt. patches/packages/glibc-solibs-2.17-i486-11_slack14.1.txz: Rebuilt.
Die Kernsätze sind dabei: "However, due to a patch applied to Slackware's glibc back in 2009 (don't use the gethostbyname4() lookup method as it was causing some cheap routers to misbehave), we were not vulnerable to that issue. Nevertheless it seems prudent to patch the overflows anyway even if we're not currently using the code in question."
Man sieht nun aber auch, dass die Slackware-Glibcen vor 14.1 nicht entsprechend gepatcht wurden.
So, jetzt stellt Euch einmal vor, P.V. hätte auch diesen Glibc-Patch für Slackware 14.1 unterlassen und ansonsten kein Wort mehr zu dieser Lücke gesagt.
Genau diese Art von Kommunikationskultur ist IMO eines der Hauptprobleme von Slackware.
Zudem ist auch ersichtlich, dass Slackware nicht grundsätzlich und durchgehend Sicherheitslücken bzw. sog. "Overflows" in allen angeblich noch unterstützten Distributionsversionen patcht, ganz im Gegensatz zu Firmen wie Red Hat oder Suse.
Ich bezweifle zudem, dass auch erfahrene Slackware-Admins jede aufgelaufenen Sicherheitslücke tracken und finden können, um diese dann gegebenenfalls selbst zu patchen. Würde man das selbst tun müssen, bräuchte man wohl einen 36-Stunden-Tag.
Slackware lebt von PV, bei Slackware mitmachen is nicht, da gibts PV dann lang nix, dann eine handvoll andere die regelmäßig builds liefern und das is es.
Keine öffentlichen Diskussion, keine 'mitmache' Möglichkeit, nix.
KLar wennst an bug findest un a Lösung vorschlägst kommst mal aufs changelog, du kannst schaun wie viele das sind.
freilich steht es dir frei auf LQ Vorschläge zu machen, da wirst dann sicher nieder gebrüllt weil Änderungen in Slackware geht gar nicht, da gibts die selbsternannten Wächter die mal alles ablehnen was nicht von ihnen selbst kommt, und beleidigt werden wen ihre Vorschläge dann genauso nieder gebügelt werden und das wars dann aber auch.
Das sehe ich nicht als Nachteil.
Slackware ist für Leute, die es schlicht und einfach mögen, so dass sie selbst gut dran basteln können. Und die geringe Personenzahl ist der Garant dafür, dass es so bleibt, denn die paar Leute wollen sich schon aus Selbstschutz nicht "just for Fun" das Leben schwer machen.
Was passiert, wenn jeder mitmacht, sieht man an KDE. Das ist mittlerweile in 3 Subprojekte zerfallen, die Mühe haben, miteinander zu reden, und die Distributionen "dürfen" sich ein funktionierendes Gesamtpaket selbst zusammensuchen.
Das ist IMO dann ein Nachteil, wenn sich P.V. neue Sicherheitslücken anschaut, dann überprüft, ob Slackware betroffen ist, danach entscheidet, dass es keine Updates geben wird und niemandem mitteilt, warum Sicherheitsupdates nun ausgeblieben sind.
Das folgende Glibc-Update zeigt stellvertretend, um was es dabei geht:
http://www.slackware.com/security/viewer.php?l=slackware-security&y=2016&m=slackware-security.569827
[slackware-security] glibc (SSA:2016-054-02)
New glibc packages are available for Slackware 14.1 and -current to
fix security issues.
Here are the details from the Slackware 14.1 ChangeLog:
+--------------------------+
patches/packages/glibc-2.17-i486-11_slack14.1.txz: Rebuilt.
This update provides a patch to fix the stack-based buffer overflow in
libresolv that could allow specially crafted DNS responses to seize
control of execution flow in the DNS client (CVE-2015-7547). However,
due to a patch applied to Slackware's glibc back in 2009 (don't use the
gethostbyname4() lookup method as it was causing some cheap routers to
misbehave), we were not vulnerable to that issue. Nevertheless it seems
prudent to patch the overflows anyway even if we're not currently using
the code in question. Thanks to mancha for the backported patch.
For more information, see:
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-7547
(* Security fix *)
patches/packages/glibc-i18n-2.17-i486-11_slack14.1.txz: Rebuilt.
patches/packages/glibc-profile-2.17-i486-11_slack14.1.txz: Rebuilt.
patches/packages/glibc-solibs-2.17-i486-11_slack14.1.txz: Rebuilt.
Die Kernsätze sind dabei:
"However,
due to a patch applied to Slackware's glibc back in 2009 (don't use the
gethostbyname4() lookup method as it was causing some cheap routers to
misbehave), we were not vulnerable to that issue. Nevertheless it seems
prudent to patch the overflows anyway even if we're not currently using
the code in question."
Man sieht nun aber auch, dass die Slackware-Glibcen vor 14.1 nicht entsprechend gepatcht wurden.
So, jetzt stellt Euch einmal vor, P.V. hätte auch diesen Glibc-Patch für Slackware 14.1 unterlassen und ansonsten kein Wort mehr zu dieser Lücke gesagt.
Genau diese Art von Kommunikationskultur ist IMO eines der Hauptprobleme von Slackware.
Zudem ist auch ersichtlich, dass Slackware nicht grundsätzlich und durchgehend Sicherheitslücken bzw. sog. "Overflows" in allen angeblich noch unterstützten Distributionsversionen patcht, ganz im Gegensatz zu Firmen wie Red Hat oder Suse.
Ich bezweifle zudem, dass auch erfahrene Slackware-Admins jede aufgelaufenen Sicherheitslücke tracken und finden können, um diese dann gegebenenfalls selbst zu patchen. Würde man das selbst tun müssen, bräuchte man wohl einen 36-Stunden-Tag.