Java fehlt nicht. Java wird auch regelmäßig mit Updates versorgt. Im Changelog steht u.a.: "l/jre-6u5-i586-1.tgz: Upgraded to Java(TM) 2 Platform Standard Edition Runtime Environment Version 6.0 update 5. (...) extra/jdk-6/jdk-6u5-i586-1.tgz: Upgraded to Java(TM) 2 Platform Standard Edition Development Kit Version 6.0 update 5."
Soweit so gut. Nur stürzt mir der artsd JEDESMAL und ANDAUERND ab. Das ging so weit, dass ich KDE abschießen musste, weil sich die Fehlermeldungen vom abgestürzten artsd stapelten. Slack ist leider nichts mehr für mich. Bevorzuge mittlerweile dann doch ein etwas fortschrittlicheres System, das Benutzerfreundlichkeit mehr in den Vordergrund stellt. Aber als damalige Lerndistri absolut top!
Slackware ist halt einfacher als andere Distros. Schau Dir z.B. einmal an, wie einfach man unter Slackware eigene Pakete bauen kann. Wenn man das z.B. weiß, dann ahnt man so langsam, was dem Nutzer unter anderen Distros schon regelrecht "vorenthalten" wird.
Glaub mir ich weiß wie man Pakete baut, liegen doch sogar noch gesicherte SlackBuilds auf der externen. ;) Dass Slackware "einfacher" ist muss ich bestreiten, bzw. etwas verdeutlichen was du glaube ich sagen wolltest. Slackware ist zwar im Gerüst und im Aufbau des Systems einfacher (und überschaubarer) als manch andere Distri, aber bei weitem nicht so einfach (zu bedienen) wie Ubuntu oder Mandriva. Und zu dem "vorenthalten": Nenn doch mal ein Beispiel, dass dir in (nur als Beispiel) Ubuntu "vorenthalten" wird, was du mit Slackware besser erledigen kannst.
Nur ein Beispiel: Ich habe jüngst versucht, Wine-0.9.58 unter Suse 9.0 zu installieren. Das klappte auch zunächst alles gut, alle Paketabhängigkeiten (auch z.B. fontforge) habe ich nachinstalliert. Die Kompilation lief ohne Probleme durch. Das entstandene rpm wollte ich installieren. Dann rebelliert auf einmal Yast wegen einer angeblich nicht erfüllten Abhängigkeit (das war allerdings Stuß). "Ganz grosse Gefahr, bitte nicht installieren, sonst geht Dein System kaputt." Es ging natürlich, Yast habe ich gelöscht. Das meinte ich mit "vorenthalten", auch wenn ich selbst hier keinerlei Absicht unterstellen möchte.
Ok, Suse (in Version 9) als schlechtes Beispiel für das von mir vorgeschlagene Ubuntu zu nehmen ist etwas .. daran vorbei. ;) In Slackware passiert dir sowas nicht, weil gar keine Abhängigkeiten existieren. Aber ich rede hier vom allgemeinen Gebrauch des Systems. In 90% der Fälle BRAUCHT man nicht einmal iewas kompilieren oder gar Pakete bauen in Ubuntu. D a s ist der Punkt.
Gut, ich verstehe Deine Argumentation. Das funktioniert so auch alles reibungslos, solange das entsprechende Ubuntu noch mit Sicherheitsupdates versorgt wird. Was ist aber, wenn jemand z.B. Ubuntu 5.10 so klasse fand, dass er es auch nach Supportende weiter benutzen möchte? Dann "würde" es auch hier genau solche Probleme geben. Ich schreibe absichtlich "würde", weil ich den Eindruck habe, dass die meisten Ubuntu-Nutzer mit der "Ubuntu-Karawane" alle sechs Monate weiter wandern.
Ich habe allerdings Bekannte, die früher Windows benutzt haben oder parallel immer noch Windows XP benutzen, denen ich vor Jahren einmal zur Anschaffung von Suse 9.0 geraten habe. Als ich da nach knapp zwei Jahren eher beiläufig darauf hinwies, dass die Suse 9.0 ja jetzt durch eine neue Suse ersetzt werden müsse, weil der Support beendet worden ist, erntete ich nur ungläubiges Staunen. So ginge das ja wohl nicht, Microsoft macht das ja auch nicht, die Hardware wird hervorragend unterstützt, warum denn "updaten"? So geht es auch nicht. Was soll ich denn auch sagen, wenn mich jemand fragt: Läuft das neue Wine unter Suse 9.0? Soll ich sagen, nein, läuft nicht, nimm OpenSuse 10.3 oder Ubuntu oder Slackware, aber lass mich in Ruhe? Auch wenn es in diesem Zusammenhang ungerecht ist, Linux etwas vorzuwerfen, das ist doch mit ein Grund, warum Linux selbst heute noch nicht wirklich auf dem "Desktop" angekommen ist.
Wohl war, insbesondere im Bezug zu dem Ankommen auf dem Desktop. Allerdings muss man ja auch sehen, dass solch ein Update im 6-Monatszyklus in 90% der Fälle ohne große Probleme von statten geht. Dass es dabei zu Problemen kommen kann.. davon ist sicherlich kein BS verschont.
Das auf einer Version "Sitzen bleiben" weil es ja gut läuft ... nunja, dafür gibt es ja die LTS Versionen! Der Nachteil: einige Pakete die aktuell sein müssen, werden nicht aktualisiert sein. Aber da ist der Punkt wo man sich dann schon fragen sollte ob dann nicht gleich die aktuellere Version (nicht LTS) angemessener ist. Ich sehe da gar nicht mehr so das große Problem drin in den Zyklen und Aktualität einiger Pakete. Klar, wine und ein paar andere sind da noch so Spezialfälle,.. da gehts manchmal nicht anders als in Version xx.xx.
Aber bei all den Fortschritten denke ich wird es nicht lang dauern dann gibts auch eine grafische simple Oberfläche um von anderen Sites Pakete zu beziehen (sources.list usw). Da sehe ich auch die Zukunft drin: Hersteller veröffentlichen in Quellcode und in kompilierter Form. Der Downloadlink des letzteren entspricht dem adden der source in die sources.list und einem darauf folgenden ausgeführten apt-get install neues-paket. Leider hat daran noch nie jemand gedacht wie es scheint bzw. es nicht umsetzen können. brainstorm ist ja zum Glück erfunden worden.
Das kann ich nur unterstreichen. Besonders diese (sorry) kranken Paketabhängikeitsprüfungen, die meisten nur unnütze Müllmeldungen herausgeben, hat man bei Slack nicht. Und das ist für mich einer der allergrössten Pluspunkte. Wer bei bei Debian oder SuSE aus deren normalen Repositories Software installiert, der hat sicher kaum Schwierigkeiten. Aber wenn man etwas abseits des Distro-Wegs wandeln möchte, dann geht das Versionsfetischismus bei den Abhängigkeiten los. Entweder man hat eine zu alte Library auf dem System - welche oftmals garkeine Probleme machen würde - oder, was noch nervender, man hat eine zu neue.
das stimmt: """Besonders diese (sorry) kranken Paketabhängikeitsprüfungen, die meisten nur unnütze Müllmeldungen herausgeben""" ich habe bei ubuntu festgestellt, das seit dapper nicht mehr so ist wie mal war bzw. wie warty oder hoary.... schade eigentlich.
aber, wenn Slakware besser sein soll, wie du behauptest...? und auch 64Bit existiert und keine probleme macht (flash ist mir nicht wichtig) dann teste ich einfach diese Distro.
> Nenn doch mal ein Beispiel, dass dir in (nur als Beispiel) Ubuntu "vorenthalten" wird, > was du mit Slackware besser erledigen kannst.
VDR 1.6.0
In Ubuntu (einer von den Ubuntu Jüngern so genannten LTS Version!) ist ne Beta 1.5.irgendwas dabei.
Jetzt kompilier mal VDR unter Slackware (snip, _sehr_ einfach) und unter Ubuntu *lol*
Besonders schlimm find ich es, wenn partout kein Update rauskommt und ein unbedingt benötigtes Feature nur in einer neueren Version vorhanden ist. Einmal ist es mir sogar passiert, daß sich bei Ubuntu über zwei Versionen hinweg rein garnix getan hat (amavisd-new). Da bin ich dann wieder zu Fedora gewechselt als Paketausprobierdistribution. Arbeitstier ist Slackware.
> Nenn doch mal ein Beispiel
Ein weiteres: ACPI bzw. Suspend 2 RAM. Unter Ubuntu und/oder Fedora funktioniert es nicht, da die Kernel in dieser Hinsicht in welcher Richtung auch immer gepatched sind. Unter Slackware mit dem Vanilla-Kernel funktioniert Suspend 2 RAM einwandfrei (Thinkpad R51), sogar die WLAN Verbindung ist adhoc wieder verfügbar (madwifi).
> Nenn doch mal ein Beispiel
Ein drittes: Ubuntu und Fedora ist schon ganz nett wenn man auf Entdeckungsreise bezüglich Pakete ist. Hat man aber "seine" Anwendungen beisammen, sind die entweder a) bei Slackware dabei b) sehr leicht von Hand zu pflegen
[quote]Ein weiteres: ACPI bzw. Suspend 2 RAM. Unter Ubuntu und/oder Fedora funktioniert es nicht, da die Kernel in dieser Hinsicht in welcher Richtung auch immer gepatched sind. Unter Slackware mit dem Vanilla-Kernel funktioniert Suspend 2 RAM einwandfrei (Thinkpad R51), sogar die WLAN Verbindung ist adhoc wieder verfügbar (madwifi).[/quote]
Hmm, dann leistet Stefan Lippers-Hollmann mit seinen Kerneln hervorragende Arbeit. Unter menen IBM TP R51 läuft alles, sidux sei dank :-)
Das ist doch d e r Punkt: Paketabhängigkeiten, die eine Installation und u.U. die Kompilation eines eigenen Paketes aus dem Quellcode der Originalautoren verhindern (letzteres gilt natürlich nicht für Linux-Distros allgemein). Suche doch in einer Slackware-Distro nach diesen unseligen "dev"-Paketen. Na, wo sind sie denn? Ich meine halt nur, dass Slackware u.a. in dieser Hinsicht einfacher zu bedienen ist, trotz "Paketabhängigkeiten".
Von Christopher Bratusek am Do, 3. April 2008 um 17:31 #
man kann auch unter Debian alle Dateien in ein Paket packen, kein Problem. Die Aufsplittung spart Speicherplatz auf LiveCDs, Servern oder End-User-Systemen, welche die Header und Libtool-Archive nicht benötigen.
Ausserdem sind .spec und debian/* sehr flexibel (z.B. im Bezug auf Makros). Ich erstelle täglich Debianpakete und habe mir nie gedacht "Ach wär das toll, Slackwares Pkgtools auf Debian zu haben". Nur weil es dir gefällt ist es noch lange nicht besser. Höchstens genauso gut.
> habe mir nie gedacht "Ach wär das toll, Slackwares Pkgtools auf Debian zu haben". > Nur weil es dir gefällt ist es noch lange nicht besser. Höchstens genauso gut. > Das sehen Slackware-User sicher genau anders herum.
Von Marcus Moeller am Do, 3. April 2008 um 20:37 #
"Ausserdem sind .spec und debian/* sehr flexibel (z.B. im Bezug auf Makros). Ich erstelle täglich Debianpakete und habe mir nie gedacht "Ach wär das toll, Slackwares Pkgtools auf Debian zu haben". Nur weil es dir gefällt ist es noch lange nicht besser. Höchstens genauso gut."
Debians dpkg ist als Paketmanagementtool sicher sehr mächtig, wenn du allerdings Pakete nach Maintainer Guidelines bauen willst, ist der Aufwand exorbital größer, der effektive Mehrwert jedoch eher gering.
Von Christopher Bratusek am Fr, 4. April 2008 um 08:01 #
>> ist der Aufwand exorbital größer, der effektive Mehrwert jedoch eher gering.
dh_make erstellt alle wichtigen dateien. (control, changelog, rules, et cetera), das anpassen derer und das hinzufügen der postinst/rm oder preinst/rm skripte (fall benötigt) dauert dann noch knapp 1 - 3 minuten (und dass muss nat. nicht bei jedem update wiederholt werden).
Nunja ob 1 - 3 minuten exorbitant sind ...
>> wenn du allerdings Pakete nach Maintainer Guidelines bauen willst
dh_make erstellt alle wichtigen dateien. (control, changelog, rules, et cetera) Wenn man damit ein Paket baut, landen die Dateien dort, wo Upstream sie hinsetzen wollte, Dokumentation möglicherweise in /usr/doc. Das ist gemäß Maintainer-Guidelines aber z.B. verboten. Zudem müssen dist-upgrades von den letzten beiden Versionen (=stable+testing) reibungslos funktionieren.
> also ich bin froh dass ich meine paketabhängigkeiten nicht selbst auflösen muss
Wenn man darauf Wert legt, sollte man auch kein Slackware nehmen. Teilweise ist es aber in Slackware einfacher, selbst erstellte Pakete einzupflegen, die mit bestimmten Optionen übersetzt wurden.
Wenn Du Programme selbst komplilierst - besonders bei ganz aktuellen Versionen - kommst Du gar nicht umhin, Dir die Pakete selbst zu besorgen, die benötigt werden. Besonders wenn es nicht die "üblichen Verdächtigen" sind. Und die bekommst Du auch vom entsprechenden Maintainer/Projekt-Homepage als tar.gz Mit apt-get stehst Du im Zweifelsfall total auf dem Schlauch, weil da nix im Repository ist.
In Zeiten von so tollen Sachen wie Build Services stimmt das gar nicht mehr. Woher soll der Build Service wissen, welche Abhängigkeiten ein Programm hat? Um das SPEC-File überhaupt schreiben zu können, musst du erst einmal selbst herausfinden, welche BuildDependencies notwendig sind.
Und Binärpakete als .tar.gz bekommst du doch fast nirgends. Jedes Debian-Paket enthält die eigentlichen Dateien als Tarball. Und Debian-Pakete gibts genug.
Von Marcus Moeller am Do, 3. April 2008 um 20:27 #
Mir ist schleierhaft warum artsd bei dir 'dauernd abgestürzt ist'. Bei mir ist unser Slackware artsd glaube ich noch nie abgestürzt und ich nutze Slack schon länger als es artsd gibt.
Das einzige was ich mir vorstellen kann ist das die alsa Mixer Einstellungen nicht definiert waren (musste man bis einschließlich Slackware 12.1 noch manuell tun). Spätestens seit 19.3. ist das in Current aber auch Geschichte:
"Set reasonable volume defaults if there are none in /etc/asound.state."
Ich hab nur die RC1 DVD geladen und eine Full Install gemacht. Nach anmelden per KDM wurde mir dann artsd entgegen geballert. ;) Ist halt noch (fast verfrühte laut PV) RC.
Mein Eindruck ist, daß man mit jeder Distri Probleme auf bestimmter Hardware haben kann.
Darum kann man in jedem Forum Berichte von Leuten finden, die auf irgendeine Distribution schimpfen und dann jede Menge Protestierer auf den Plan rufen, die das bestreiten.
Ich habe hier einen 3 1/2 Jahre alten Rechner, der mehrere Slackware- Versionen problemlos verdaut hatte, aber unter Slackware 12 dann öfter mal einfror. Da habe ich dann auf die 12er geschimpft und die erst mal nicht auf zwei anderen Rechnern installiert.
Irgendwann war es aber doch so weit, und - siehe da - auf den beiden anderen Rechnern gab es keine Probleme. Den Problemrechner habe ich dann auf Slackware-current gebracht, und die Probleme waren dann dort auch weg.
Ich vermute, daß in Slackweare 12 ein Entwicklungsstand des Kernels oder in der Xorg- Pakete Treiber für meine Hardware enthalten waren, die zu dem Zeitpunkt instabil waren.
Solche Probleme sollte man nicht verallgemeinern und zum allgemeinen Qualitätsstand der Distribution erklären.
Ach ja: noch was: sicherlich ist Slackware nicht so umfangreich wie alle Distributionen; da es aber z.B. keine separaten devel- Pakete gibt und die Pakete nicht so fein geschnitten sind wie z.B. bei Debian oder Ubuntu, darf man nicht direkt 500 Pakete zu 20000 ins Verhältnis setzen.
Und wie C't früher immer so schön bei Apple- Besprechungen schrieb: bei Apple gibt es für viele Einsatzbereiche nur ein Programm, aber das deckt alle Wünsche ab.
Jedenfalls solange, bis Novell es dann an sich riss.
Aber vielleicht macht sich ja noch mal jemand ran und entwickelt wieder aus Slackware ein zweites SuSE, so wie es damals war?
Schlecht wärs jedenfalls nicht.
Ansonsten finde ich es erfreulich, dass es Slackware noch gibt. Ist zwar keine Distri, die man so ohne weiteres handhaben kann, aber dafür gibts wenigstens nicht so ein elitäres Gehabe und soviel Knatsch, wie bei der bekannten anderen Distri, deren Namen ich hier garnicht nennen will, der aber mit "D" anfängt.
Und wenn Slackware erstmal läuft, dann läuft es jedenfalls auch sehr stabil und sicher.
Jap. Es fehlt definitiv eine Slackware-basierende Distribution die ein riesen Repository an aktuellen Paketen bietet, grafischen Installer und mehr Wert auf Nutzerfreundlichkeit.
Halt Moment... dann wären wir ja (sehen wir mal vom Gerüst ab) bei einem Ubuntu oder gar Mandriva! ;)
Wie weiter oben geschrieben scheint man ja dauernd Probleme mit alten oder zu neuen libs zu haben (ich schein da wohl ne Ausnahme zu sein). Sofern man sich etwas mit dem System auseinandersetzt (was bei Slack Zwang ist) versteht man auch sehr schnell dass man in Ubuntu einfach Pakete bauen kann, zB mit checkinstall.
edit: Versteht micht nicht falsch: ich liebe Slackware nach wie vor. Nur sollte man seine genauen Einsatzgebiete erkennen und wenn sich diese ändern sollte man auch die Distri dementsprechend ändern. Alles andere wäre kontraproduktiv. Slackware ist eben sehr UNIX-'rein' und bedarf einiger Dokumentation um es zu nutzen. Nicht das was man eigentlich von einem BS erwartet, das man BEnutzt, aber von einem das man NUTZT.
Weil das Grundgerüst und die damit verbunden Bauweise zu kompliziert ist wenn man ein paar tausend Files aktuell halten möchte. Redundanz ist da nur ein Stichwort das mir gerade dazu einfällt.
Dass man bei Slackware etwas länger auf Sicherheitsaktualisierungen warten muss, das stimmt.
Das wird aber - das ist meine persönliche Meinung - durch mindestens zwei Vorteile aufgewogen:
1. Von Slackware-Seite her gibt es keinerlei künstliche Beschränkungen, was den Anwendungsbereich der Updates anbelangt. Bsp.: Dieses Java-Update für Slackware 12.0: http://www.slackware.com/security/ viewer.php?l=slackware-security&y=2007&m=slackware-security.486841 Dieses Java läuft nicht etwa nur auf Slackware 12.0 oder 11.0, nein, es läuft auf jeder glibc-basierten Slackware-Distro: "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." Das ist etwa so, als würde Novell mit den neuen Java-Aktualisierungen für OpenSuse 10.3 ein entsprechend aktualisiertes Java in der gleichen Version "spendieren", das noch auf Suse 6.0 lauffähig wäre.
2. Slackware unterstützt seine Veröffentlichungen sehr, sehr lange. Ein Beispiel ist dieses libpng-Update von Ende 2007: http://www.slackware.com/security/ viewer.php?l=slackware-security&y=2007&m=slackware-security.520323 "New libpng packages are available for Slackware 8.1, 9.0, 9.1, 10.0, 10.1, 10.2, 11.0, 12.0, and -current to fix security issues." Slackware 8.1 wurde im Juni 2002 veröffentlicht. Selbst jetzt gibt es noch Aktualisierungen dafür. Slackware kennt keine Aktualisierungsbeschränkungen auf 18 oder 24 Monate. Für einen normalen Anwender ist das schlichtweg "Wahnsinn", d.h. wahnsinnig gut.
Hmmm, das "elitäre Gehabe" und den "Knatsch" im Zusammenhang mit Debian hätte ich dann doch gerne etwas näher von Dir erläutert. Sollte das allerdings nicht über Deinen persönlichen Geschmack hinaus gehen, dann lass es. Ich fang hier auch nicht an, mich darüber auszulassen, warum mir Schokoladeneis besser schmeckt, als Erdbeereis.
[quote]Und wenn Slackware erstmal läuft, dann läuft es jedenfalls auch sehr stabil und sicher.[/quote] Oh ja, hier spricht der Profi ;-)
Ich habe Slackware sehr lange benutzt und halte es heute noch für eine der gelungensten Distris. Vor ein paar Monaten bin ich dann auf Arch Linux umgestiegen. Der Vorteil von Arch gegenüber Slack ist das integrierte Ports-System und das m. E. sauberere Init-Konzept mit /etc/rc.conf und den Start-Stop-Scripten unter /etc/rc.d. Bei Slackware fand ich die unterteilung der Skripten (inet1, inet2 usw.) immer etwas eigenwillig und nicht leicht zu durchschauen.
Arch habe ich auch mal ein paar Tage lang benutzt. Mir ging auf den Zeiger, daß es da alle paar Tage ein paar hundert MB zum runterladen gab, weil es von Arch wohl keine stabile Version gibt, sondern es mit Slackware- current zu vergleichen ist.
Ich fand es noch schlimmer als Slackware-current, denn bei Arch hatte ich es ein- oder zweimal, daß der Paketmanager das Update abbrach und wegen irgendwelcher kaputter Paketabhängigkeiten herumheulte. Das löste sich dann ohne eigenes Zutun durch Abwarten, aber hat mich doch ziemlich abgeschreckt.
Das stimmt wohl, es gibt keine "stabile" Arch Linux Version im herkömmlichen Sinne - alles ist ziemlich bleeding Edge. Das auf Arch Linux basierende Frugalware kennt dagegen wohl stabile Versionen, jedoch hält sich Frugalware nicht mehr so ganz an das KISS-Prinzip, was mich wiederum gestört hat.
Größere Probleme hatte ich bei Arch noch nicht. Und da ich in der letzten Zeit vor Arch sowieso Slackware-current hatte gab es auch keinen so großen Unterschied bei den Downloads.
Java wird auch regelmäßig mit Updates versorgt.
Im Changelog steht u.a.:
"l/jre-6u5-i586-1.tgz: Upgraded to Java(TM) 2 Platform Standard Edition Runtime Environment Version 6.0 update 5.
(...)
extra/jdk-6/jdk-6u5-i586-1.tgz: Upgraded to Java(TM) 2 Platform Standard Edition Development Kit Version 6.0 update 5."
Schau Dir z.B. einmal an, wie einfach man unter Slackware eigene Pakete bauen kann.
Wenn man das z.B. weiß, dann ahnt man so langsam, was dem Nutzer unter anderen Distros schon regelrecht "vorenthalten" wird.
Dass Slackware "einfacher" ist muss ich bestreiten, bzw. etwas verdeutlichen was du glaube ich sagen wolltest. Slackware ist zwar im Gerüst und im Aufbau des Systems einfacher (und überschaubarer) als manch andere Distri, aber bei weitem nicht so einfach (zu bedienen) wie Ubuntu oder Mandriva.
Und zu dem "vorenthalten": Nenn doch mal ein Beispiel, dass dir in (nur als Beispiel) Ubuntu "vorenthalten" wird, was du mit Slackware besser erledigen kannst.
Ich habe jüngst versucht, Wine-0.9.58 unter Suse 9.0 zu installieren.
Das klappte auch zunächst alles gut, alle Paketabhängigkeiten (auch z.B. fontforge) habe ich nachinstalliert. Die Kompilation lief ohne Probleme durch.
Das entstandene rpm wollte ich installieren.
Dann rebelliert auf einmal Yast wegen einer angeblich nicht erfüllten Abhängigkeit (das war allerdings Stuß).
"Ganz grosse Gefahr, bitte nicht installieren, sonst geht Dein System kaputt."
Es ging natürlich, Yast habe ich gelöscht.
Das meinte ich mit "vorenthalten", auch wenn ich selbst hier keinerlei Absicht unterstellen möchte.
So etwas passiert mir in Slackware so nicht.
In Slackware passiert dir sowas nicht, weil gar keine Abhängigkeiten existieren. Aber ich rede hier vom allgemeinen Gebrauch des Systems. In 90% der Fälle BRAUCHT man nicht einmal iewas kompilieren oder gar Pakete bauen in Ubuntu. D a s ist der Punkt.
Was ist aber, wenn jemand z.B. Ubuntu 5.10 so klasse fand, dass er es auch nach Supportende weiter benutzen möchte?
Dann "würde" es auch hier genau solche Probleme geben.
Ich schreibe absichtlich "würde", weil ich den Eindruck habe, dass die meisten Ubuntu-Nutzer mit der "Ubuntu-Karawane" alle sechs Monate weiter wandern.
Ich habe allerdings Bekannte, die früher Windows benutzt haben oder parallel immer noch Windows XP benutzen, denen ich vor Jahren einmal zur Anschaffung von Suse 9.0 geraten habe.
Als ich da nach knapp zwei Jahren eher beiläufig darauf hinwies, dass die Suse 9.0 ja jetzt durch eine neue Suse ersetzt werden müsse, weil der Support beendet worden ist, erntete ich nur ungläubiges Staunen. So ginge das ja wohl nicht, Microsoft macht das ja auch nicht, die Hardware wird hervorragend unterstützt, warum denn "updaten"?
So geht es auch nicht.
Was soll ich denn auch sagen, wenn mich jemand fragt: Läuft das neue Wine unter Suse 9.0?
Soll ich sagen, nein, läuft nicht, nimm OpenSuse 10.3 oder Ubuntu oder Slackware, aber lass mich in Ruhe?
Auch wenn es in diesem Zusammenhang ungerecht ist, Linux etwas vorzuwerfen, das ist doch mit ein Grund, warum Linux selbst heute noch nicht wirklich auf dem "Desktop" angekommen ist.
Allerdings muss man ja auch sehen, dass solch ein Update im 6-Monatszyklus in 90% der Fälle ohne große Probleme von statten geht. Dass es dabei zu Problemen kommen kann.. davon ist sicherlich kein BS verschont.
Das auf einer Version "Sitzen bleiben" weil es ja gut läuft ... nunja, dafür gibt es ja die LTS Versionen!
Der Nachteil: einige Pakete die aktuell sein müssen, werden nicht aktualisiert sein. Aber da ist der Punkt wo man sich dann schon fragen sollte ob dann nicht gleich die aktuellere Version (nicht LTS) angemessener ist.
Ich sehe da gar nicht mehr so das große Problem drin in den Zyklen und Aktualität einiger Pakete. Klar, wine und ein paar andere sind da noch so Spezialfälle,.. da gehts manchmal nicht anders als in Version xx.xx.
Aber bei all den Fortschritten denke ich wird es nicht lang dauern dann gibts auch eine grafische simple Oberfläche um von anderen Sites Pakete zu beziehen (sources.list usw). Da sehe ich auch die Zukunft drin: Hersteller veröffentlichen in Quellcode und in kompilierter Form. Der Downloadlink des letzteren entspricht dem adden der source in die sources.list und einem darauf folgenden ausgeführten apt-get install neues-paket. Leider hat daran noch nie jemand gedacht wie es scheint bzw. es nicht umsetzen können. brainstorm ist ja zum Glück erfunden worden.
Wer bei bei Debian oder SuSE aus deren normalen Repositories Software installiert, der hat sicher kaum Schwierigkeiten.
Aber wenn man etwas abseits des Distro-Wegs wandeln möchte, dann geht das Versionsfetischismus bei den Abhängigkeiten los.
Entweder man hat eine zu alte Library auf dem System - welche oftmals garkeine Probleme machen würde - oder, was noch nervender, man hat eine zu neue.
"""Besonders diese (sorry) kranken Paketabhängikeitsprüfungen, die meisten nur unnütze Müllmeldungen herausgeben"""
ich habe bei ubuntu festgestellt, das seit dapper nicht mehr so ist wie mal war bzw. wie warty oder hoary.... schade eigentlich.
aber, wenn Slakware besser sein soll, wie du behauptest...? und auch 64Bit existiert und keine probleme macht (flash ist mir nicht wichtig) dann teste ich einfach diese Distro.
> was du mit Slackware besser erledigen kannst.
VDR 1.6.0
In Ubuntu (einer von den Ubuntu Jüngern so genannten LTS Version!) ist ne Beta 1.5.irgendwas dabei.
Jetzt kompilier mal VDR unter Slackware (snip, _sehr_ einfach) und unter Ubuntu *lol*
Besonders schlimm find ich es, wenn partout kein Update rauskommt und ein unbedingt benötigtes Feature nur in einer neueren Version vorhanden ist. Einmal ist es mir sogar passiert, daß sich bei Ubuntu über zwei Versionen hinweg rein garnix getan hat (amavisd-new).
Da bin ich dann wieder zu Fedora gewechselt als Paketausprobierdistribution. Arbeitstier ist Slackware.
> Nenn doch mal ein Beispiel
Ein weiteres: ACPI bzw. Suspend 2 RAM. Unter Ubuntu und/oder Fedora funktioniert es nicht, da die Kernel in dieser Hinsicht in welcher Richtung auch immer gepatched sind.
Unter Slackware mit dem Vanilla-Kernel funktioniert Suspend 2 RAM einwandfrei (Thinkpad R51), sogar die WLAN Verbindung ist adhoc wieder verfügbar (madwifi).
> Nenn doch mal ein Beispiel
Ein drittes:
Ubuntu und Fedora ist schon ganz nett wenn man auf Entdeckungsreise bezüglich Pakete ist. Hat man aber "seine" Anwendungen beisammen, sind die entweder
a) bei Slackware dabei
b) sehr leicht von Hand zu pflegen
Unter Slackware mit dem Vanilla-Kernel funktioniert Suspend 2 RAM einwandfrei (Thinkpad R51), sogar die WLAN Verbindung ist adhoc wieder verfügbar (madwifi).[/quote]
Hmm, dann leistet Stefan Lippers-Hollmann mit seinen Kerneln hervorragende Arbeit. Unter menen IBM TP R51 läuft alles, sidux sei dank :-)
Beste Grüße,
Holger
Suche doch in einer Slackware-Distro nach diesen unseligen "dev"-Paketen.
Na, wo sind sie denn?
Ich meine halt nur, dass Slackware u.a. in dieser Hinsicht einfacher zu bedienen ist, trotz "Paketabhängigkeiten".
Ausserdem sind .spec und debian/* sehr flexibel (z.B. im Bezug auf Makros). Ich erstelle täglich Debianpakete und habe mir nie gedacht "Ach wär das toll, Slackwares Pkgtools auf Debian zu haben". Nur weil es dir gefällt ist es noch lange nicht besser. Höchstens genauso gut.
> Nur weil es dir gefällt ist es noch lange nicht besser. Höchstens genauso gut.
>
Das sehen Slackware-User sicher genau anders herum.
Debians dpkg ist als Paketmanagementtool sicher sehr mächtig, wenn du allerdings Pakete nach Maintainer Guidelines bauen willst, ist der Aufwand exorbital größer, der effektive Mehrwert jedoch eher gering.
Viele Grüße
Marcus
dh_make erstellt alle wichtigen dateien. (control, changelog, rules, et cetera), das anpassen derer und das hinzufügen der postinst/rm oder preinst/rm skripte (fall benötigt) dauert dann noch knapp 1 - 3 minuten (und dass muss nat. nicht bei jedem update wiederholt werden).
Nunja ob 1 - 3 minuten exorbitant sind ...
>> wenn du allerdings Pakete nach Maintainer Guidelines bauen willst
Mach ich ... zu 95%
Wenn man damit ein Paket baut, landen die Dateien dort, wo Upstream sie hinsetzen wollte, Dokumentation möglicherweise in /usr/doc. Das ist gemäß Maintainer-Guidelines aber z.B. verboten. Zudem müssen dist-upgrades von den letzten beiden Versionen (=stable+testing) reibungslos funktionieren.
Wenn man darauf Wert legt, sollte man auch kein Slackware nehmen. Teilweise ist es aber in Slackware einfacher, selbst erstellte Pakete einzupflegen, die mit bestimmten Optionen übersetzt wurden.
duncan
Mit apt-get stehst Du im Zweifelsfall total auf dem Schlauch, weil da nix im Repository ist.
Woher soll der Build Service wissen, welche Abhängigkeiten ein Programm hat? Um das SPEC-File überhaupt schreiben zu können, musst du erst einmal selbst herausfinden, welche BuildDependencies notwendig sind.
Und Binärpakete als .tar.gz bekommst du doch fast nirgends.
Jedes Debian-Paket enthält die eigentlichen Dateien als Tarball. Und Debian-Pakete gibts genug.
Das einzige was ich mir vorstellen kann ist das die alsa Mixer Einstellungen nicht definiert waren (musste man bis einschließlich Slackware 12.1 noch manuell tun). Spätestens seit 19.3. ist das in Current aber auch Geschichte:
"Set reasonable volume defaults if there are none in /etc/asound.state."
Viele Grüße
Marcus
Nach anmelden per KDM wurde mir dann artsd entgegen geballert. ;)
Ist halt noch (fast verfrühte laut PV) RC.
Darum kann man in jedem Forum Berichte von Leuten finden, die auf irgendeine Distribution schimpfen und dann jede Menge Protestierer auf den Plan rufen, die das bestreiten.
Ich habe hier einen 3 1/2 Jahre alten Rechner, der mehrere Slackware- Versionen problemlos verdaut hatte, aber unter Slackware 12 dann öfter mal einfror. Da habe ich dann auf die 12er geschimpft und die erst mal nicht auf zwei anderen Rechnern installiert.
Irgendwann war es aber doch so weit, und - siehe da - auf den beiden anderen Rechnern gab es keine Probleme. Den Problemrechner habe ich dann auf Slackware-current gebracht, und die Probleme waren dann dort auch weg.
Ich vermute, daß in Slackweare 12 ein Entwicklungsstand des Kernels oder in der Xorg- Pakete Treiber für meine Hardware enthalten waren, die zu dem Zeitpunkt instabil waren.
Solche Probleme sollte man nicht verallgemeinern und zum allgemeinen Qualitätsstand der Distribution erklären.
Ach ja: noch was: sicherlich ist Slackware nicht so umfangreich wie alle Distributionen; da es aber z.B. keine separaten devel- Pakete gibt und die Pakete nicht so fein geschnitten sind wie z.B. bei Debian oder Ubuntu, darf man nicht direkt 500 Pakete zu 20000 ins Verhältnis setzen.
Und wie C't früher immer so schön bei Apple- Besprechungen schrieb: bei Apple gibt es für viele Einsatzbereiche nur ein Programm, aber das deckt alle Wünsche ab.
Aber vielleicht macht sich ja noch mal jemand ran und entwickelt wieder
aus Slackware ein zweites SuSE, so wie es damals war?
Schlecht wärs jedenfalls nicht.
Ansonsten finde ich es erfreulich, dass es Slackware noch gibt. Ist zwar keine
Distri, die man so ohne weiteres handhaben kann, aber dafür gibts wenigstens nicht
so ein elitäres Gehabe und soviel Knatsch, wie bei der bekannten anderen Distri,
deren Namen ich hier garnicht nennen will, der aber mit "D" anfängt.
Und wenn Slackware erstmal läuft, dann läuft es jedenfalls auch sehr stabil und sicher.
Sebalin.
Halt Moment... dann wären wir ja (sehen wir mal vom Gerüst ab) bei einem Ubuntu oder gar Mandriva! ;)
Wie weiter oben geschrieben scheint man ja dauernd Probleme mit alten oder zu neuen libs zu haben (ich schein da wohl ne Ausnahme zu sein). Sofern man sich etwas mit dem System auseinandersetzt (was bei Slack Zwang ist) versteht man auch sehr schnell dass man in Ubuntu einfach Pakete bauen kann, zB mit checkinstall.
Slackware funktioniert hervorragend ohne so etwas.
Um einmal etwas ketzerisch zu fragen:
Wo sind denn eigentlich die Windows-Repositories?
"It follows simple Slackware-like design concepts"...
Ich kann sie allen wärmstens empfehlen.
Er meint sicherlich das Paketformat
Wurde -glaube ich- nach SuSE 4.3 von tgz nach rpm gewechselt
Das wird aber - das ist meine persönliche Meinung - durch mindestens zwei Vorteile aufgewogen:
1. Von Slackware-Seite her gibt es keinerlei künstliche Beschränkungen, was den Anwendungsbereich der Updates anbelangt.
Bsp.: Dieses Java-Update für Slackware 12.0:
http://www.slackware.com/security/
viewer.php?l=slackware-security&y=2007&m=slackware-security.486841
Dieses Java läuft nicht etwa nur auf Slackware 12.0 oder 11.0, nein, es läuft auf jeder glibc-basierten Slackware-Distro:
"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."
Das ist etwa so, als würde Novell mit den neuen Java-Aktualisierungen für OpenSuse 10.3 ein entsprechend aktualisiertes Java in der gleichen Version "spendieren", das noch auf Suse 6.0 lauffähig wäre.
2. Slackware unterstützt seine Veröffentlichungen sehr, sehr lange.
Ein Beispiel ist dieses libpng-Update von Ende 2007:
http://www.slackware.com/security/
viewer.php?l=slackware-security&y=2007&m=slackware-security.520323
"New libpng packages are available for Slackware 8.1, 9.0, 9.1, 10.0, 10.1,
10.2, 11.0, 12.0, and -current to fix security issues."
Slackware 8.1 wurde im Juni 2002 veröffentlicht.
Selbst jetzt gibt es noch Aktualisierungen dafür.
Slackware kennt keine Aktualisierungsbeschränkungen auf 18 oder 24 Monate.
Für einen normalen Anwender ist das schlichtweg "Wahnsinn", d.h. wahnsinnig gut.
[quote]Und wenn Slackware erstmal läuft, dann läuft es jedenfalls auch sehr stabil und sicher.[/quote] Oh ja, hier spricht der Profi ;-)
Ich fand es noch schlimmer als Slackware-current, denn bei Arch hatte ich es ein- oder zweimal, daß der Paketmanager das Update abbrach und wegen irgendwelcher kaputter Paketabhängigkeiten herumheulte. Das löste sich dann ohne eigenes Zutun durch Abwarten, aber hat mich doch ziemlich abgeschreckt.
Größere Probleme hatte ich bei Arch noch nicht. Und da ich in der letzten Zeit vor Arch sowieso Slackware-current hatte gab es auch keinen so großen Unterschied bei den Downloads.