Das finde ich ehrlich gesagt alles wenig überraschend. Man darf halt doch immer nur soviel erwarten wie man auch bezahlt ... Zumal man Ubuntu zu gute halten muss, dass der eingeschränkte Support (nur main Repo) nie verheimlicht wurde (wenn auch nicht besonders offen kommuniziert). Ich frage mich hingegen, welche Alternativen das sind nach denen man sich umschauen sollte. Ob z.B. Red Hat einen besseren Langzeit-Support von Multimedia-Paketen bietet, weiß ich nicht. Die meisten kommerziellen Linux Distributionen sind ja auf Unternehmen (Server) ausgerichtet. Ist das vlt. sogar eine Marktlücke? Ich meine viele "Linux-Fans" sind doch inzwischen raus aus Schule und Uni und wären bereit alle 5 Jahre 100 € (so z.B. der Preis für nicht Upgrade Windows 10) für ein Betriebssystem auszugeben.
Als Desktopuser würde ich auch ein Rolling Release setzen. Mit Arch bin ich bisher sehr gut gefahren, leider ist es viel zu kompliziert für den normalen User.
Von Anon Y. Mouse am Mo, 25. April 2016 um 10:24 #
Es muss ja nicht gleich rolling sein aber so 1mal im jahr auf die neueste version updaten sollte ja drin liegen, bei xp gabs ja auch ab und an ein sp...
Bei diversen distries klappt das mit den updates mittlerweile ja auch ganz ok. Bei meiner mutter löse ich normalerweise das update auf die nächste version aus esse ein feines abendessen und schaue zum schluss noch schnell ob alles ok ist.
Bei meinem vater mit win 10/10 xyz hat das etwas länger gedauert bis alles wieder auf dem letzten stand war...
Es gibt ja jedes halbe Jahr eine neue Ubuntu Version. Der Artikel kritisiert nur die Ubuntu LTS bei Benutzung von Software aus anderen als main Repository. Und empfiehlt dann alternative Distributionen zu verwenden.
Andere Möglichkeit ist immer die aktuellste Ubuntu Version zu verwenden.
Fertiggeräte kommen oft mit den LTS Versionen. Dort ist man auch gerne mal auf LTS beschränkt, da mit neueren Versionen die Anpassungen des Herstellers verloren gehen. Dieses Problem hatten/haben zum Beispiel die Dell Geräte. Beim neusten Gerät soll es kein Problem mehr sein, aber bei denen davo schon.
Dann kommen noch Projekte wie Limux oder Mint. Diese bauen auch auf LTS auf, und sind somit alle verwundbar.
Warum nicht rolling? Ubuntu hat mit Snaps ja inzwischen auch ein Format, mit dem Anwendungen Isoliert alles mitbringen was sie brauchen. Dann könnte man seine Anwendungen direkt aus dem Upsream beziehen, wie unter Windows dann auch. Wünschenswert wäre dann ein moderiertes Repository das alle Snaps bereitstellt und vielleicht auch mit älteren Versionen. Das könnte dann sogar Distributionsunabhängig sein.
PS: Bei Windows ist das Problem ein anderes. Wobei Problem hier etwas weit gegriffen ist. Du musst theoretisch nur alle 10 Jahre ein OS Upgrade machen. Viele machen wohl nie eins, da sie vorher einen neuen Rechner kaufen. Dort müssen sich die Anwendungen nur darum kümmern, sich selber auf dem aktuellen Stand zu halten.
Zwei meiner Bekannten nutzen z.B. noch immer Geräte mit Windows Vista. Das Upgrade ist bei ihnen nicht nötig, da sie sich bald eh neue Geräte zulegen wollen. Weniger wegen dem OS, sondern viel mehr um leistungsfähigere Hardware zu bekommen bzw längere Akkulaufzeiten.
1. Ich hab im Urlaub meinen Laptop mit Arch + Gnome 3.18 und ein Dumb Phone mit. Kriege per Email die Boardkarte, die ich ausdrucken soll. Meine Freundin hat nen schicken neuen Netzwerkdrucker. Davor hatte ich Debian Stable und es klinkte sich ohne Probleme in das Ding ein. Mit Arch keine Chance. Mein Kumpel, auch da zu Gast, nimmt sein billiges Android Phone, das sich binnen 10s da einklinkt und meine Datei druckt.
2. Selber Laptop, Antegros. Wir wollen einen Film gucken, HDMI geht auf einmal nicht. Geht sonst auf dem älteren (!) Debian Stable oder Ubuntu LTS (da noch 14.04). Hab ATI, also läuft alles schön über Mesa.Nach viel Gefrickel macht es dann komische Farbeffekte wenn die Szene im Film dunkler oder heller wird.
3. Arch. Selber Laptop. Muss unbedingt Plakate die ich auf Inkscape gemacht habe als PDF speichern und zum Drucken schicken. Klappte sonst mit Debian Stable prima. Hier nicht. Inkscape stürzt dauernd ab. Notlösung: Inkscape auf dem Windows 7 Bürorechner installieren. LOL
Könnte bis morgen weitererzählen...
Also, es ist schade, dass Ubuntu LTS wenige Pakete unterstützen kann. Könnten sie doch bloß Entwicklerzeit in den Desktop stecken als in die Telefone... Tja... Debian Stable ist dann für mich da. Und so Projekte wie xdg-app oder auf Ubuntu Snap liefern dann eventuell die frischen Pakete, die man unbedingt braucht.
Arch hat doch nur den Zweck, das man ständig was zum Basteln hat. Meiner Meinung nach kann man es nicht für Dinge einsetzen auf die man angewiesen ist.
Arch hat doch nur den Zweck, das man ständig was zum Basteln hat. Meiner Meinung nach kann man es nicht für Dinge einsetzen auf die man angewiesen ist.
Leute, was macht ihr alle? Mein Arbeitsplatzrechner in der Firma: Arch Linux seit 3+ Jahren. Muß laufen, Basteln ist für Wochenenden zuhause. Genau einmal ein Problem gehabt: Morgens Systemaktualisierung durchgeführt, anschließend wollte mein Desktop nicht mehr. Desktop neugebaut (bin selbst der Paketmaintainer eines externen Repos - insofern hat es genau den richtigen getroffen), Paket hochgeladen, nochmal aktualisiert und gut. Man sollte natürlich die Ankündigungen auf der Netzseite lesen UND _regelmäßig_ aktualisieren. Wer für das eine oder das andere zu faul ist, der kann schon mal ins Stolpern kommen. Wer meint, auf beides verzichten zu können, der muß mit Schmerzen leben - oder eben ohne Arch.
Zugegeben: LibreOffice kann ganz schön nerven. Aber wenn die neuste Version mal wieder so kaputt ist, daß sie effektiv unbrauchbar ist, dann gibt es ja noch libreoffice-still. Ansonsten: Mit Arch KANN man ganz nett basteln. Muß man aber nicht. Ganz normal arbeiten geht durchaus auch. Sogar recht gut.
Wer für das eine oder das andere zu faul ist, der kann schon mal ins Stolpern kommen.
Ich fände es schön, wenn die Diskussion sachlich bleiben könnte. Ersetze doch einfach mal "faul" gegen "wer andere zeitliche Prioritäten" hat.
Mit Familie oder echter "Crunch-Time" im Job haben selbst Computer-Interessierte ganz schnell keine Zeit mehr dafür, sich jeden Morgen mit den Updates zu beschäftigen.
> Ersetze doch einfach mal "faul" gegen "wer andere zeitliche Prioritäten" hat.
So gerne ich Deinen Formulierungsvorschlag annahmen würde: Nein.
Unterschiedliche Distributionen haben unterschiedliche Voraussetzungen. Die beiden Hauptvoraussetzungen für einen reibungslosen Betrieb sind bei Arch: „Halte dein System aktuell“ und „wisse, was du tust“. Ersteres ist dem Rolling-Release-Modell geschuldet, bzw. der Community-Ausrichtung bei Arch: Es ist niemand da, der einen funktionalen Updatepfad auf die aktuellste Version für sechs Monate alte Installationen sicherstellt. Für die zweite Voraussetzung gibt sich Arch alle Mühe, ein wirklich gutes und umfangreiches Wiki zu pflegen.
Natürlich: Es hat nicht jeder die Zeit, sich damit zu beschäftigen. Ich habe selbst Familie und weiß, wie rar Freizeit ist. Das heißt aber ganz einfach: Arch ist nicht für jeden die richtige Distri. Was aus meiner Sicht auch nicht schlimm ist. Ich schätze z.B. auch die Flexibilität von Gentoo. Aber wenn ich ehrlich zu mir bin, dann könnte ich mir z.B. für meine Arbeitsstation die Kompilierzeiten für Updates von Kernel, Kompiler & Co. gelinde gesagt nicht leisten. Damit scheidet Gentoo als Möglichkeit aus.
Was meine Formulierung mit der Faulheit anging: Ein Kollege hier hat sich auch ein Arch aufgesetzt, da ihm der Minimalansatz des Systems zusagte. Bei ihm hakt es immer mal wieder mit dem System und es machen Programme Probleme, die bei mir einwandfrei funktionieren - obwohl wir die gleichen Paketversionen haben. Wenn etwas kaputt ist und ich ihn frage, ob er gerade aktualisiert hat, ist die Antwort zu fast 100%: „Ja“. Da er sich für Arch entschieden hat (und die Voraussetzungen kannte), muß er mit meinem Vorwurf der Faulheit leben können (kann er auch).
Das heißt natürlich nicht, daß ich Leuten, die Arch wegen der genannten Voraussetzungen ausschließen, Faulheit unterstelle. Es gibt viele gute Gründe, sich gegen Arch zu entscheiden. Was mir aber wichtig ist: Es ist einfach unnötig, daß viele Leute, für die Arch vielleicht passen würde, es sich gar nicht erst ansehen, weil sie überall lesen, daß Rolling-Release immer wieder alles kaputt mache. Das kommt ohne Frage vor, wenn man die Regeln verletzt. Ganz überwiegend aber auch nur dann.
Es ging hier aber ursprünglich darum, auch Rolling Releases statt der bishering Ubuntu Update Politik zu benutzen (siehe Originalpost). Den Vergleich zu Arch (aber auch zu Antergos, u.ä. Distri, die auf Arch aufbauen, sich aber an einfache Benutzer richten) habe ich gemacht, um meine Erfahrnungen mit solchen Systemen mitzuteilen. Ich bin zu faul dafür, diese zu pflegen. Und ich denke mal, der Durchschnitts-Ubuntu-User ist es auch. Rolling Release ist für mich also kein guter Ersatz und Half-Rolling so wie Suse oder Sabayon/Chakra/Antergos sind genauso buggy für mich.
Das ist, wie gesagt. völlig legitim und ich habe auch keine Probleme damit. Arch ist nicht für jeden und wer keine Zeit/Lust hat, sich regelmäßig um ein paar Kleinigkeiten zu kümmern, der wird Probleme haben. In der Hauptsache habe ich Einspruch eingelegt, weil sich viele Kritiken an Arch so lesen, als seien die Probleme regelrecht „gottgegeben“ und praktisch unausweichlich.
Dann nächstes mal genauer lesen, denn im Originalpost erwähnte ich auch Antergos.
Aber wer weiß, vielleicht kriegen die das noch hin, dass ich auch ne half rolling Distro ohne viel Mühe einsetzen kann. Es ist noch eine sehr junge Distro.
Ich mache nix. Aber woher soll ich wissen, dass Cups oder die Treiber spontan abkacken? Als normaler User hab ich dazu leider auch nicht die Zeit, das alles nachzulesen. Und davor hätte ich Angst, wenn Sachen in Anfängerdistri rolling werden.
Arch hat doch nur den Zweck, das man ständig was zum Basteln hat. Meiner Meinung nach kann man es nicht für Dinge einsetzen auf die man angewiesen ist.
Mit Arch KANN man ganz nett basteln. Muß man aber nicht. Arch Linux seit 3+ Jahren
Nope.. aber in ein paar Jahren wirst es von alleine verstehen.
Nach einem pacman -Syu mag das System zwar i.O. aussehen aber die Regressionen prasseln dir jeweils ganz langsam ins Gesicht.. meistens dann, wenn man sie am wenigsten brauchen kann.
> Nope.. aber in ein paar Jahren wirst es von alleine verstehen.
Hui, wie viele Jahre sind denn nötig, bis Arch einen beißt? Möglicherweise werde ich es allerdings nicht erleben, denn wenn ich den Rechner neu aufsetzen würde, würde ich heute nicht mehr Linux nehmen, sondern wahrscheinlich FreeBSD (ausgezeichnete ZFS-Unterstützung, ausgereiftes Jailsystem, Bhyve, ...). Im Zuge des Umstieges auf Systemd hat Arch ja leider auch sein hauptsächliches Alleinstellungsmerkmal, die zentralisierte Konfiguration, aufgegeben, was ich noch immer für einen unklugen Zug halte.
> Nach einem pacman -Syu mag das System zwar i.O. aussehen aber die Regressionen prasseln dir jeweils ganz langsam ins Gesicht..
Es kann ganz gut sein, daß ich vielen Problemen aus ganz anderen Gründen nie begegnet bin: Ich bin - zumindest auf der Arbeit - Minimalist. Ob KDE oder irgendwelche aufgeblähten Programme unter Arch leicht kaputtgehen, weiß ich nicht. Wo es irgend geht, setze ich auf Programme, wo upstream auf Stabilität und Korrektheit wertgelegt wird (z.B. die suckless-Projekte). Arch ist bewußt nahe am Upstream und wenn da geschlampt wird, kommt da bestimmt mal was durch - wie bereits erwähnt, ist Libreoffice so ein Programm. Leider aber eines, zu dem es kaum eine brauchbare Alternative gibt.
Für mich persönlich: Weil es immer wieder mal Probleme mit neuen Versionen gibt (upstream, nicht mal direkt im packaging). Funktionen fallen weg oder es gibt in einer neuen Version einen Bug. Oder bei einem Dienst ändert sich die Syntax für config-Dateien.
Da muss ich ab und zu mal etwas anpassen, was auch kein Problem ist. Ich finde es aber viel stressfreier, täglich ohne jeden Gedanken aktualisieren zu können und mir dann 1-2x im Jahr etwas Zeit für eine Aktualisierung zu machen.
Wenn ich morgens zu einem Kunden fahre, möchte ich nicht Gefahr laufen, dass plötzlich irgendeine für mich wichtige Komponente nicht mehr geht, weil sich etwas geändert hat.
Und Zeit zum täglichen Lesen von Update-Hinweisen hätte ich nur selten (bzw. wenn müssten sie sehr zeitsparend personalisiert sein, z.B. Mail nur bei Paketen, die ich wirklich installiert habe, am besten auch mit klaren Hinweisen, wie sich welche Datei/Option geändert hat).
Verwaist sind sie ja erstmal nur für die neuen Versionen in Sid. Wenn es kritische Lücken gibt und kein Maintainer diese in Stable einbringt, dann wird das gemeldet und das Paket wird in Stable gelöscht. Außer es ist etwas sehr obskures, das dann keiner merkt. Natürlich ist bei 40 000 Paketen nicht alles rosig.
Deswegen setze ich auf Debian 'stable'. Habe das noch nie bereut :)
Am 13. Mai 2008 gab das Debian-Projekt bekannt, dass das OpenSSL-Paket der Distributionen seit 17. September 2006 (Version 0.9.8c-1 bis 0.9.8g-9) eine Sicherheitslücke enthielt. Durch einen Fehler in einem Debian-spezifischen Patch sind die mit dem in diesen Paketen enthaltenen Zufallszahlengenerator erzeugten Schlüssel vorhersagbar. Davon betroffen seien SSH-, OpenVPN-, DNSSEC-Schlüssel, Schlüssel in X.509-Zertifikaten sowie Sitzungsschlüssel, die in SSL/TLS-Verbindungen (HTTPS) genutzt werden.
Von .-,.-,-.,-.,-.,-.,-., am Di, 26. April 2016 um 00:03 #
Debian gibt aber im Gegensatz zu Ubuntu haargenau an, welche Pakete Ihren Sicherheitssupport verloren haben. Die Debian-Maintainer sind da knallhart und nehmen teilweise solche Pakete aus der Distribution heraus.
Und wenn Du solche Debian-Hinweise gelesen hast, dann kannst Du auch gleich davon ausgehen, dass für das schweigende Ubuntu genau das Gleiche zutrifft.
Man sollte aber die Kirche im Dorf lassen. Gefährdet ist in erster Linie Software, die für Verbindungen ins Internet benutzt wird oder entsprechende Dienste im Internet anbietet, wie z.B. Netzwerksoftware und Webbrowser sowie Serverdienste und manche internetbenutzende Multimediasoftware.
Was folgt daraus? IMO, dass das Main-Core von Ubuntu sicher ist, samt wichtiger Internetsoftware wie Firefox und Thunderbird, die ohnehin alle *buntus benutzen. Katastrophen wie die Owncloud-Geschichte oder Seamonkey sind ja bekannt und wurden beseitigt.
Wenn man keine Serverdienste auf seinem Desktop anbietet, dann ist es trotz vorhandener Sicherheitslücken recht schwierig, übers Internet in ein solches System einzubrechen, zumal Software wie OpenJDK, Bind, Firefox, Thunderbird und Openssl, um nur einige Beispiele zu nennen, über Ubuntu Main gefixt werden. Multimediasoftware wie ein vielleicht irgendwann einmal ungefixtes VLC ist da als potentielle Einbruchsquelle nur schwer einzuschätzen.
Canonical müsste diese Tatsachen aber auch wenigstens einmal in den Release Notes an prominenter Stelle klar ansagen. Ansonsten sieht das wie Verharmlosen aus. Wenn nicht Canonical seine MOTUs kennt und deren Leistungsfähigkeit, wer dann?
Laien und Newbies sind mit solchen Problemen, wenn sie damit allein gelassen werden, jedenfalls komplett aufgeschmissen.
Bei Ubuntu genauso wie bei Mint und genauso wie bei Windows. Oder hat schon jemand einmal gehört, dass Microsoft Adobes FlashPlayer oder Oracles Java fixt?
Ich persönlich halte den momentanen Zustand bei Ubuntu mit dieser Universe- und Multiverse- Ab- und Aufteilung für ganz großen Mist. Das ist dringend reformbedürftig. Canonical kann wirklich froh sein, dass heise.de nicht mehr auf Englisch publiziert.
Schon komisch, dass dies nicht schon früher thematisiert wurde. Mit dem LTS erweckt Ubuntu den Eindruck von 5 Jahren Support. Wenn man dann aber genauer hinschaut ist dies nur für das main Repository der Fall. main = Canonical supported Mit den Paketen von main allein kommt aber kein Mensch aus. Das universe Repository wird "community maintained" angegeben. Da Community das ganze Linux am laufen hält, fühlt man sich hier von einer Gemeinschaft umsorgt und geschützt.
Bei Cannonical scheit der Begriff aber anders gebraucht zu werden. Im Sinne von "cannonical ist nicht zuständig". Da es offensichtlich auch keine community gibt die sich bei Ubuntu kompetent darum kümmern kann, ist der 5 Jahres Support ein Fake.
Eigentlich müsste es lauten: universe = no community, nothing maintaned
Ubuntu sollte die Kommentare aus der sources.list dem Benutzer klarer anzeigen. Dort steht alles sehr deutlich drin. So wie es derzeit in der GUI gemacht wird (insbesondere mit standardmäßig aktiviertem universe/multiverse), ist es irreführend.
Wenn man stabil will Debian. Oder wenn man es lieber aktuell haben möchte Siduction, Arch. Manjaro ist auch RR aber auch für den unerfarenen User benutzbar.
Ich verwende nun seit Jahr und Tag openSUSE, derzeit 42.1. Vielleicht täusche ich mich ja, aber ich habe den Eindruck, dass Ubuntu-LTS-Problem gibt es da nicht. Allerdings kann ich die neue Version nicht auf meinem 32-bit Notebook installieren. Werde wohl auf Ubuntu wechseln und, ehrlich gesagt, ich habe da wenig Bedenken, was die Sicherheit angeht. Zur Zeit werden noch erschreckend wenige Viren für Linux programmiert. Wer aus Sicherheitsgründe von Ubuntu ab- und bei Windows 10 zurät, nun ja, der hat wohl ein ganz eigenes Sichtsbewusstsein... Ich habe auch den Heise-Artikel so verstanden, dass es jetzt langsam ernst wird mit der Konkurrenz.
Muss nicht sein das es als Konkurrenz war genommen wird. Aber Sicherheit und Ubuntu sind auch schon früher aufgefallen. Wenn ich mich recht entsinne, war Ubuntu Repository schonmal gehackt worden, weil deren System auf veraltete Software setzte.
Fünf der acht von Canonical gestifteten Ubuntu-Community-Server mussten abgeschaltet werden, da sie geknackt wurden und aktiv andere Server angriffen.
Bei der Analyse der Server wurde festgestellt, dass auf den Servern sehr viel Software lief und die Versionen teilweise veraltet waren bzw. Sicherheits-Updates nicht installiert wurden. Zudem wurde FTP ohne SSL-Verschlüsselung genutzt, so dass Passwörter ausspioniert werden konnten und die Server nutzten noch immer den mit "Breezy Badger" ausgelieferten Kernel. Nun wird vermutet, dass der oder die Angreifer eine Kernel-Lücke ausgenutzt haben könnten.
Im professionellen Umfeld: RHEL/SLES bzw. die RHEL-Clone: CentOS, Scientific Linux. Knapp 10 Jahre Support für einen Release. Die ursprünglichen Binärpakete kommen von RedHat, da fließt Geld, so dass ich aus bisheriger Erfahrung sagen kann, dass für alle großen/wichtigen Softwarepakete zeitnahe und funktionierende Patches/Updates erschienen sind. Ob auch EPEL-Pakete so gut gepflegt werden, kann ich nicht sagen. Ansonsten bin ich privat auch ein großer GNU/Linux Debian-Fan - gefühlt etwas träger als RedHat/Fedora, aber stetige und zuverlässige Updates.
Gentoo und ArchLinux hatte ich früher mal, war mir irgendwann zu "anstrengend", da mir so manches pacman-Update (nachdem ich mehrere Wochen kein Update gemacht habe) mir mein gesamtes System zerschossen hat. Daher nutze ich auf dem Desktop nun Fedora und bin sehr zufrieden damit. Es funktioniert einfach und Updates erscheinen nahezu täglich.
Die RPM-Fusion-Repos einbinden ist natürlich ein Riesenaufwand ... Dauert geschätzte 5 Sekunden. Die eigentliche Installation dürfte sich dann zeitlich nicht von Debian unterscheiden. Evtl. geht's sogar, Delta-RPMs sei Dank, etwas fixer.
Ansonsten findest du für Fedora so ziemlich jede Software, die es auch in anderen Distributionen gibt.
Mit RPM-Fusion und anderen alternativen rpm-Quellen (wie EPEL für RHEL) steht man aber wiederum auf ähnlichem Stand wie bei Debian Contrib oder Ubuntu Universe. Da kann man genauso gut zu letzteren greifen. Oder aber Fedora/Debian/Ubuntu ohne Fusion/Contrib/Universe nutzen. Sicherer, aber wiederum weniger Software. Oder aber zu Entwicklerversionen oder Rolling Release greifen - Debian Sid, Arch Linux, Gentoo ~, etc. Hat auch seine Vor- und Nachteile. Hängt alles von den persönlichen Präferenzen ab. Man hat immerhin selber die Wahl und kriegt diese nicht vom Softwarehersteller vorgeschrieben.
Wie mein Oppa schon immer sagte: Et is gehüppt wie gesprunge.
Es geht nicht um die Frage wie schnell oder aufwändig es ist das Repo einzubinden. Du hast da wieder ein Repo wo nicht klar ist, wie gut oder schlecht die Pakete gewartet werden und du gibst den Maintainern damit direkt root Zugang zu deinen Systemen.
Jetzt plötzlich geht's Dir um die Sicherheit der Extra-Repos?
Oben schriebst Du doch noch, dass Dir so viel Software fehlt und das hatte ich beantwortet. Überlege Dir erst mal, was du möchtest und plappere nicht jedes hier gelesene Halbwissen nach.
Mir ist doch vollkommen egal, ob Du Ubuntu oder sonst irgendwelchen halbgaren Mist nutzt.
Denke doch erst mal nach bevor du etwas von dir gibst. Warum sollte ich denn sonst einen Bogen um Fedora machen? Oder andere Distributionen die nur eine relativ kleine Anzahl an Paketen selber anbieten.
Weil du stets auf einen Dritten angewiesen bist oder selber Hand anlegen musst.
Aber entschuldige das ich dir nicht alles vorgekaut habe, was eigentlich offensichtlich ist.
Von Idiotenpfleger am Mo, 25. April 2016 um 20:50 #
dass dieses Problem bei jeder Distribution besteht. Beim hochgelobten Debian Stable genau so wie bei Fedora. Bei Fedora vielleicht noch krasser, wegen des ultrakurzen Supportzeitraums. Ich will gar nicht wissen, wie viele veraltete Fedora-Rechner durchs Netz geistern.
Chef@Rechner:~$ ubuntu-support-status Zusammenfassung der Unterstützung für 'Rechner':
Sie haben 86 Pakete (4.9%), die bis Februar 2015 (9m) unterstützt werden Sie haben 41 Pakete (2.3%), die bis Januar 2017 (9m) unterstützt werden Sie haben 1428 Pakete (80.6%), die bis Mai 2019 (5y) unterstützt werden Sie haben 149 Pakete (8.4%), die bis Mai 2017 (3y) unterstützt werden
Sie haben 0 Pakete (0.0%), die nicht/nicht mehr heruntergeladen werden können Sie haben 67 nicht unterstützte Pakete (3.8%)
Für weitere Informationen mit --show-unsupported, --show-supported oder --show-all ausführen Chef@Rechner:~$ ubuntu-support-status --show-unsupported Zusammenfassung der Unterstützung für 'Rechner':
Sie haben 1428 Pakete (80.6%), die bis Mai 2019 (5y) unterstützt werden Sie haben 86 Pakete (4.9%), die bis Februar 2015 (9m) unterstützt werden Sie haben 149 Pakete (8.4%), die bis Mai 2017 (3y) unterstützt werden Sie haben 41 Pakete (2.3%), die bis Januar 2017 (9m) unterstützt werden
Sie haben 0 Pakete (0.0%), die nicht/nicht mehr heruntergeladen werden können Sie haben 67 nicht unterstützte Pakete (3.8%)
Ist gleich: ein paar Metapakete, Google Chrome ist selbstverständlich weiterhin unterstützt, genau wie Opera. Dann haben wir noch ein paar Gnome-Spiele... will ja mal sehen, wie sich einer durchs Mahjong-Spiel in mein Internetbanking hackt...
Na ja, da sind immerhin auch gstreamer und libreoffice dabei. D.h. irgendeine Applikation, die aus dem Netz z.B. Videos mit gstreamer verarbeitet, kann schon angreifbar sein.
Oder es wird ein Bug in libreoffice exploitet - das muss nicht mal der geöffnete Anhang sein, es könnte u.U. schon ausreichen, wenn man das Office-Dokument auf der Platte hat und dann nautilus über den thumbnailer-Prozess libreoffice aufruft.
Von Idiotenpfleger am Mo, 25. April 2016 um 21:22 #
Und ist denn z.B. Gstreamer überhaupt veraltet? Oder einfach nur nicht UNTERSTÜTZT? Der Unterschied ist gewaltig, oder?
Libreoffice: dann müsste der Hacker also erst auf die Platte, durch einige aktuelle/ aktualisierte Pakete, um dann ans ach so verwundbare Libreoffice zu kommen und dann den Nautilus zu hacken... jipp. Genauso wirds laufen
gstreamer selbst ist natürlich nicht veraltet, aber wenn es von Canonical nicht unterstützt wird, heißt es, dass hier ev. Sicherheitsupdates auch nicht den Weg in Ubuntu finden.
Und bei LibreOffice reicht es, z.B. einen Mailanhang zu öffnen bzw. in vom Mailprogramm auf der Platte zu speichern.
Diesen Angriffsvektor finde ich nicht so abwegig, zumal das "auf der Platte speichern" auch per drive-by download passieren kann.
Von .,-.,-,-.,.-,-.,-., am Mo, 25. April 2016 um 22:09 #
Verharmlosen ist hier die falsche Strategie.
Das Chaos, das aus Deinen hier zitierten Angaben durchlugt, ist ungeheuer.
Was ist denn daran so schwierig, tatsächlich mit Sicherheitsupdates unterstützte Universe- und Multiverse-Software in einem eigenen Repo zusammenzufassen? Dann könnte man bewusst den unsicheren großen Rest meiden.
Ubuntu Main reicht IMO nicht für den Desktop. Der wäre dann genauso "multimediamäßig kastriert" wie Opensuse, Fedora oder RHEL.
Und genau das ist das Schlimme an diesem Obscurity-Schleier, den Canonical letztlich mit über Ubuntu Universe und Multiverse gelegt hat.
IMO wäre Canonical nur dann moralisch und verantwortungstechnisch aus dem Schneider, wenn die Universe- und Multiverse-Repos nicht standardmäßig bereits ab dem ersten Ubuntu-Start aktiviert wären. Genau das sind diese aber.
Von Idiotenpfleger am Di, 26. April 2016 um 06:10 #
Es gibt keinen Obscurity-Schleier.
Wie weiter oben schon mehrfach erwähnt wurde, sagt Canonical ganz genau, was mit den Universe und Multiverse Repos los ist. Sie werden von der "Gemeinschaft" betreut. Und wenn da eben keiner aus dieser "Gemeinschaft" da ist, der die Pakete betreut? Wer hat dann den schwarzen Peter? Canonical? Mitnichten!
Die "Gemeinschaft" an sich hat dann den schwarzen Peter. Aber das ist man ja als User gewöhnt: es sind für diese "Gemeinschaft" immer "die anderen" schuld. Und wenn dann mal wieder wie hier dieser ganze Haufen an Selbstgefälligkeit unter solchen Sicherheitslücken zusammenbricht, ist das Gejammer groß... So sieht es nämlich aus. Diese Doppelmoral und Selbstgefälligkeit kotzt mich dermaßen an, das ist einfach unglaublich.
Übrigens bedeutet "unsupported" noch lange nicht, dass das Paket veraltet ist, dass es verwaist ist oder sonstwas. Gerade erst vor 2 Wochen kam ein Schwung Updates für die gstreamer-Pakete in 14.04 rein... wie das, wenn die Pakete ja "Überhaupt gar nicht mehr betreut werden"???
XXX@yyy:~$ ubuntu-support-status --show-unsupported Zusammenfassung der Unterstützung für 'yyy':
Sie haben 61 Pakete (2.7%), die bis Januar 2017 (9m) unterstützt werden Sie haben 1651 Pakete (73.6%), die bis April 2021 (5y) unterstützt werden Sie haben 307 Pakete (13.7%), die bis April 2019 (3y) unterstützt werden
Sie haben 0 Pakete (0.0%), die nicht/nicht mehr heruntergeladen werden können Sie haben 224 nicht unterstützte Pakete (10.0%)
Man schaue sich einmal die Anzahl und die Namen der bereits im ersten Monat der Ubuntu 16.04-Existenz nicht mehr unterstützten Pakete an (u.a. Claws-Mail, Epiphany-Webbrowser, Wine, Dosbox, Midnight Commander, Qpdfview, Mupdf, Pdfmod, praktisch alle Nmap-GUIs): 224 nicht mehr unterstützte Pakete, 10% der gesamten Paketinstallation.
Bei der Installation der nicht mehr unterstützen Pakete gab es keinen einzigen Hinweis. So steht unter Epiphany-Browser Folgendes zu den Betreuern: Ubuntu Developers (...). Wenn das heißen soll, dass dieses Paket bereits jetzt nicht mehr unterstützt ist, dann erinnert mich diese Angabe ganz klar an ein Potemkinsches Dorf. Das Paket Claws-Mail hat den gleichen Pseudo-Maintainer.
Das in Ubuntu Main befindliche Paket Gcc5 hat demgegenüber folgenden theoretischen Betreuer: Ubuntu Core Developers (...). Man achte auf den feinen Unterschied.
Beim Thunar-Paket, das von Xubuntu unterstützt wird, steht dabei als Betreuer: Xubuntu Developers (...).
IMO heißt das somit, dass die Angabe, dass die Betreuer u.a. von Epiphany-Browser und Claws-Mail Ubuntu Developers (...) seien, IMO einen reinen Fake darstellt, da es sich hierbei um eine klare Falschangabe handelt. Bei den nicht unterstützten Paketen wie Epiphany-Browser und Claws-Mail müsste stehen: Not Supported oder Unmaintained. Nur das ist in diesem Zusammenhang eine korrekte Angabe.
Hinweis: (...) steht für die jeweilige in Klammern angegebene Mailinglist-Adresse der angegebenen Maintainer.
Von ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, am Fr, 13. Mai 2016 um 00:59 #
Keiner von Euch hat sich mit Ruhm bekleckert.
Hat sich irgendjemand von Euch denn jemals gefragt, ob ubuntu-support-status überhaupt korrekte Daten ausspuckt?
Schau(t) einmal hier: https://bugs.launchpad.net/ubuntu/+source/update-manager/+bug/1574670 "ubuntu-support-status returns inaccurate information"
Offenbar hat auch heise.de nicht bei Ubuntu bzw. Canonical nachgefragt, was dieses angeblich gebrochene LTS-Versprechen denn eigentlich soll. Dann hätte man vielleicht darauf kommen können.
Das ist etwa so, als wenn alle hier leidenschaftlich über einen Text diskutieren würden, den aber niemand zuvor überhaupt gelesen hat.
denn was Canonical nämlich ungesagt lässt ist, dass ein bekanntes Sicherheitsproblem von grafischen Linux-Anwendungen auch bei Snap besteht: Grafische Anwendungen können die Tastatureingaben und Daten anderer Programme abgreifen, die zur gleichen Zeit unter dem X-Server laufen. Da die Desktop-Ausgabe von Ubuntu 16.04 auf diese Art die Bedienoberfläche ausgibt, ist die Abschottung von Snap-Programmen so gut wie gar nicht gegeben. Anders sieht es mit dem X11-Nachfolger Mir aus, der auf den Mobile-Versionen von Ubuntu zum Einsatz kommt. Deren Verbreitung ist im Vergleich mit den Desktop- und Server-Ausgaben von Ubuntu allerdings zu vernachlässigen.
Einige Distributionen erschweren diesen Angriffsweg mit SELinux – Ubuntu aber nicht. Eine generelle Lösung für diese Sicherheitsproblematik für alle Linux-Distributionen ist aber in Sicht: Die von der Mehrheit der Linux-Entwickler als X11-Nachfolger designierte Software Wayland löst das Problem ebenso wie der Konkurrent Mir, den Canonical im Alleingang vorantreibt. Auch entwickelt das Gnome-Projekt mit den xdg-apps eine Technik, welche sehr ähnliche Ziele hat wie Snap und sich breiter Unterstützung unter jenen Linux-Entwicklern erfreut, die nicht an Ubuntu arbeiten.
Das finde ich ehrlich gesagt alles wenig überraschend. Man darf halt doch immer nur soviel erwarten wie man auch bezahlt ...
Zumal man Ubuntu zu gute halten muss, dass der eingeschränkte Support (nur main Repo) nie verheimlicht wurde (wenn auch nicht besonders offen kommuniziert).
Ich frage mich hingegen, welche Alternativen das sind nach denen man sich umschauen sollte. Ob z.B. Red Hat einen besseren Langzeit-Support von Multimedia-Paketen bietet, weiß ich nicht. Die meisten kommerziellen Linux Distributionen sind ja auf Unternehmen (Server) ausgerichtet.
Ist das vlt. sogar eine Marktlücke? Ich meine viele "Linux-Fans" sind doch inzwischen raus aus Schule und Uni und wären bereit alle 5 Jahre 100 € (so z.B. der Preis für nicht Upgrade Windows 10) für ein Betriebssystem auszugeben.
Als Desktopuser würde ich auch ein Rolling Release setzen. Mit Arch bin ich bisher sehr gut gefahren, leider ist es viel zu kompliziert für den normalen User.
Es muss ja nicht gleich rolling sein aber so 1mal im jahr auf die neueste version updaten sollte ja drin liegen, bei xp gabs ja auch ab und an ein sp...
Bei diversen distries klappt das mit den updates mittlerweile ja auch ganz ok. Bei meiner mutter löse ich normalerweise das update auf die nächste version aus esse ein feines abendessen und schaue zum schluss noch schnell ob alles ok ist.
Bei meinem vater mit win 10/10 xyz hat das etwas länger gedauert bis alles wieder auf dem letzten stand war...
Es gibt ja jedes halbe Jahr eine neue Ubuntu Version. Der Artikel kritisiert nur die Ubuntu LTS bei Benutzung von Software aus anderen als main Repository. Und empfiehlt dann alternative Distributionen zu verwenden.
Andere Möglichkeit ist immer die aktuellste Ubuntu Version zu verwenden.
Fertiggeräte kommen oft mit den LTS Versionen. Dort ist man auch gerne mal auf LTS beschränkt, da mit neueren Versionen die Anpassungen des Herstellers verloren gehen.
Dieses Problem hatten/haben zum Beispiel die Dell Geräte. Beim neusten Gerät soll es kein Problem mehr sein, aber bei denen davo schon.
Dann kommen noch Projekte wie Limux oder Mint. Diese bauen auch auf LTS auf, und sind somit alle verwundbar.
Warum nicht rolling? Ubuntu hat mit Snaps ja inzwischen auch ein Format, mit dem Anwendungen Isoliert alles mitbringen was sie brauchen.
Dann könnte man seine Anwendungen direkt aus dem Upsream beziehen, wie unter Windows dann auch. Wünschenswert wäre dann ein moderiertes Repository das alle Snaps bereitstellt und vielleicht auch mit älteren Versionen. Das könnte dann sogar Distributionsunabhängig sein.
PS: Bei Windows ist das Problem ein anderes. Wobei Problem hier etwas weit gegriffen ist. Du musst theoretisch nur alle 10 Jahre ein OS Upgrade machen. Viele machen wohl nie eins, da sie vorher einen neuen Rechner kaufen. Dort müssen sich die Anwendungen nur darum kümmern, sich selber auf dem aktuellen Stand zu halten.
Zwei meiner Bekannten nutzen z.B. noch immer Geräte mit Windows Vista. Das Upgrade ist bei ihnen nicht nötig, da sie sich bald eh neue Geräte zulegen wollen. Weniger wegen dem OS, sondern viel mehr um leistungsfähigere Hardware zu bekommen bzw längere Akkulaufzeiten.
"Warum nicht rolling?"
Hier 3 Erfahrungen:
1. Ich hab im Urlaub meinen Laptop mit Arch + Gnome 3.18 und ein Dumb Phone mit. Kriege per Email die Boardkarte, die ich ausdrucken soll. Meine Freundin hat nen schicken neuen Netzwerkdrucker. Davor hatte ich Debian Stable und es klinkte sich ohne Probleme in das Ding ein. Mit Arch keine Chance. Mein Kumpel, auch da zu Gast, nimmt sein billiges Android Phone, das sich binnen 10s da einklinkt und meine Datei druckt.
2. Selber Laptop, Antegros. Wir wollen einen Film gucken, HDMI geht auf einmal nicht. Geht sonst auf dem älteren (!) Debian Stable oder Ubuntu LTS (da noch 14.04). Hab ATI, also läuft alles schön über Mesa.Nach viel Gefrickel macht es dann komische Farbeffekte wenn die Szene im Film dunkler oder heller wird.
3. Arch. Selber Laptop. Muss unbedingt Plakate die ich auf Inkscape gemacht habe als PDF speichern und zum Drucken schicken. Klappte sonst mit Debian Stable prima. Hier nicht. Inkscape stürzt dauernd ab. Notlösung: Inkscape auf dem Windows 7 Bürorechner installieren. LOL
Könnte bis morgen weitererzählen...
Also, es ist schade, dass Ubuntu LTS wenige Pakete unterstützen kann. Könnten sie doch bloß Entwicklerzeit in den Desktop stecken als in die Telefone... Tja...
Debian Stable ist dann für mich da. Und so Projekte wie xdg-app oder auf Ubuntu Snap liefern dann eventuell die frischen Pakete, die man unbedingt braucht.
Arch hat doch nur den Zweck, das man ständig was zum Basteln hat.
Meiner Meinung nach kann man es nicht für Dinge einsetzen auf die man angewiesen ist.
Arch hat doch nur den Zweck, das man ständig was zum Basteln hat.
Meiner Meinung nach kann man es nicht für Dinge einsetzen auf die man angewiesen ist.
Leute, was macht ihr alle? Mein Arbeitsplatzrechner in der Firma: Arch Linux seit 3+ Jahren. Muß laufen, Basteln ist für Wochenenden zuhause. Genau einmal ein Problem gehabt: Morgens Systemaktualisierung durchgeführt, anschließend wollte mein Desktop nicht mehr. Desktop neugebaut (bin selbst der Paketmaintainer eines externen Repos - insofern hat es genau den richtigen getroffen), Paket hochgeladen, nochmal aktualisiert und gut. Man sollte natürlich die Ankündigungen auf der Netzseite lesen UND _regelmäßig_ aktualisieren. Wer für das eine oder das andere zu faul ist, der kann schon mal ins Stolpern kommen. Wer meint, auf beides verzichten zu können, der muß mit Schmerzen leben - oder eben ohne Arch.
Zugegeben: LibreOffice kann ganz schön nerven. Aber wenn die neuste Version mal wieder so kaputt ist, daß sie effektiv unbrauchbar ist, dann gibt es ja noch libreoffice-still. Ansonsten: Mit Arch KANN man ganz nett basteln. Muß man aber nicht. Ganz normal arbeiten geht durchaus auch. Sogar recht gut.
Ich fände es schön, wenn die Diskussion sachlich bleiben könnte. Ersetze doch einfach mal "faul" gegen "wer andere zeitliche Prioritäten" hat.
Mit Familie oder echter "Crunch-Time" im Job haben selbst Computer-Interessierte ganz schnell keine Zeit mehr dafür, sich jeden Morgen mit den Updates zu beschäftigen.
> Ersetze doch einfach mal "faul" gegen "wer andere zeitliche Prioritäten" hat.
So gerne ich Deinen Formulierungsvorschlag annahmen würde: Nein.
Unterschiedliche Distributionen haben unterschiedliche Voraussetzungen. Die beiden Hauptvoraussetzungen für einen reibungslosen Betrieb sind bei Arch: „Halte dein System aktuell“ und „wisse, was du tust“. Ersteres ist dem Rolling-Release-Modell geschuldet, bzw. der Community-Ausrichtung bei Arch: Es ist niemand da, der einen funktionalen Updatepfad auf die aktuellste Version für sechs Monate alte Installationen sicherstellt. Für die zweite Voraussetzung gibt sich Arch alle Mühe, ein wirklich gutes und umfangreiches Wiki zu pflegen.
Natürlich: Es hat nicht jeder die Zeit, sich damit zu beschäftigen. Ich habe selbst Familie und weiß, wie rar Freizeit ist. Das heißt aber ganz einfach: Arch ist nicht für jeden die richtige Distri. Was aus meiner Sicht auch nicht schlimm ist. Ich schätze z.B. auch die Flexibilität von Gentoo. Aber wenn ich ehrlich zu mir bin, dann könnte ich mir z.B. für meine Arbeitsstation die Kompilierzeiten für Updates von Kernel, Kompiler & Co. gelinde gesagt nicht leisten. Damit scheidet Gentoo als Möglichkeit aus.
Was meine Formulierung mit der Faulheit anging: Ein Kollege hier hat sich auch ein Arch aufgesetzt, da ihm der Minimalansatz des Systems zusagte. Bei ihm hakt es immer mal wieder mit dem System und es machen Programme Probleme, die bei mir einwandfrei funktionieren - obwohl wir die gleichen Paketversionen haben. Wenn etwas kaputt ist und ich ihn frage, ob er gerade aktualisiert hat, ist die Antwort zu fast 100%: „Ja“. Da er sich für Arch entschieden hat (und die Voraussetzungen kannte), muß er mit meinem Vorwurf der Faulheit leben können (kann er auch).
Das heißt natürlich nicht, daß ich Leuten, die Arch wegen der genannten Voraussetzungen ausschließen, Faulheit unterstelle. Es gibt viele gute Gründe, sich gegen Arch zu entscheiden. Was mir aber wichtig ist: Es ist einfach unnötig, daß viele Leute, für die Arch vielleicht passen würde, es sich gar nicht erst ansehen, weil sie überall lesen, daß Rolling-Release immer wieder alles kaputt mache. Das kommt ohne Frage vor, wenn man die Regeln verletzt. Ganz überwiegend aber auch nur dann.
Es ging hier aber ursprünglich darum, auch Rolling Releases statt der bishering Ubuntu Update Politik zu benutzen (siehe Originalpost).
Den Vergleich zu Arch (aber auch zu Antergos, u.ä. Distri, die auf Arch aufbauen, sich aber an einfache Benutzer richten) habe ich gemacht, um meine Erfahrnungen mit solchen Systemen mitzuteilen. Ich bin zu faul dafür, diese zu pflegen. Und ich denke mal, der Durchschnitts-Ubuntu-User ist es auch. Rolling Release ist für mich also kein guter Ersatz und Half-Rolling so wie Suse oder Sabayon/Chakra/Antergos sind genauso buggy für mich.
Das ist, wie gesagt. völlig legitim und ich habe auch keine Probleme damit. Arch ist nicht für jeden und wer keine Zeit/Lust hat, sich regelmäßig um ein paar Kleinigkeiten zu kümmern, der wird Probleme haben. In der Hauptsache habe ich Einspruch eingelegt, weil sich viele Kritiken an Arch so lesen, als seien die Probleme regelrecht „gottgegeben“ und praktisch unausweichlich.
Dann nächstes mal genauer lesen, denn im Originalpost erwähnte ich auch Antergos.
Aber wer weiß, vielleicht kriegen die das noch hin, dass ich auch ne half rolling Distro ohne viel Mühe einsetzen kann. Es ist noch eine sehr junge Distro.
Ich mache nix.
Aber woher soll ich wissen, dass Cups oder die Treiber spontan abkacken? Als normaler User hab ich dazu leider auch nicht die Zeit, das alles nachzulesen.
Und davor hätte ich Angst, wenn Sachen in Anfängerdistri rolling werden.
Arch hat doch nur den Zweck, das man ständig was zum Basteln hat.
Meiner Meinung nach kann man es nicht für Dinge einsetzen auf die man angewiesen ist.
Mit Arch KANN man ganz nett basteln. Muß man aber nicht.
Arch Linux seit 3+ Jahren
Nope.. aber in ein paar Jahren wirst es von alleine verstehen.
Nach einem pacman -Syu mag das System zwar i.O. aussehen aber die Regressionen prasseln dir jeweils ganz langsam ins Gesicht.. meistens dann, wenn man sie am wenigsten brauchen kann.
> Nope.. aber in ein paar Jahren wirst es von alleine verstehen.
Hui, wie viele Jahre sind denn nötig, bis Arch einen beißt? Möglicherweise werde ich es allerdings nicht erleben, denn wenn ich den Rechner neu aufsetzen würde, würde ich heute nicht mehr Linux nehmen, sondern wahrscheinlich FreeBSD (ausgezeichnete ZFS-Unterstützung, ausgereiftes Jailsystem, Bhyve, ...). Im Zuge des Umstieges auf Systemd hat Arch ja leider auch sein hauptsächliches Alleinstellungsmerkmal, die zentralisierte Konfiguration, aufgegeben, was ich noch immer für einen unklugen Zug halte.
> Nach einem pacman -Syu mag das System zwar i.O. aussehen aber die Regressionen prasseln dir jeweils ganz langsam ins Gesicht..
Es kann ganz gut sein, daß ich vielen Problemen aus ganz anderen Gründen nie begegnet bin: Ich bin - zumindest auf der Arbeit - Minimalist. Ob KDE oder irgendwelche aufgeblähten Programme unter Arch leicht kaputtgehen, weiß ich nicht. Wo es irgend geht, setze ich auf Programme, wo upstream auf Stabilität und Korrektheit wertgelegt wird (z.B. die suckless-Projekte). Arch ist bewußt nahe am Upstream und wenn da geschlampt wird, kommt da bestimmt mal was durch - wie bereits erwähnt, ist Libreoffice so ein Programm. Leider aber eines, zu dem es kaum eine brauchbare Alternative gibt.
Du hast aber keine Intel GPU, nehme ich an?
Für mich persönlich: Weil es immer wieder mal Probleme mit neuen Versionen gibt (upstream, nicht mal direkt im packaging). Funktionen fallen weg oder es gibt in einer neuen Version einen Bug. Oder bei einem Dienst ändert sich die Syntax für config-Dateien.
Da muss ich ab und zu mal etwas anpassen, was auch kein Problem ist. Ich finde es aber viel stressfreier, täglich ohne jeden Gedanken aktualisieren zu können und mir dann 1-2x im Jahr etwas Zeit für eine Aktualisierung zu machen.
Wenn ich morgens zu einem Kunden fahre, möchte ich nicht Gefahr laufen, dass plötzlich irgendeine für mich wichtige Komponente nicht mehr geht, weil sich etwas geändert hat.
Und Zeit zum täglichen Lesen von Update-Hinweisen hätte ich nur selten (bzw. wenn müssten sie sehr zeitsparend personalisiert sein, z.B. Mail nur bei Paketen, die ich wirklich installiert habe, am besten auch mit klaren Hinweisen, wie sich welche Datei/Option geändert hat).
Meine Rede.
Für den normalen User gibt es da Distribution wie Manjaro (basierend auf Arch).
Deswegen setze ich auf Debian 'stable'. Habe das noch nie bereut
Bei Debian ist auch nicht alles Gold was glänzt. Niemand garantiert dir, dass ein Paket auch über den gesamten Supportzeitraum gepflegt wird.
Hier mal eine Liste mit verwaisten Paketen ohne Maintainer:
https://www.debian.org/devel/wnpp/orphaned
Verwaist sind sie ja erstmal nur für die neuen Versionen in Sid.
Wenn es kritische Lücken gibt und kein Maintainer diese in Stable
einbringt, dann wird das gemeldet und das Paket wird in Stable gelöscht.
Außer es ist etwas sehr obskures, das dann keiner merkt.
Natürlich ist bei 40 000 Paketen nicht alles rosig.
Es gab hier mal eine Meldung, dass in Debian auch jede Menge Lücken existieren; als Beispiel wurde PHP angeführt.
Auf die Schnelle habe ich nur diesen Link gefunden, siehe: "action needed":
https://tracker.debian.org/pkg/php5
Am 13. Mai 2008 gab das Debian-Projekt bekannt, dass das OpenSSL-Paket der Distributionen seit 17. September 2006 (Version 0.9.8c-1 bis 0.9.8g-9) eine Sicherheitslücke enthielt. Durch einen Fehler in einem Debian-spezifischen Patch sind die mit dem in diesen Paketen enthaltenen Zufallszahlengenerator erzeugten Schlüssel vorhersagbar. Davon betroffen seien SSH-, OpenVPN-, DNSSEC-Schlüssel, Schlüssel in X.509-Zertifikaten sowie Sitzungsschlüssel, die in SSL/TLS-Verbindungen (HTTPS) genutzt werden.
Debian Sta(b)le ist unsicher. Längst nicht aus allen Upstream-Sicherheitsaktualisierungen können "reine Sicherheitsupdates" rausgefrickelt werden.
Debian gibt aber im Gegensatz zu Ubuntu haargenau an, welche Pakete Ihren Sicherheitssupport verloren haben. Die Debian-Maintainer sind da knallhart und nehmen teilweise solche Pakete aus der Distribution heraus.
Und wenn Du solche Debian-Hinweise gelesen hast, dann kannst Du auch gleich davon ausgehen, dass für das schweigende Ubuntu genau das Gleiche zutrifft.
Man sollte aber die Kirche im Dorf lassen. Gefährdet ist in erster Linie Software, die für Verbindungen ins Internet benutzt wird oder entsprechende Dienste im Internet anbietet, wie z.B. Netzwerksoftware und Webbrowser sowie Serverdienste und manche internetbenutzende Multimediasoftware.
Was folgt daraus? IMO, dass das Main-Core von Ubuntu sicher ist, samt wichtiger Internetsoftware wie Firefox und Thunderbird, die ohnehin alle *buntus benutzen. Katastrophen wie die Owncloud-Geschichte oder Seamonkey sind ja bekannt und wurden beseitigt.
Wenn man keine Serverdienste auf seinem Desktop anbietet, dann ist es trotz vorhandener Sicherheitslücken recht schwierig, übers Internet in ein solches System einzubrechen, zumal Software wie OpenJDK, Bind, Firefox, Thunderbird und Openssl, um nur einige Beispiele zu nennen, über Ubuntu Main gefixt werden. Multimediasoftware wie ein vielleicht irgendwann einmal ungefixtes VLC ist da als potentielle Einbruchsquelle nur schwer einzuschätzen.
Canonical müsste diese Tatsachen aber auch wenigstens einmal in den Release Notes an prominenter Stelle klar ansagen. Ansonsten sieht das wie Verharmlosen aus. Wenn nicht Canonical seine MOTUs kennt und deren Leistungsfähigkeit, wer dann?
Laien und Newbies sind mit solchen Problemen, wenn sie damit allein gelassen werden, jedenfalls komplett aufgeschmissen.
Bei Ubuntu genauso wie bei Mint und genauso wie bei Windows. Oder hat schon jemand einmal gehört, dass Microsoft Adobes FlashPlayer oder Oracles Java fixt?
Ich persönlich halte den momentanen Zustand bei Ubuntu mit dieser Universe- und Multiverse- Ab- und Aufteilung für ganz großen Mist. Das ist dringend reformbedürftig. Canonical kann wirklich froh sein, dass heise.de nicht mehr auf Englisch publiziert.
Schon komisch, dass dies nicht schon früher thematisiert wurde.
Mit dem LTS erweckt Ubuntu den Eindruck von 5 Jahren Support.
Wenn man dann aber genauer hinschaut ist dies nur für das
main Repository der Fall. main = Canonical supported
Mit den Paketen von main allein kommt aber kein Mensch aus.
Das universe Repository wird "community maintained" angegeben. Da Community das ganze Linux am laufen hält, fühlt man sich hier von einer Gemeinschaft umsorgt und geschützt.
Bei Cannonical scheit der Begriff aber anders gebraucht zu werden. Im Sinne von "cannonical ist nicht zuständig".
Da es offensichtlich auch keine community gibt die sich bei Ubuntu kompetent darum kümmern kann, ist der 5 Jahres Support ein Fake.
Eigentlich müsste es lauten:
universe = no community, nothing maintaned
Ubuntu sollte die Kommentare aus der sources.list dem Benutzer klarer anzeigen. Dort steht alles sehr deutlich drin. So wie es derzeit in der GUI gemacht wird (insbesondere mit standardmäßig aktiviertem universe/multiverse), ist es irreführend.
Schon komisch, dass dies nicht schon früher thematisiert wurde.
Das ist ein alter Hut, der schon mehrfach thematisiert wurde. Aber noch nicht von jedem
so welche Distri ist dann besser in patchen ? und aktuell gut ?
Wenn man stabil will Debian.
Oder wenn man es lieber aktuell haben möchte Siduction, Arch. Manjaro ist auch RR aber auch für den unerfarenen User benutzbar.
Mit stabil meinst du aber eher alt. Denn auch Debian hat viele Bugs die im Upstream bzw. neueren Versionen schon behoben wurden.
sid(uction) und aktuell? Lustig ....
Ich verwende nun seit Jahr und Tag openSUSE, derzeit 42.1. Vielleicht täusche ich mich ja, aber ich habe den Eindruck, dass Ubuntu-LTS-Problem gibt es da nicht. Allerdings kann ich die neue Version nicht auf meinem 32-bit Notebook installieren. Werde wohl auf Ubuntu wechseln und, ehrlich gesagt, ich habe da wenig Bedenken, was die Sicherheit angeht. Zur Zeit werden noch erschreckend wenige Viren für Linux programmiert. Wer aus Sicherheitsgründe von Ubuntu ab- und bei Windows 10 zurät, nun ja, der hat wohl ein ganz eigenes Sichtsbewusstsein... Ich habe auch den Heise-Artikel so verstanden, dass es jetzt langsam ernst wird mit der Konkurrenz.
Muss nicht sein das es als Konkurrenz war genommen wird. Aber Sicherheit und Ubuntu sind auch schon früher aufgefallen. Wenn ich mich recht entsinne, war Ubuntu Repository schonmal gehackt worden, weil deren System auf veraltete Software setzte.
In google habe ich "Ubuntu gehackt" eingegeben und sogar mehr Dinge gefunden von denen ich nichts mal wusste.
Aber das meinte ich wohl:
http://www.golem.de/0708/54153.html
Ubuntu nutze ich damals hauptsächlich in der Version 5.04.
2013 ist das Ubuntuforum gehackt worden... Wußte ich zB nicht.
Hast du den Artikel von Golem gelesen?
Das Problem saß also wie so oft vor dem Rechner.Damals habe ich irgendwas darüber gelesen. Golem.de habe ich jetzt gefunden.
Ja, weiß ich dass das Problem von Menschen gemacht wird.
In diesem Fall kann man aber nicht mehr allein auf Benutzer die Probleme schieben.
Neben Rolling-Releases Semi-Rolling-Releases wie Fedora oder Tanglu.
Im professionellen Umfeld: RHEL/SLES bzw. die RHEL-Clone: CentOS, Scientific Linux. Knapp 10 Jahre Support für einen Release. Die ursprünglichen Binärpakete kommen von RedHat, da fließt Geld, so dass ich aus bisheriger Erfahrung sagen kann, dass für alle großen/wichtigen Softwarepakete zeitnahe und funktionierende Patches/Updates erschienen sind. Ob auch EPEL-Pakete so gut gepflegt werden, kann ich nicht sagen. Ansonsten bin ich privat auch ein großer GNU/Linux Debian-Fan - gefühlt etwas träger als RedHat/Fedora, aber stetige und zuverlässige Updates.
Gentoo und ArchLinux hatte ich früher mal, war mir irgendwann zu "anstrengend", da mir so manches pacman-Update (nachdem ich mehrere Wochen kein Update gemacht habe) mir mein gesamtes System zerschossen hat. Daher nutze ich auf dem Desktop nun Fedora und bin sehr zufrieden damit. Es funktioniert einfach und Updates erscheinen nahezu täglich.
http://www.pro-linux.de/sicherheit/
man sieht hier , dass fedora distro ist ganz gut in viel patchen
also installiere ich gleich das gute Fedora !
Bei Fedora mangelt es mir oft an Software. Man muss sie sich immer etwas zusammen suchen.
Welche fehlt Dir denn? Muss ja 'ne Menge sein, wenn der Mangel so häufig ist ...
Oder ist es nur das Finden, das Dir Probleme bereitet?
Zu lange her, aber eigentlich jede Anwendung die ich unter Debian einfach installieren konnte musste ich erst mal auf dem RPM Fusion Repos laden.
Die RPM-Fusion-Repos einbinden ist natürlich ein Riesenaufwand ... Dauert geschätzte 5 Sekunden. Die eigentliche Installation dürfte sich dann zeitlich nicht von Debian unterscheiden. Evtl. geht's sogar, Delta-RPMs sei Dank, etwas fixer.
Ansonsten findest du für Fedora so ziemlich jede Software, die es auch in anderen Distributionen gibt.
Mit RPM-Fusion und anderen alternativen rpm-Quellen (wie EPEL für RHEL) steht man aber wiederum auf ähnlichem Stand wie bei Debian Contrib oder Ubuntu Universe. Da kann man genauso gut zu letzteren greifen. Oder aber Fedora/Debian/Ubuntu ohne Fusion/Contrib/Universe nutzen. Sicherer, aber wiederum weniger Software. Oder aber zu Entwicklerversionen oder Rolling Release greifen - Debian Sid, Arch Linux, Gentoo ~, etc. Hat auch seine Vor- und Nachteile. Hängt alles von den persönlichen Präferenzen ab. Man hat immerhin selber die Wahl und kriegt diese nicht vom Softwarehersteller vorgeschrieben.
Wie mein Oppa schon immer sagte: Et is gehüppt wie gesprunge.
Dein Opa ist/war sicher ein schlauer Mensch und müsste er sich entscheiden (bzw. hätte er sich entscheiden müssen), dann sicher nicht für Ubuntu. ^^
Es geht nicht um die Frage wie schnell oder aufwändig es ist das Repo einzubinden. Du hast da wieder ein Repo wo nicht klar ist, wie gut oder schlecht die Pakete gewartet werden und du gibst den Maintainern damit direkt root Zugang zu deinen Systemen.
Jetzt plötzlich geht's Dir um die Sicherheit der Extra-Repos?
Oben schriebst Du doch noch, dass Dir so viel Software fehlt und das hatte ich beantwortet. Überlege Dir erst mal, was du möchtest und plappere nicht jedes hier gelesene Halbwissen nach.
Mir ist doch vollkommen egal, ob Du Ubuntu oder sonst irgendwelchen halbgaren Mist nutzt.
Denke doch erst mal nach bevor du etwas von dir gibst. Warum sollte ich denn sonst einen Bogen um Fedora machen? Oder andere Distributionen die nur eine relativ kleine Anzahl an Paketen selber anbieten.
Weil du stets auf einen Dritten angewiesen bist oder selber Hand anlegen musst.
Aber entschuldige das ich dir nicht alles vorgekaut habe, was eigentlich offensichtlich ist.
dass dieses Problem bei jeder Distribution besteht. Beim hochgelobten Debian Stable genau so wie bei Fedora. Bei Fedora vielleicht noch krasser, wegen des ultrakurzen Supportzeitraums. Ich will gar nicht wissen, wie viele veraltete Fedora-Rechner durchs Netz geistern.
Chef@Rechner:~$ ubuntu-support-status
Zusammenfassung der Unterstützung für 'Rechner':
Sie haben 86 Pakete (4.9%), die bis Februar 2015 (9m) unterstützt werden
Sie haben 41 Pakete (2.3%), die bis Januar 2017 (9m) unterstützt werden
Sie haben 1428 Pakete (80.6%), die bis Mai 2019 (5y) unterstützt werden
Sie haben 149 Pakete (8.4%), die bis Mai 2017 (3y) unterstützt werden
Sie haben 0 Pakete (0.0%), die nicht/nicht mehr heruntergeladen werden können
Sie haben 67 nicht unterstützte Pakete (3.8%)
Für weitere Informationen mit --show-unsupported, --show-supported oder --show-all ausführen
Chef@Rechner:~$ ubuntu-support-status --show-unsupported
Zusammenfassung der Unterstützung für 'Rechner':
Sie haben 1428 Pakete (80.6%), die bis Mai 2019 (5y) unterstützt werden
Sie haben 86 Pakete (4.9%), die bis Februar 2015 (9m) unterstützt werden
Sie haben 149 Pakete (8.4%), die bis Mai 2017 (3y) unterstützt werden
Sie haben 41 Pakete (2.3%), die bis Januar 2017 (9m) unterstützt werden
Sie haben 0 Pakete (0.0%), die nicht/nicht mehr heruntergeladen werden können
Sie haben 67 nicht unterstützte Pakete (3.8%)
Nicht mehr herunterzuladen:
Nicht unterstützt:
aspell-de banshee banshee-extension-soundmenu five-or-more
flashplugin-installer four-in-a-row freepats gnome-chess gnome-games
gnome-klotski gnome-nibbles gnome-robots gnome-tetravex gnuchess
gnuchess-book google-chrome-stable gstreamer0.10-fluendo-mp3
gstreamer0.10-gnomevfs gstreamer0.10-plugins-bad
gstreamer0.10-plugins-bad-multiverse gstreamer1.0-fluendo-mp3
gstreamer1.0-plugins-bad gstreamer1.0-plugins-bad-faad
gstreamer1.0-plugins-bad-videoparsers gstreamer1.0-plugins-ugly
gthumb gthumb-data iagno intel-microcode iucode-tool libavcodec-extra
libdbus-glib1.0-cil libdbus1.0-cil libevdev2 libfaac0 libgdata2.1-cil
libgkeyfile1.0-cil libgme0 libgstreamer-plugins-bad0.10-0
libgstreamer-plugins-bad1.0-0 libgtk-sharp-beans-cil libgudev1.0-cil
libmimic0 libmono-zeroconf1.0-cil libnewtonsoft-json5.0-cil
libnotify0.4-cil liboil0.3 libreoffice libreoffice-report-builder-bin
libtaglib2.1-cil libwildmidi-config libwildmidi1 libzbar0 lightsoff
opera-stable pdftk quadrapassel smistrip snmp-mibs-downloader
swell-foop tali testdisk unrar xsane xsane-common
xubuntu-restricted-addons xubuntu-restricted-extras
Ist gleich: ein paar Metapakete, Google Chrome ist selbstverständlich weiterhin unterstützt, genau wie Opera. Dann haben wir noch ein paar Gnome-Spiele... will ja mal sehen, wie sich einer durchs Mahjong-Spiel in mein Internetbanking hackt...
Na ja, da sind immerhin auch gstreamer und libreoffice dabei. D.h. irgendeine Applikation, die aus dem Netz z.B. Videos mit gstreamer verarbeitet, kann schon angreifbar sein.
Oder es wird ein Bug in libreoffice exploitet - das muss nicht mal der geöffnete Anhang sein, es könnte u.U. schon ausreichen, wenn man das Office-Dokument auf der Platte hat und dann nautilus über den thumbnailer-Prozess libreoffice aufruft.
Und ist denn z.B. Gstreamer überhaupt veraltet? Oder einfach nur nicht UNTERSTÜTZT? Der Unterschied ist gewaltig, oder?
Libreoffice: dann müsste der Hacker also erst auf die Platte, durch einige aktuelle/ aktualisierte Pakete, um dann ans ach so verwundbare Libreoffice zu kommen und dann den Nautilus zu hacken... jipp. Genauso wirds laufen
gstreamer selbst ist natürlich nicht veraltet, aber wenn es von Canonical nicht unterstützt wird, heißt es, dass hier ev. Sicherheitsupdates auch nicht den Weg in Ubuntu finden.
Und bei LibreOffice reicht es, z.B. einen Mailanhang zu öffnen bzw. in vom Mailprogramm auf der Platte zu speichern.
Diesen Angriffsvektor finde ich nicht so abwegig, zumal das "auf der Platte speichern" auch per drive-by download passieren kann.
Verharmlosen ist hier die falsche Strategie.
Das Chaos, das aus Deinen hier zitierten Angaben durchlugt, ist ungeheuer.
Was ist denn daran so schwierig, tatsächlich mit Sicherheitsupdates unterstützte Universe- und Multiverse-Software in einem eigenen Repo zusammenzufassen? Dann könnte man bewusst den unsicheren großen Rest meiden.
Ubuntu Main reicht IMO nicht für den Desktop. Der wäre dann genauso "multimediamäßig kastriert" wie Opensuse, Fedora oder RHEL.
Und genau das ist das Schlimme an diesem Obscurity-Schleier, den Canonical letztlich mit über Ubuntu Universe und Multiverse gelegt hat.
IMO wäre Canonical nur dann moralisch und verantwortungstechnisch aus dem Schneider, wenn die Universe- und Multiverse-Repos nicht standardmäßig bereits ab dem ersten Ubuntu-Start aktiviert wären. Genau das sind diese aber.
Es gibt keinen Obscurity-Schleier.
Wie weiter oben schon mehrfach erwähnt wurde, sagt Canonical ganz genau, was mit den Universe und Multiverse Repos los ist. Sie werden von der "Gemeinschaft" betreut. Und wenn da eben keiner aus dieser "Gemeinschaft" da ist, der die Pakete betreut? Wer hat dann den schwarzen Peter? Canonical? Mitnichten!
Die "Gemeinschaft" an sich hat dann den schwarzen Peter. Aber das ist man ja als User gewöhnt: es sind für diese "Gemeinschaft" immer "die anderen" schuld. Und wenn dann mal wieder wie hier dieser ganze Haufen an Selbstgefälligkeit unter solchen Sicherheitslücken zusammenbricht, ist das Gejammer groß... So sieht es nämlich aus. Diese Doppelmoral und Selbstgefälligkeit kotzt mich dermaßen an, das ist einfach unglaublich.
Übrigens bedeutet "unsupported" noch lange nicht, dass das Paket veraltet ist, dass es verwaist ist oder sonstwas. Gerade erst vor 2 Wochen kam ein Schwung Updates für die gstreamer-Pakete in 14.04 rein... wie das, wenn die Pakete ja "Überhaupt gar nicht mehr betreut werden"???
Hier die Ausgabe für ein nagelneues Ubuntu 16.04:
XXX@yyy:~$ ubuntu-support-status --show-unsupported
Zusammenfassung der Unterstützung für 'yyy':
Sie haben 61 Pakete (2.7%), die bis Januar 2017 (9m) unterstützt werden
Sie haben 1651 Pakete (73.6%), die bis April 2021 (5y) unterstützt werden
Sie haben 307 Pakete (13.7%), die bis April 2019 (3y) unterstützt werden
Sie haben 0 Pakete (0.0%), die nicht/nicht mehr heruntergeladen werden können
Sie haben 224 nicht unterstützte Pakete (10.0%)
Nicht mehr herunterzuladen:
Nicht unterstützt:
abiword-plugin-grammar armagetronad armagetronad-common avfs bbpager
bbrun bbtime blackbox blackbox-themes cabextract claws-mail
claws-mail-i18n claws-mail-themes dosbox e17 e17-data emelfm2
emelfm2-svg-icons epiphany-browser epiphany-browser-data eterm
ext3grep ext4magic extundelete fatresize fbpager fbpanel fluxbox
fonts-horai-umefont fonts-wqy-microhei fspanel fvwm fvwm-icons geeqie
geeqie-common gentoo gnome-exe-thumbnailer gnumeric-plugins-extra
gnustep-icons gtk-clearlooks-gperfection2-theme hpanel icewm
icewm-common icewm-themes isomaster java-wrappers libalut0
libapache-pom-java libast2 libatk-wrapper-java
libatk-wrapper-java-jni libbcmail-java libbcpkix-java libbcprov-java
libbt0v5 libcapi20-3 libcapi20-3:i386 libck-connector0
libcommons-codec-java libcommons-httpclient-java
libcommons-logging-java libcommons-parent-java libdom4j-java
libecore-con1 libecore-evas1 libecore-fb1 libecore-file1
libecore-imf1 libecore-input1 libecore-ipc1 libecore-x1 libecore1
libedbus1 libedje-bin libedje1 libeet1 libeeze1 libefreet-bin
libefreet1a libeina1 libeio1 libembryo-bin libembryo1 libetpan17
libevas-loaders libevas1 libevas1-engines-x libfox-1.6-0
libgconf2.0-cil libgnuinet-java libgnumail-java libisoburn1
libitext-java libjaxen-java libjdom1-java libjgoodies-common-java
libjgoodies-looks-java liblink-grammar4 liblog4j1.2-java libmikmod3
libopenjp2-7 libplib1 libqtxdg0 libqupzilla1 librazorqt0 librplay3
libsdl-mixer1.2 libsdl-net1.2 libsdl-sound1.2 libsdl-ttf2.0-0
libsmpeg0 libstroke0 libtorrent-rasterbar8 libuser1 libwings3
libwraster5 libwutil5 libxdo3 libxmmsclient-glib1 libxmmsclient6
libxom-java libxpp2-java libxpp3-java link-grammar-dictionaries-en
ltpanel lxdm lxmusic lxpolkit lxsession-edit mc mc-data menu mupdf
mupdf-tools musescore-soundfont-gm nmapsi4 obconf-qt obmenu
openbox-menu openjdk-9-jre openjdk-9-jre-headless p7zip pdfchain
pdfgrep pdfmod pdfresurrect pdfsam pdfshuffler pdftk pxlib1
python-libtorrent python-nmap python-pdfminer python-poppler
python-pygame python-pypdf python3-nmap qpdfview qpdfview-djvu-plugin
qpdfview-ps-plugin qpdfview-translations qupzilla razorqt
razorqt-appswitcher razorqt-autosuspend razorqt-config
razorqt-confupdate razorqt-data razorqt-desktop
razorqt-globalkeyshortcuts razorqt-lightdm-greeter
razorqt-notificationd razorqt-openssh-askpass razorqt-panel
razorqt-policykit-agent razorqt-power razorqt-runner razorqt-session
scribus-doc spacefm spacefm-common timgm6mb-soundfont torcs
torcs-data torcs-data-cars torcs-data-tracks
ttf-mscorefonts-installer ttf-wqy-microhei
ubuntu-packaging-guide-pdf-de ufraw-batch umit usermode viewnior wdm
wine wine-gecko2.21 wine-gecko2.21:i386 wine-mono0.0.8 wine1.6
wine1.6-amd64 wine1.6-i386:i386 winetricks wm-icons wmaker
wmaker-common wmaker-data worker worker-data xarchiver xdotool xfe
xfe-i18n xfe-themes xfonts-100dpi xfonts-terminus xmms2-core
xmms2-plugin-alsa xmms2-plugin-flac xmms2-plugin-id3v2
xmms2-plugin-mad xmms2-plugin-speex xmms2-plugin-vorbis xorriso
zenmap
Man schaue sich einmal die Anzahl und die Namen der bereits im ersten Monat der Ubuntu 16.04-Existenz nicht mehr unterstützten Pakete an (u.a. Claws-Mail, Epiphany-Webbrowser, Wine, Dosbox, Midnight Commander, Qpdfview, Mupdf, Pdfmod, praktisch alle Nmap-GUIs): 224 nicht mehr unterstützte Pakete, 10% der gesamten Paketinstallation.
Bei der Installation der nicht mehr unterstützen Pakete gab es keinen einzigen Hinweis. So steht unter Epiphany-Browser Folgendes zu den Betreuern:
Ubuntu Developers (...).
Wenn das heißen soll, dass dieses Paket bereits jetzt nicht mehr unterstützt ist, dann erinnert mich diese Angabe ganz klar an ein Potemkinsches Dorf. Das Paket Claws-Mail hat den gleichen Pseudo-Maintainer.
Das in Ubuntu Main befindliche Paket Gcc5 hat demgegenüber folgenden theoretischen Betreuer:
Ubuntu Core Developers (...).
Man achte auf den feinen Unterschied.
Beim Thunar-Paket, das von Xubuntu unterstützt wird, steht dabei als Betreuer:
Xubuntu Developers (...).
IMO heißt das somit, dass die Angabe, dass die Betreuer u.a. von Epiphany-Browser und Claws-Mail Ubuntu Developers (...) seien, IMO einen reinen Fake darstellt, da es sich hierbei um eine klare Falschangabe handelt. Bei den nicht unterstützten Paketen wie Epiphany-Browser und Claws-Mail müsste stehen: Not Supported oder Unmaintained. Nur das ist in diesem Zusammenhang eine korrekte Angabe.
Hinweis: (...) steht für die jeweilige in Klammern angegebene Mailinglist-Adresse der angegebenen Maintainer.
(quote) wine wine-gecko2.21 wine-gecko2.21:i386 wine-mono0.0.8 wine1.6
wine1.6-amd64 wine1.6-i386:i386 winetricks wm-icons wmaker (/quote)
Nicht mehr unterstützt = veraltet! Nicht mehr aktuell.
Bei mir sind es knapp 12 Prozent ...
Wow, da hast du ja einen Skandal aufgedeckt... Watergate ist ein Scheißdreck dagegen.
Ich werde dich für den diesjährigen Pulitzerpreis vorschlagen.
Wenn ich oben die Terminalausgabe und die zugehörigen Befehle nicht gepostet hätte, wärst du gar nicht drauf gekommen... So sieht es in Wahrheit aus.
Keiner von Euch hat sich mit Ruhm bekleckert.
Hat sich irgendjemand von Euch denn jemals gefragt, ob ubuntu-support-status überhaupt korrekte Daten ausspuckt?
Schau(t) einmal hier:
https://bugs.launchpad.net/ubuntu/+source/update-manager/+bug/1574670
"ubuntu-support-status returns inaccurate information"
Offenbar hat auch heise.de nicht bei Ubuntu bzw. Canonical nachgefragt, was dieses angeblich gebrochene LTS-Versprechen denn eigentlich soll. Dann hätte man vielleicht darauf kommen können.
Das ist etwa so, als wenn alle hier leidenschaftlich über einen Text diskutieren würden, den aber niemand zuvor überhaupt gelesen hat.
denn was Canonical nämlich ungesagt lässt ist, dass ein bekanntes Sicherheitsproblem von grafischen Linux-Anwendungen auch bei Snap besteht: Grafische Anwendungen können die Tastatureingaben und Daten anderer Programme abgreifen, die zur gleichen Zeit unter dem X-Server laufen. Da die Desktop-Ausgabe von Ubuntu 16.04 auf diese Art die Bedienoberfläche ausgibt, ist die Abschottung von Snap-Programmen so gut wie gar nicht gegeben. Anders sieht es mit dem X11-Nachfolger Mir aus, der auf den Mobile-Versionen von Ubuntu zum Einsatz kommt. Deren Verbreitung ist im Vergleich mit den Desktop- und Server-Ausgaben von Ubuntu allerdings zu vernachlässigen.
Einige Distributionen erschweren diesen Angriffsweg mit SELinux – Ubuntu aber nicht. Eine generelle Lösung für diese Sicherheitsproblematik für alle Linux-Distributionen ist aber in Sicht: Die von der Mehrheit der Linux-Entwickler als X11-Nachfolger designierte Software Wayland löst das Problem ebenso wie der Konkurrent Mir, den Canonical im Alleingang vorantreibt. Auch entwickelt das Gnome-Projekt mit den xdg-apps eine Technik, welche sehr ähnliche Ziele hat wie Snap und sich breiter Unterstützung unter jenen Linux-Entwicklern erfreut, die nicht an Ubuntu arbeiten.
Quelle heise.de