BlueZ 5 wiederum hat die direkte Unterstützung von ALSA aufgegeben und erzwingt nun PulseAudio.
Ich verstehe einfach nicht warum man so etwas machen sollte. Ich gehe einfach mal davon aus, dass die API von Alsa stabil ist. Es bedeutet also keinen Aufwand Alsa, nachdem es schon drin war, beliebig lange zu unterstützen.
Wie machen die das eigentlich unter Android? Wird da auch PA verwendet?
Ich habe bluez 5 auf dem System und Pulseaudio ist nicht installiert. Ich nutze allerdings Gentoo. Es gibt dort aber kein USE Flag um PA / Alsa zu aktivieren.
Es freut mich wirklich sehr, das es neue Version gibt. Ich hatte schon allmählich die Befürchtung gehabt, das Slackware langsam eingeschlafen sein soll. Es wäre wirklich Schade um so ein gutes System.
So gut ist dieses System nun auch wieder nicht. Ich denke dabei vor allem an die allzu oft ausbleibenden Kernel-, Xorg- und Glibc-Updates.
Hinzu kommt das Fehlen einer offiziellen Update-Politik. Es ist überhaupt nicht klar, welche Releases in welcher Form wie lange noch zur Gänze unterstützt werden. So gibt es zur Zeit aktuelle Firefox- und Thunderbird-Updates nur für Slackware 14.1 und Slackware-Current.
Slackware ist gut, hat aber somit die eine oder andere sehr gravierende "Update-Schwäche".
Eine weitere Schwäche dürfte die Kompliziertheit der Umstellung von Slackware auf die jeweils eigene nationale Sprache für Newbies und schon etwas fortgeschrittene Nutzer sein, die bestimmt gleich zu anfangs massenweise Wechselwillige und Sympathisanten vergrault.
Slackware ist IMO gut und irgendwie doch "krude". Die aus den obigen Schwächen zu folgernden Ratschläge interpretiere ich dann in etwa so: Wenn Slackware keine Updates liefert, dann bau Dir selbst welche und wenn Du z.B. die Umstellung von Slackware auf Deutsch nicht schaffst, dann ist Slackware wohl noch etwas zu schwierig für Dich.
Es hängt natürlich von der Definition von "gut" ab. Die Update-Politik machf m.E. durchaus Sinn. Desktop-User dürften wohl kaum etwas älteres als 14.1 nutzen, während andere Pakete, die auf Server- Systemen laufen könnten bis runter zu Slackware 13.0 aktualisiert werden
Ich denke das unter Slackware das gleiche ist, wie zB. Unter Debian auch. Das Projekt lebt von mitmachen. Wenn unter Debian ein Packet keinen Entwickler findet, wird es schlicht fallen gelassen. Mitten im Release verschwinden auch unter so populären Distribution wie Debian, plötzlich Programme.
Unter Slackware ist das auch keine Ausnahme. Solange sich ein Unterstützer findet, gibt es Updates.
Slackware würde ich persönlich auch für den Desktop wenig empfehlen. Das würde ich persönlich für jedes Linux-System aber sagen, nur aus persönlichen Meinung heraus, das für mich Linux als Desktop wenig taugt. Ist nur meine Meinung und teilt sicher nicht jeder.
Was Slackware aber auszeichnet, und ich sehr Schätze, ist die Charakterisierung "Mach was du willst, du musst es schließlich besser Wissen." Das ist mMn. Viel besser als das "Wir wissen besser, was du brauchst.", vieler anderen Distributoren wie Ubuntu,Debian, SuSE oder RedHat.
Natürlich überspitzt gesagt und ich meine die Pakete-Manager. Als OSX und Windows User, bin ich es gewohnt, Software zu installieren die ich brauche oder haben will. Ein Pakete-Manager erlaubt mir, Software zu installieren und zu Pflegen. Aber eben nur was in ihrer Datenbank ist und das ganze ist umso schwieriger wenn viele Pakete auch noch (unnötiger Weise) atomisiert vorliegen.
Das Problem sehe ich somit überall, privat wie beruflich. Unser Linux-Admin muss immer wieder erklären, warum wir auf bestimmte Programme und Dienste nicht wechseln können, und die Angestellten das nicht verstehen und erstmal verzichten , weil es zB. unter Windows ganz einfach geht.
Als Entwickler braucht man zB. eine neuere PHP Version. Unter Windows einfach das benötigte installiert und los gelegt. Sagt man der Administration, das man die selbe Version auch auf Linux braucht, bekommt man gesagt das es nicht so einfach geht. Aus persönlichen Erfahrungen kann ich das auch bestätigen.
Unter Slackware werden die Pakete weder atomisiert und es ist einfacher dafür ein Paket zu erstellen. Ich kann selber Pakete erstellen und das mache ich auch. Will ich PHP 5.6 baue ich mir das, oder PHP 5.5, auch das geht. Der Aufwand ist unter Slackware weniger als vergleichsweise auf Denian.
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.
Also ich kann nur für Debian und CentOS sprechen, aber mehrere PHP Versionen nebeneinander ist doch recht locker realisiert. Kannst du auch in der Praxis bei Massenhoster dir anschauen, ist alles kein Ding. Welche PHP Version genutzt wird, kannst du ja z.B. per .htaccess festlegen. Hm.. Hier aus der Ferne beurteilt machen deine Admins scheinbar etwas falsch.
War natürlich vertretend für viele andere Pakete. Genauso könnte ich auch Qt nennen. Das war zumindest bei mir unter Debian mit sehr hohem Aufwand verbunden. Unter Slackware existiert dafür ein Paket und läßt sich spielend auch auf einem alten Slackware aktualisieren. Bei anderen Distros sucht man dafür externe Repos.
Aber vielen Dank für den Tipp mit mehreren PHP versionen. Leite ich ganz einfach weiter
Ich weiss um die Schwächen, die Du geschildert hast, bin aber trotzdem seit fast fünfzehn Jahren Slacker, weil das Grundsystem auf Einfachheit und Beständigkeit ausgelegt ist.
Wenn man sich ein wenig eingearbeitet hat, kann man sehr lange davon zehren, weil sich am Grundsystem (trotz aktueller Software) nur wenig ändert.
Um in der Tiefe von Distributionen wie Debian oder Ubuntu herumzuwurschteln oder eigene Softwarepakete zu bauen, braucht man wesentlich mehr Kenntnisse, und die veralten auch schneller.
Slackware wird durchaus upgedated. Die Updatefrequenz ist geringer als bei anderen Distributionen, aber wenn CVEs existieren, gibt es Updates.
Die Updatepolitik anderer Distributionen ist meiner Meinung auch nicht so viel besser. Z.B. Ubuntu garantiert nur für sein Kernsystem und nicht für das Zeug in "universe", und Debian ist neulich ins Gerede gekommen, weil bei einem größeren Paket (ich glaube, es war PHP) laut Debian-Bugtracker monatelang jede Menge sicherheitskritische Bugs offen waren. Da wiegt sich vielleicht mancher in falscher Sicherheit, weil zwar häufige Updates reinkommen, aber eben nicht alles upgedatet wird.
Wie machen die das eigentlich unter Android? Wird da auch PA verwendet?
Ich habe bluez 5 auf dem System und Pulseaudio ist nicht installiert. Ich nutze allerdings Gentoo. Es gibt dort aber kein USE Flag um PA / Alsa zu aktivieren.
Silvio
Ich gehe davon aus, dass dann die Unterstützung für Audio-bezogene Dinge einfach fehlt...
Offizielle Images gibt es nicht.
Das war mal so, hat sich aber inzwischen geändert:
ftp://ftp.slackware.com/pub/slackware-iso/
Allerdings gibt es da nur die jeweiligen stabilen Versionen, während ftp.slackware.no zusätzlich wöchentliche ISOs aus dem current-Zweig baut.
Es freut mich wirklich sehr, das es neue Version gibt. Ich hatte schon allmählich die Befürchtung gehabt, das Slackware langsam eingeschlafen sein soll. Es wäre wirklich Schade um so ein gutes System.
So gut ist dieses System nun auch wieder nicht. Ich denke dabei vor allem an die allzu oft ausbleibenden Kernel-, Xorg- und Glibc-Updates.
Hinzu kommt das Fehlen einer offiziellen Update-Politik. Es ist überhaupt nicht klar, welche Releases in welcher Form wie lange noch zur Gänze unterstützt werden. So gibt es zur Zeit aktuelle Firefox- und Thunderbird-Updates nur für Slackware 14.1 und Slackware-Current.
Slackware ist gut, hat aber somit die eine oder andere sehr gravierende "Update-Schwäche".
Eine weitere Schwäche dürfte die Kompliziertheit der Umstellung von Slackware auf die jeweils eigene nationale Sprache für Newbies und schon etwas fortgeschrittene Nutzer sein, die bestimmt gleich zu anfangs massenweise Wechselwillige und Sympathisanten vergrault.
Slackware ist IMO gut und irgendwie doch "krude". Die aus den obigen Schwächen zu folgernden Ratschläge interpretiere ich dann in etwa so: Wenn Slackware keine Updates liefert, dann bau Dir selbst welche und wenn Du z.B. die Umstellung von Slackware auf Deutsch nicht schaffst, dann ist Slackware wohl noch etwas zu schwierig für Dich.
Es hängt natürlich von der Definition von "gut" ab. Die Update-Politik machf m.E. durchaus Sinn. Desktop-User dürften wohl kaum etwas älteres als 14.1 nutzen, während andere Pakete, die auf Server- Systemen laufen könnten bis runter zu Slackware 13.0 aktualisiert werden
Ich denke das unter Slackware das gleiche ist, wie zB. Unter Debian auch. Das Projekt lebt von mitmachen. Wenn unter Debian ein Packet keinen Entwickler findet, wird es schlicht fallen gelassen. Mitten im Release verschwinden auch unter so populären Distribution wie Debian, plötzlich Programme.
Unter Slackware ist das auch keine Ausnahme. Solange sich ein Unterstützer findet, gibt es Updates.
Slackware würde ich persönlich auch für den Desktop wenig empfehlen. Das würde ich persönlich für jedes Linux-System aber sagen, nur aus persönlichen Meinung heraus, das für mich Linux als Desktop wenig taugt. Ist nur meine Meinung und teilt sicher nicht jeder.
Was Slackware aber auszeichnet, und ich sehr Schätze, ist die Charakterisierung "Mach was du willst, du musst es schließlich besser Wissen." Das ist mMn. Viel besser als das "Wir wissen besser, was du brauchst.", vieler anderen Distributoren wie Ubuntu,Debian, SuSE oder RedHat.
Natürlich überspitzt gesagt und ich meine die Pakete-Manager. Als OSX und Windows User, bin ich es gewohnt, Software zu installieren die ich brauche oder haben will. Ein Pakete-Manager erlaubt mir, Software zu installieren und zu Pflegen. Aber eben nur was in ihrer Datenbank ist und das ganze ist umso schwieriger wenn viele Pakete auch noch (unnötiger Weise) atomisiert vorliegen.
Das Problem sehe ich somit überall, privat wie beruflich. Unser Linux-Admin muss immer wieder erklären, warum wir auf bestimmte Programme und Dienste nicht wechseln können, und die Angestellten das nicht verstehen und erstmal verzichten , weil es zB. unter Windows ganz einfach geht.
Als Entwickler braucht man zB. eine neuere PHP Version. Unter Windows einfach das benötigte installiert und los gelegt. Sagt man der Administration, das man die selbe Version auch auf Linux braucht, bekommt man gesagt das es nicht so einfach geht. Aus persönlichen Erfahrungen kann ich das auch bestätigen.
Unter Slackware werden die Pakete weder atomisiert und es ist einfacher dafür ein Paket zu erstellen. Ich kann selber Pakete erstellen und das mache ich auch. Will ich PHP 5.6 baue ich mir das, oder PHP 5.5, auch das geht. Der Aufwand ist unter Slackware weniger als vergleichsweise auf Denian.
Darum mag ich Slackware auch so sehr
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.
Also ich kann nur für Debian und CentOS sprechen, aber mehrere PHP Versionen nebeneinander ist doch recht locker realisiert. Kannst du auch in der Praxis bei Massenhoster dir anschauen, ist alles kein Ding. Welche PHP Version genutzt wird, kannst du ja z.B. per .htaccess festlegen. Hm.. Hier aus der Ferne beurteilt machen deine Admins scheinbar etwas falsch.
War natürlich vertretend für viele andere Pakete. Genauso könnte ich auch Qt nennen. Das war zumindest bei mir unter Debian mit sehr hohem Aufwand verbunden. Unter Slackware existiert dafür ein Paket und läßt sich spielend auch auf einem alten Slackware aktualisieren. Bei anderen Distros sucht man dafür externe Repos.
Aber vielen Dank für den Tipp mit mehreren PHP versionen. Leite ich ganz einfach weiter
Ich weiss um die Schwächen, die Du geschildert hast, bin aber trotzdem seit fast fünfzehn Jahren Slacker, weil das Grundsystem auf Einfachheit und Beständigkeit ausgelegt ist.
Wenn man sich ein wenig eingearbeitet hat, kann man sehr lange davon zehren, weil sich am Grundsystem (trotz aktueller Software) nur wenig ändert.
Um in der Tiefe von Distributionen wie Debian oder Ubuntu herumzuwurschteln oder eigene Softwarepakete zu bauen, braucht man wesentlich mehr Kenntnisse, und die veralten auch schneller.
Slackware wird durchaus upgedated. Die Updatefrequenz ist geringer als bei anderen Distributionen, aber wenn CVEs existieren, gibt es Updates.
Die Updatepolitik anderer Distributionen ist meiner Meinung auch nicht so viel besser. Z.B. Ubuntu garantiert nur für sein Kernsystem und nicht für das Zeug in "universe", und Debian ist neulich ins Gerede gekommen, weil bei einem größeren Paket (ich glaube, es war PHP) laut Debian-Bugtracker monatelang jede Menge sicherheitskritische Bugs offen waren. Da wiegt sich vielleicht mancher in falscher Sicherheit, weil zwar häufige Updates reinkommen, aber eben nicht alles upgedatet wird.