die beste?? also ein vernünftiges paketmanagement ist doch heutzutage pflicht! bei slackware werden ja nicht mal abhängigkeiten berücksichtigt oder hat sich da inzwischen was geändert?
Das hat auch Vorteile. Man kann Pakete wie z.B. libmad deinstallieren, ohne dass der installierte KDE gleich komplett auseinander fällt, wenn man z.B. in den USA lebt und das Paket wegen der dortigen Patentgesetze nicht auf dem Rechner haben möchte. Mach das mal mit Debian Etch. Bei einem mit der Etch-KDE-CD installierten KDE-Desktop führt die Abwahl der libmad über Apt/Synaptic zur Deinstallation von 279 Paketen, der gesamte KDE wird bis auf ein paar *data-Restpakete gleich mit deinstalliert.
Genau darum bin ich nach Ausflügen zu anderen Distries schon nach wenigen Tagen wieder zu Slackware zurückgekehrt.
Bei Slackware muß man nicht tonnenweise Sachen installieren lassen, von denen man weiß, daß sie nicht nötig sind, bei denen der Paketmanager aber der Meinung ist, daß sie erforderlich sind.
Wie hast Du das Update gemacht? Ich habe neulich ein 12.1 -System mit Slapt-get auf current umstellen wollen und danach startete das System gar nicht mehr da mit dem Dateisystem was nicht koscher war, das System landete immer jund immer wieder in einem Check und liess sich ums verrecken nicht starten -- Partitionen nicht gefunden (SATA).
Von anonymous coward am Do, 11. Dezember 2008 um 18:50 #
Eigentlich ist das schon eine Weile drin
Siehe Announce von 12.1: > We have added to Slackware support for HAL (the > Hardware Abstraction Layer) which allows the system administrator to add > users to the cdrom and plugdev groups.
Patrik Volkerding editiert die Ankündigung meist nur anstatt neue yu schreiben, höchstwarscheinlich hat er das einfach übersehen.
HAL ist - wie schon geschrieben wurde - mit 12.0 reingekommen, also relativ spät (verglichen mit anderen Distries). Das ist halt die Philosophie von Slackware - der Nutzer kennt sich aus und braucht Automatiken eigentlich gar nicht.
Irgendwann kommen sie halt doch rein, weil ein bisschen Komfort ja auch ganz nett sein kann, und man den Kram notfalls abschalten kann, ohne daß man damit das System zerlegt.
Ich finde immer wieder beeindruckend, wie Pat Volkerding hauptsächlich ganz alleine eine so gute Distro auf die Beine stellt. Auch Slackware wird ja von Version zu Version umfangreicher (immerhin 3,8 GB auf der Install-DVD der 12.1).
Dazu kommt, dass Slackware-Releases sehr lange supportet werden. Wenn man sich die letzten Security-Advisories ansieht sind meist noch Pakete für Slackware 10.x (Release 2005) dabei, im Falle von Bind im Juli 2008 sogar noch für Slackware 8.1 (von 2002). Das ist mal Long-Term-Support.
"Dazu kommt, dass Slackware-Releases sehr lange supportet werden. Wenn man sich die letzten Security-Advisories ansieht sind meist noch Pakete für Slackware 10.x (Release 2005) dabei, im Falle von Bind im Juli 2008 sogar noch für Slackware 8.1 (von 2002). Das ist mal Long-Term-Support."
Das stimmt doch nur teilweise. Wo sind die Kernel-, XFree86-, KDE 2.x- und Gnome-1.4.x-Updates für Slackware 8.1? Vielleicht betreibt jemand ja noch einen Slackware 8.1- oder 10.0-Server und weiß daher durch Vergleich mit den üblichen Sicherheits-Advisories, ob diese Versionen (ohne GUI) tatsächlich noch a l l e notwendigen Sicherheitsupdates bekommen.
Zudem patcht Slackware in den meisten Fällen nur dann, wenn ein Exploit vorliegt ("Where is the exploit?") oder wenn der Exploit derart auf der Hand liegt, dass man an einem Sicherheitsupdate nicht mehr "vorbeikommt".
Die volle Unterstützung für ältere Slackwareversionen läuft in etwa nach dem dritten darauf folgenden Release aus. Genaues dazu weiß man allerdings nicht, da darüber leider nicht offiziell geredet wird. Ausnahmen mag es geben. Diesen leichten Anflug von "Obscurity" finde ich aber nicht sehr vorteilhaft.
Die bind- und auch libpng-Updates für das alte Slackware 8.1 (Mitte 2002 erscheinen) sind natürlich ein absoluter "Hammer". So etwas würde ich mir auch von anderen Distros wünschen. Das wäre etwa so, als würde es noch Updates für Suse 8.0 (2002 erschienen) geben.
Nur sollte man diese immense Slackwareleistung ganz rational bewerten, "Aussenstehende" könnten das gründlich missverstehen: Es handelt sich gerade nicht um LTS-Support, so wie man ihn von Ubuntu oder Debian Woody (im letzteren Fall wohl etwas unfreiwillig) her kennt.
Von root mit hut am Fr, 12. Dezember 2008 um 00:07 #
da darüber leider nicht offiziell geredet wird. Du meinst große Ankündigungen? Slackware ist nicht umsonst bei fähigen Administratoren sehr beliebt. Da braucht es keine großen Schlagzeilen auf zdnet sondern Lösungen. Vor allem für kritische Komponenten wie bind und nicht für den KDE 2 Browser.
Aha. Wahrscheinlich hatten die meisten Slackwareadministratoren bind schon gepatcht, bevor der eigentliche Updatepatch von Slackware selbst kam. Von daher ist es dann auch nicht wichtig, ob überhaupt noch ein Patch kommt. So macht es dann wohl keinen Unterschied, ob man noch Slackware 8.0 oder 8.1 nutzt. Sehr logisch. EOL-Mitteilungen braucht man da nicht, "eternal support" heisst das Zauberwort.
Ironiemodus aus
Slackware finde ich klasse. "Das" (s.o) ist mein einziger kleiner Kritikpunkt. Und er ist berechtigt.
verglichen damit, wie viele full-time- Entwickler an den "großen" Distries mitarbeiten, ist das erstaunlich.
Volkerding hält Slackware konsequent möglichst schlicht und einfach, sonst könnte er das nicht schaffen.
Und das ist nicht nur nur ein Vorteil für ihn, sondern auch für die Anwender: Slackware ist nicht sonderlich komfortabel, aber so schlicht und einfach, daß man es leicht versteht und sich leicht selber helfen kann, statt darauf zu warten, daß ein gnädiger Entwickler die nicht richtig funktionierenden Komfortfunktionen fixt.
"Slackware ist nicht sonderlich komfortabel, aber so schlicht und einfach, daß man es leicht versteht und sich leicht selber helfen kann, statt darauf zu warten, daß ein gnädiger Entwickler die nicht richtig funktionierenden Komfortfunktionen fixt."
Das möchte ich ebenfalls unterstreichen. So sind etwa "fehlende" Kernel-Updates nicht wirklich ein Problem, kernel.org ist schließlich nicht weit.
"Volkerding hält Slackware konsequent möglichst schlicht und einfach, sonst könnte er das nicht schaffen."
Ein Paradebeispiel hierfür ist dieses Java-Update: http://www.slackware.com/security/viewer.php?l= slackware-security&y=2007&m=slackware-security.486841
"Updated packages for Slackware 8.1, 9.0, 9.1, 10.0, 10.1, 10.2, 11.0, and 12.0: ftp://ftp.slackware.com/pub/slackware/slackware-12.0/ patches/packages/jre-6u2-i586-1.tgz (...)"
Dazu folgender Kommentar: "Slackware repackages Sun's Java(TM) binaries without changing them, so the packages from Slackware 12.0 should work on all glibc based Slackware versions."
Wenn ich das richtig verstanden habe, wurden das Java-Updatepaket so gebaut, dass es auf allen glibc-2.x-basierten Slackware-Distros läuft. Wobei "so gebaut" eigentlich in diesem Fall bedeutet, "nicht mit Absicht verhunzt", so wie das bei manchen anderen Distros die Regel ist. Und genau das scheint auch der einfachste "Weg" gewesen zu sein: Ein einziges aktuelles Java-Updatepaket für "alle".
Wenn ich das richtig verstanden habe, wurden das Java-Updatepaket so gebaut, dass es auf allen glibc-2.x-basierten Slackware-Distros läuft. Du hast da wohl was falsch verstanden. Es sind einfach die offiziellen Binaries, die man direkt von Sun auf www.java.com erhält. Die laufen auch auf anderen Distributionen ohne Probleme. Problematisch ist nur die automatische Generierung von Abhängigkeiten durch das Paket-Build-Tool. Das weiß natürlich bei einer Erzeugung auf Debian Etch nicht, dass die Binaries auch unter Sarge laufen würden und setzt somit die Abhängigkeiten auf mind. die gerade auf Etch installierte glibc-Version.
Ein Java-Update verhält sich also eher wie ein Opera-Update (Opera gibt es in der aktuellen Version ja selbst noch für Suse 7.0 und Debian Potato). Linux-Kompatibilität aller Orten, wenn man nur will.
Proprietäre Software hat manchmal anscheinend auch Vorteile, wenn - wie in diesem Fall - die Softwarehersteller wie Sun und Opera von sich aus an größtmöglicher Kompatibilität zu neuen und alten Linuxdistributionen interessiert sind.
Von DarkVision am Do, 11. Dezember 2008 um 13:50 #
...über Slackware 12.2 hab ich hier gefunden. http://slackware.com/announce/12.2.php
Ist etwas informativer als der Copy'n'Paste Bericht. Ein bisschen mehr Recherche hätte sicher nicht geschadet. Da hätte man dann auch festgestellt das Dropline seit GNOME 2.20.2/3 für Slackware 12.0 kein Stable-Release mehr veröffentlicht hat. Wer Binary Pakete für Slackware 12.1 haben möchte sollte mal bei gnomeslackbuild.org , slacky.eu oder gware.org vorbeischauen.
Ein Glück, dass Slackware noch KDE 3.5.10 als Standardumgebung mitliefert. Mit Slackware 13.0 kann KDE 4 ruhig kommen. Das Schlimmste dürfte bis dahin wohl überstanden sein.
Das ist einer der Hauptgründe, warum ich mir die aktuelle Slackware nach mehreren Jahren Pause mal wieder installieren werde. Der andere Grund ist der, dass es bei Slackware auch als interesierter Laie möglich ist, sich in die Startskripte soweit reinzulesen, dass man wirklich kapiert, was beim Systemstart vor sich geht, und auch einzelne Parameter zu verändern. So kenn ich es zumindest vor ca. 2 Jahren.
Das ist mal ein schönes Weihnachtsgeschenk. Danke an Patrick V.
Die neue Version kommt genau zur richtigen Zeit, da ich sowieso vor hatte mal wieder einen Großputz inkl. Neuinstallation auf einem meiner Rechner durchzuführen.
Warum ist OpenOffice.org eigentlich nicht Teil der Distribution? Es gibt ja auch keinen einfachen Weg das zu installieren. Beim Benutzen der tar.gz-Installationspakete meckert der Installer über fehlendes RPM.
Du könntest es einfach mit rpm2tgz probieren: http://www.howledge.com/index.php?action=artikel&cat=1&id=2&artlang=en Oder: http://slackbuilds.org/repository/12.1/office/openoffice.org/ Oder aber: http://www.linuxpackages.net/pkg_details.php?id=12444
Die älteste noch existierende - ja.
Die älteste - nein.
also ein vernünftiges paketmanagement ist doch heutzutage pflicht!
bei slackware werden ja nicht mal abhängigkeiten berücksichtigt oder hat sich da inzwischen was geändert?
slapt-get, swaret oder seit 12.2 integriert: slackpkg.
> bei slackware werden ja nicht mal abhängigkeiten berücksichtigt
Mich persönlich stört das nicht im geringsten. Wer es braucht findet sicher das passende unter den unzähligen GNU/ Linux-Distributionen.
> die beste??
Der OP schrieb: "Meiner Meinung nach".
Man kann Pakete wie z.B. libmad deinstallieren, ohne dass der installierte KDE gleich komplett auseinander fällt, wenn man z.B. in den USA lebt und das Paket wegen der dortigen Patentgesetze nicht auf dem Rechner haben möchte.
Mach das mal mit Debian Etch.
Bei einem mit der Etch-KDE-CD installierten KDE-Desktop führt die Abwahl der libmad über Apt/Synaptic zur Deinstallation von 279 Paketen, der gesamte KDE wird bis auf ein paar *data-Restpakete gleich mit deinstalliert.
Bei Slackware muß man nicht tonnenweise Sachen installieren lassen, von denen man weiß, daß sie nicht nötig sind, bei denen der Paketmanager aber der Meinung ist, daß sie erforderlich sind.
Jetzt sagt bitte nicht, dass das eine Neuigkeit in 12.2 ist?!
Lese dir dazu bitte ftp://ftp.slackware.com/pub/slackware/slackware-current/CHANGES_AND_HINTS.TXT durch.
Deine Problem fuehrt auf udev zurueck.
Siehe Announce von 12.1:
> We have added to Slackware support for HAL (the
> Hardware Abstraction Layer) which allows the system administrator to add
> users to the cdrom and plugdev groups.
Patrik Volkerding editiert die Ankündigung meist nur anstatt neue yu schreiben, höchstwarscheinlich hat er das einfach übersehen.
Irgendwann kommen sie halt doch rein, weil ein bisschen Komfort ja auch ganz nett sein kann, und man den Kram notfalls abschalten kann, ohne daß man damit das System zerlegt.
Dazu kommt, dass Slackware-Releases sehr lange supportet werden. Wenn man sich die letzten Security-Advisories ansieht sind meist noch Pakete für Slackware 10.x (Release 2005) dabei, im Falle von Bind im Juli 2008 sogar noch für Slackware 8.1 (von 2002). Das ist mal Long-Term-Support.
Das stimmt doch nur teilweise.
Wo sind die Kernel-, XFree86-, KDE 2.x- und Gnome-1.4.x-Updates für Slackware 8.1?
Vielleicht betreibt jemand ja noch einen Slackware 8.1- oder 10.0-Server und weiß daher durch Vergleich mit den üblichen Sicherheits-Advisories, ob diese Versionen (ohne GUI) tatsächlich noch a l l e notwendigen Sicherheitsupdates bekommen.
Zudem patcht Slackware in den meisten Fällen nur dann, wenn ein Exploit vorliegt ("Where is the exploit?") oder wenn der Exploit derart auf der Hand liegt, dass man an einem Sicherheitsupdate nicht mehr "vorbeikommt".
Die volle Unterstützung für ältere Slackwareversionen läuft in etwa nach dem dritten darauf folgenden Release aus.
Genaues dazu weiß man allerdings nicht, da darüber leider nicht offiziell geredet wird.
Ausnahmen mag es geben.
Diesen leichten Anflug von "Obscurity" finde ich aber nicht sehr vorteilhaft.
Die bind- und auch libpng-Updates für das alte Slackware 8.1 (Mitte 2002 erscheinen) sind natürlich ein absoluter "Hammer". So etwas würde ich mir auch von anderen Distros wünschen. Das wäre etwa so, als würde es noch Updates für Suse 8.0 (2002 erschienen) geben.
Nur sollte man diese immense Slackwareleistung ganz rational bewerten, "Aussenstehende" könnten das gründlich missverstehen:
Es handelt sich gerade nicht um LTS-Support, so wie man ihn von Ubuntu oder Debian Woody (im letzteren Fall wohl etwas unfreiwillig) her kennt.
Du meinst große Ankündigungen? Slackware ist nicht umsonst bei fähigen Administratoren sehr beliebt. Da braucht es keine großen Schlagzeilen auf zdnet sondern Lösungen. Vor allem für kritische Komponenten wie bind und nicht für den KDE 2 Browser.
Aha.
Wahrscheinlich hatten die meisten Slackwareadministratoren bind schon gepatcht, bevor der eigentliche Updatepatch von Slackware selbst kam.
Von daher ist es dann auch nicht wichtig, ob überhaupt noch ein Patch kommt.
So macht es dann wohl keinen Unterschied, ob man noch Slackware 8.0 oder 8.1 nutzt.
Sehr logisch.
EOL-Mitteilungen braucht man da nicht, "eternal support" heisst das Zauberwort.
Ironiemodus aus
Slackware finde ich klasse.
"Das" (s.o) ist mein einziger kleiner Kritikpunkt.
Und er ist berechtigt.
verglichen damit, wie viele full-time- Entwickler an den "großen" Distries mitarbeiten, ist das erstaunlich.
Volkerding hält Slackware konsequent möglichst schlicht und einfach, sonst könnte er das nicht schaffen.
Und das ist nicht nur nur ein Vorteil für ihn, sondern auch für die Anwender: Slackware ist nicht sonderlich komfortabel, aber so schlicht und einfach, daß man es leicht versteht und sich leicht selber helfen kann, statt darauf zu warten, daß ein gnädiger Entwickler die nicht richtig funktionierenden Komfortfunktionen fixt.
Das möchte ich ebenfalls unterstreichen.
So sind etwa "fehlende" Kernel-Updates nicht wirklich ein Problem, kernel.org ist schließlich nicht weit.
"Volkerding hält Slackware konsequent möglichst schlicht und einfach, sonst könnte er das nicht schaffen."
Ein Paradebeispiel hierfür ist dieses Java-Update:
http://www.slackware.com/security/viewer.php?l=
slackware-security&y=2007&m=slackware-security.486841
"Updated packages for Slackware 8.1, 9.0, 9.1, 10.0, 10.1, 10.2, 11.0, and 12.0:
ftp://ftp.slackware.com/pub/slackware/slackware-12.0/
patches/packages/jre-6u2-i586-1.tgz
(...)"
Dazu folgender Kommentar:
"Slackware repackages Sun's Java(TM) binaries without changing them,
so the packages from Slackware 12.0 should work on all glibc based
Slackware versions."
Wenn ich das richtig verstanden habe, wurden das Java-Updatepaket so gebaut, dass es auf allen glibc-2.x-basierten Slackware-Distros läuft.
Wobei "so gebaut" eigentlich in diesem Fall bedeutet, "nicht mit Absicht verhunzt", so wie das bei manchen anderen Distros die Regel ist.
Und genau das scheint auch der einfachste "Weg" gewesen zu sein:
Ein einziges aktuelles Java-Updatepaket für "alle".
Du hast da wohl was falsch verstanden. Es sind einfach die offiziellen Binaries, die man direkt von Sun auf www.java.com erhält. Die laufen auch auf anderen Distributionen ohne Probleme.
Problematisch ist nur die automatische Generierung von Abhängigkeiten durch das Paket-Build-Tool. Das weiß natürlich bei einer Erzeugung auf Debian Etch nicht, dass die Binaries auch unter Sarge laufen würden und setzt somit die Abhängigkeiten auf mind. die gerade auf Etch installierte glibc-Version.
Danke für den Hinweis.
Ein Java-Update verhält sich also eher wie ein Opera-Update (Opera gibt es in der aktuellen Version ja selbst noch für Suse 7.0 und Debian Potato).
Linux-Kompatibilität aller Orten, wenn man nur will.
Proprietäre Software hat manchmal anscheinend auch Vorteile, wenn - wie in diesem Fall - die Softwarehersteller wie Sun und Opera von sich aus an größtmöglicher Kompatibilität zu neuen und alten Linuxdistributionen interessiert sind.
http://slackware.com/announce/12.2.php
Ist etwas informativer als der Copy'n'Paste Bericht. Ein bisschen mehr Recherche hätte sicher nicht geschadet. Da hätte man dann auch festgestellt das Dropline seit GNOME 2.20.2/3 für Slackware 12.0 kein Stable-Release mehr veröffentlicht hat. Wer Binary Pakete für Slackware 12.1 haben möchte sollte mal bei gnomeslackbuild.org , slacky.eu oder gware.org vorbeischauen.
Mit Slackware 13.0 kann KDE 4 ruhig kommen.
Das Schlimmste dürfte bis dahin wohl überstanden sein.
Die neue Version kommt genau zur richtigen Zeit, da ich sowieso vor hatte mal wieder einen Großputz inkl. Neuinstallation auf einem meiner Rechner durchzuführen.
:Daumen hoch:
http://www.howledge.com/index.php?action=artikel&cat=1&id=2&artlang=en
Oder:
http://slackbuilds.org/repository/12.1/office/openoffice.org/
Oder aber:
http://www.linuxpackages.net/pkg_details.php?id=12444
Der Desktop bleibt aber aktiv.
Klickt man nun Rechtsklick auf Logout, dann passoert auch nichts.
Die X Session kann ich nur mit einem kill -9 Befehl beendet.