ubuntuusers.de

tomtomtom schrieb:

apt-ghetto schrieb:

Das stimmt nicht in allen Fällen. Beispielsweise ist Kernel 3.13 kein Longtermkernel, wird aber von Canonical 5 Jahre lang mit Sicherheitsaktualisierungen versehen.

Bestätigt also genau das geschriebene...

Nein, das bestätigt also nicht genau das geschriebene...

Das Upstream-Projekt legt den Supportzeitraum seiner Software fest. Punkt, aus.

Der Supportzeitraum von 5 Jahren für die Software "Kernel 3.13" wurde von Canonical festgelegt. Also nicht vom Upstream-Projekt. Es sei denn du verwendest den vanilla-Kernel von kernel.org, also aus einer Fremdquelle.

Will die Distribution diese trotzdem länger nutzen, muss sie sie selbst supporten.

Diesen Zeitraum nennt wahrscheinlich die Mehrheit Supportzeitraum. Aber du kannst das gerne anders halten.

An der Supportzeit des Upstream-Projekts ändert das nicht das geringste.

Wurde von mir auch nirgends behauptet.

apt-ghetto schrieb:

Nein, das bestätigt also nicht genau das geschriebene...

Bin gespannt auf die Argumente. 😉

Der Supportzeitraum von 5 Jahren für die Software "Kernel 3.13" wurde von Canonical festgelegt.

Falsch. Der Kernel kommt von https://www.kernel.org/, die legen den Supportzeitraum fest.

Canonical kann festlegen, das SIE in IHRER Distribution länger Sicherheitsaktualisierungen einpflegen als das Upstream-Projekt dies tut. Dies tangiert aber weder die Upstream-Software noch andere Distributionen.

Und es verlängert auch nicht die Supportlaufzeit des Kernels generell...

Diesen Zeitraum nennt wahrscheinlich die Mehrheit Supportzeitraum. Aber du kannst das gerne anders halten.

Niemand, der sich ernsthaft mit dem Thema beschäftigt, wird den Zeitraum, den IRGENDEINE Linux-Distribution entgegen dem Upstream-Projekt als Supportzeitraum nenn,t als Supportzeitraum der Upstream-Software bezeichnen.

An der Supportzeit des Upstream-Projekts ändert das nicht das geringste.

Wurde von mir auch nirgends behauptet.

Du hast als Antwort darauf, dass das Upstream-Projekt den Supportzeitraum der Software festlegt geantwortet, dass das nicht der Fall ist, weil Canonical den Kernel länger unterstützt.

Ergo wurde dies insoweit schon.

tomtomtom schrieb:

apt-ghetto schrieb:

Nein, das bestätigt also nicht genau das geschriebene...

Bin gespannt auf die Argumente. 😉

Ich habe nur das gleiche geschrieben wie du. Ohne Angabe von irgendwelchen Argumenten, genau so wie du.

Der Supportzeitraum von 5 Jahren für die Software "Kernel 3.13" wurde von Canonical festgelegt.

Falsch. Der Kernel kommt von https://www.kernel.org/, die legen den Supportzeitraum fest.

Ich bekomme meinen Kernel wahrscheinlich von http://security.ubuntu.com/ubuntu/pool/main/.

Canonical kann festlegen, das SIE in IHRER Distribution länger Sicherheitsaktualisierungen einpflegen als das Upstream-Projekt dies tut. Dies tangiert aber weder die Upstream-Software noch andere Distributionen.

Wo habe ich anderes behauptet?

Und es verlängert auch nicht die Supportlaufzeit des Kernels generell...

Lustigerweise wird Kernel 3.13 aus den Ubuntuquellen dennoch 5 Jahre lang unterstützt. Und lustigerweise geht es genau um den Kernel aus den Ubuntuquellen.

Diesen Zeitraum nennt wahrscheinlich die Mehrheit Supportzeitraum. Aber du kannst das gerne anders halten.

Niemand, der sich ernsthaft mit dem Thema beschäftigt, wird den Zeitraum, den IRGENDEINE Linux-Distribution entgegen dem Upstream-Projekt als Supportzeitraum nenn,t als Supportzeitraum der Upstream-Software bezeichnen.

Habe ich auch nirgendwo geschrieben.

An der Supportzeit des Upstream-Projekts ändert das nicht das geringste.

Wurde von mir auch nirgends behauptet.

Du hast als Antwort darauf, dass das Upstream-Projekt den Supportzeitraum der Software festlegt geantwortet, dass das nicht der Fall ist, weil Canonical den Kernel länger unterstützt.

Also wurden die 5 Jahre Support für den Kernel aus den Ubunturepos von kernel.org festgelegt? Oder wurden die 5 Jahre Support für Kernel 3.13 von Canonical festgelegt?

Ergo wurde dies insoweit schon.

Ich habe geschrieben, dass Kernel 3.13 5 Jahre lang von Canonical Support erhält, obwohl er im Upstream-Projekt kein Langzeitsupport erhält.

apt-ghetto schrieb:

Ich habe nur das gleiche geschrieben wie du. Ohne Angabe von irgendwelchen Argumenten, genau so wie du.

Dann lies nochmal, was ich geschrieben habe. Und beschäftige dich damit, was Upstream-Software ist und in welchem Verhältnis sie zu den Distributionen steht, die sie nutzen. Scheint dir nicht geläufig zu sein...

Ich bekomme meinen Kernel wahrscheinlich von http://security.ubuntu.com/ubuntu/pool/main/.

Und du hast immernoch nicht verstanden, wo der Unterschied zwischen der von Upstream ausgelieferten und der von Distributionen verwendeten Software ist, wie es scheint.

Wo habe ich anderes behauptet?

Siehe oben.

Habe ich auch nirgendwo geschrieben.

Seltsam, das ich das, was du dann nie geschrieben hast, zitieren konnte.

Also wurden die 5 Jahre Support für den Kernel aus den Ubunturepos von kernel.org festgelegt? Oder wurden die 5 Jahre Support für Kernel 3.13 von Canonical festgelegt?

Das wurde bereits mehrfach erklärt, bitte lesen.

Das Upstream-Projekt legt den Supportzeitraum fest, fertig aus. Die Distributionen können darüber hinaus selber noch Support leisten, das ist aber eben nicht der Supportzeitraum des Upstream-Projektes und auch nicht der Support für die Upstream-Software.

Ich habe geschrieben, dass Kernel 3.13 5 Jahre lang von Canonical Support erhält, obwohl er im Upstream-Projekt kein Langzeitsupport erhält.

Du hast behauptet, dass für Kernel 3.13 nicht das Upstream-Projekt, sondern Canonical den Supportzeitraum festlegt.

Und das ist schlechtweg falsch.

zephir schrieb:

k1l schrieb:

Wie man reinen Gewissens Mint empfehlen kann, kann ich echt nicht nachvollziehen. Von Seite gehackt und Downloads ausgetauscht zu Sicherheitsupdates absichtlich zurückhalten weil das Update inkompatibel zu den eigenen Änderungen ist und das Team zu klein um es zeitnah anzupassen.

Sicherheitsupdates zurückhalten ist in der Tat ein nogo, wenn das immer noch so ist, wäre das das erste Argument gegen Mint was ich nachvollziehen kann. Nach meinem bisherigem Kenntnisstand setzt Mint einfach nur auf die Ubuntu Quellen und bieten nur wenige eigen Pakete aus anderen Quellen an. Damit unterscheidet es sich dann nicht groß von den offiziellen Ubuntu Derivaten, die meist auch nur von sehr wenigen Personen gepflegt werden und meist auch keinen LTS Support genießen.

Definitiv falsch. Mint hält wie beschrieben einige Pakete zurück aus den ubuntu repos, da sie sonst ihr Paket-Setup mit ihren eigenen extra Quellen kaputt machen würde. (Werden mittlerweile Kernel updates per default eingespielt oder muss man das immer noch erst händisch einstellen?)
Die offiziellen ubuntu Derivate liefern alle Pakete nur aus den ubuntu Quellen aus. Die werden dann teilweise nur von einem Community Team gepflegt und haben nicht 5 Jahre Support (so wie die Pakete im ubuntu Main Repo), aber sie halten keine Updates zurück, weil sie ja schon im Repo getestet werden.

Das die Website mal gehackt worden ist, ist unschön, aber wie oft lädt man da schon was runter? maximal einmal das ISO, wenn man das nicht ohnehin per torrent zieht. Und die Prüfsumme überprüft man eh nochmal. Oder geht es um Mint spezifische Paketquellen? Das wäre in der tat übel.

Du gibst jemandem root zu deinem System (denn das ist was eine Distributor hat. Er kann dir per Update Pakete beliebig unterjubeln mit beliebigem Code drin), der einen so laxen Umgang mit Sicherheit hat? Und die Prüfsummen prüft niemand. Gerade nicht der neue User, der von chip.de den "Linux Mint ist so geiles Hacker Linux" Artikel gelesen hat.

Ich kann trotzdem ehrlich gesagt nicht so ganz verstehen, warum man hier nicht einen Forenbereich inoffizielle Ubuntu Derivate dulden kann. Hier wird doch niemand von Canonical bezahlt?

Das hat mit Canonical doch nichts zu tun. (Auch wenn Celement Levebvre einen sehr großen Sack an Spenden monatlich einsammelt, sei ihm das gegönnt als jemand der Open-Source weiter bringt)\\ Mint hat eine Lizenz von Canonical, die ubuntu Pakete samt Trademark und die Infrastruktur zu nutzen. Mint hat sich von Anfang an selbst als eigenständiger Distributor hingestellt. Es wollte nicht nur ein Wallbuntu sein.

Frieder108 schrieb:

Aber unabhängig davon, was ich seit Jahren nicht verstehe und mir auch niemand schlüssig erklären konnte, ist das mit den Supportzeiten.

das ist eine gute Frage. Denn die Pakete in den ubuntu universe Repos haben ja von den ubuntu flavor teams (kubuntu, xubuntu, lubuntu,..) ja nur 3 Jahre Support. Also entweder hat Mint da größere Teams und überschreibt die Pakete mit eigenen Repos, oder die Ansage ist falsch.

• Cinnamon - ja gut, wem das gefällt und es nutzen will, der ist bei Mint wahrscheinlich am besten untergebracht (m.E ist Cinnamon aber nur ein Nachbau von KDE/Plasma) → ist deren Flaggschiff und damit geben sie sich auch Mühe.

Cinnamon ist deren gnome3-shell-Umbau im gnome2 look. Die müssen da nur eine Menge ändern und kommen nicht immer mit dem orginal gnome mit. Das war mal so schlimm, dass sie da aus debian und ubuntu Repos rausgeflogen sind (ubuntu musste Ähnliches ja für unity machen hatte da aber einen großen Sack an Entwicklern für bezahlt). Ist zur Zeit aber wohl wieder besser. Mit KDE Plasma hat das eher weniger zu tun.

k1l schrieb:

(Werden mittlerweile Kernel updates per default eingespielt oder muss man das immer noch erst händisch einstellen?)

Der "aktuelle" Kernel in den Mint-Repos ist ein Metapaket, das den 4.8.0-53er Kernel aus den Ubuntu-Repos vom 17.05.2017 festtackert.

das ist eine gute Frage. Denn die Pakete in den ubuntu universe Repos haben ja von den ubuntu flavor teams (kubuntu, xubuntu, lubuntu,..) ja nur 3 Jahre Support. Also entweder hat Mint da größere Teams und überschreibt die Pakete mit eigenen Repos, oder die Ansage ist falsch.

Als ich mir das zuletzt angesehen habe hatten die an "ihren" KDE- und Xfce-Quellen überhaupt nichts gemacht, sondern einfach PPAs von anderen Anbietern dafür eingebunden.

EDIT:

Einfach mal nachgesehen...

Mint-18.2-KDE:

mkdir mintiso mintsfs
wget http://mirror.bauhuette.fh-aachen.de/linuxmint-cd/stable/18.2/linuxmint-18.2-kde-64bit.iso 

--2017-09-11 23:20:21--  http://mirror.bauhuette.fh-aachen.de/linuxmint-cd/stable/18.2/linuxmint-18.2-kde-64bit.iso
Auflösen des Hostnamens mirror.bauhuette.fh-aachen.de… 149.201.240.100
Verbindungsaufbau zu mirror.bauhuette.fh-aachen.de|149.201.240.100|:80 … verbunden.
HTTP-Anforderung gesendet, auf Antwort wird gewartet … 200 OK
Länge: 2005401600 (1,9G) [application/octet-stream]
Wird in »linuxmint-18.2-kde-64bit.iso« gespeichert.

linuxmint-18.2-kde-64bit.iso            100%[============================================================================>]   1,87G  10,2MB/s    in 3m 11s  

2017-09-11 23:23:33 (9,99 MB/s) - »linuxmint-18.2-kde-64bit.iso« gespeichert [2005401600/2005401600]

mount -o loop linuxmint-18.2-kde-64bit.iso mintiso 

mount: /root/mintiso: WARNUNG: das Gerät ist schreibgeschützt und wird daher im Nur-Lese-Modus eingehängt.

mount -t squashfs mintiso/casper/filesystem.squashfs mintsfs/
egrep -e deb mintsfs/etc/apt/sources.list.d/* 

(Die sources.list selbst ist bei Mint leer.)

mintsfs/etc/apt/sources.list.d/official-package-repositories.list:deb http://packages.linuxmint.com sonya main upstream import backport #id:linuxmint_main
mintsfs/etc/apt/sources.list.d/official-package-repositories.list:deb http://archive.ubuntu.com/ubuntu xenial main restricted universe multiverse
mintsfs/etc/apt/sources.list.d/official-package-repositories.list:deb http://archive.ubuntu.com/ubuntu xenial-updates main restricted universe multiverse
mintsfs/etc/apt/sources.list.d/official-package-repositories.list:deb http://archive.ubuntu.com/ubuntu xenial-backports main restricted universe multiverse
mintsfs/etc/apt/sources.list.d/official-package-repositories.list:deb http://security.ubuntu.com/ubuntu/ xenial-security main restricted universe multiverse
mintsfs/etc/apt/sources.list.d/official-package-repositories.list:deb http://archive.canonical.com/ubuntu/ xenial partner
mintsfs/etc/apt/sources.list.d/ubuntu-defaults.list:deb http://ppa.launchpad.net/kubuntu-ppa/backports/ubuntu xenial main

umount mintsfs mintiso
rm linuxmint-18.2-kde-64bit.iso 

Mint-18.2-Xfce:

wget http://mirror.netcologne.de/linuxmint/iso/stable/18.2/linuxmint-18.2-xfce-64bit.iso 

--2017-09-11 23:27:17--  http://mirror.netcologne.de/linuxmint/iso/stable/18.2/linuxmint-18.2-xfce-64bit.iso
Auflösen des Hostnamens mirror.netcologne.de… 194.8.197.22, 2001:4dd0:1234:1::deb
Verbindungsaufbau zu mirror.netcologne.de|194.8.197.22|:80 … verbunden.
HTTP-Anforderung gesendet, auf Antwort wird gewartet … 200 OK
Länge: 1647968256 (1,5G) [application/octet-stream]
Wird in »linuxmint-18.2-xfce-64bit.iso« gespeichert.

linuxmint-18.2-xfce-64bit.iso           100%[============================================================================>]   1,53G  10,3MB/s    in 2m 37s  

2017-09-11 23:29:54 (10,0 MB/s) - »linuxmint-18.2-xfce-64bit.iso« gespeichert [1647968256/1647968256]

mount -o loop linuxmint-18.2-xfce-64bit.iso mintiso/ 

mount: /root/mintiso: WARNUNG: das Gerät ist schreibgeschützt und wird daher im Nur-Lese-Modus eingehängt.

mount -t squashfs mintiso/casper/filesystem.squashfs mintsfs/
egrep -e deb mintsfs/etc/apt/sources.list.d/* 

deb http://packages.linuxmint.com sonya main upstream import backport #id:linuxmint_main
deb http://archive.ubuntu.com/ubuntu xenial main restricted universe multiverse
deb http://archive.ubuntu.com/ubuntu xenial-updates main restricted universe multiverse
deb http://archive.ubuntu.com/ubuntu xenial-backports main restricted universe multiverse
deb http://security.ubuntu.com/ubuntu/ xenial-security main restricted universe multiverse
deb http://archive.canonical.com/ubuntu/ xenial partner

Also hier keine andere Quelle für Xfce, dafür kommen aber einige Xfce-Bestandteile hier aus dem Mint-Repo.

Hallo!

Vielleicht noch mal ein Hinweis, wie das mit den Aktualisierungen zunächst so läuft bei Mint. Nach Neuinstallation erscheint folgendes Menü zur Auswahl. Es gibt also schon eine Auswahl, was man auch immer von Prozedere, Wortwahl und Voreinstellung halten mag.

Ali_As schrieb:

Vielleicht noch mal ein Hinweis, wie das mit den Aktualisierungen zunächst so läuft bei Mint. Nach Neuinstallation erscheint folgendes Menü zur Auswahl:

Also ist die Einstellung, wichtige Sicherheitsupdates zurückzuhalten, weiterhin der Standard.

Ja klar, wenn man nichts verändert! M.E. hatten die das bei früheren Versionen aber (so prominent) noch nicht. Am Konstrukt als solches änderts aber halt eh nix!

tomtomtom schrieb:

apt-ghetto schrieb:

Ich habe nur das gleiche geschrieben wie du. Ohne Angabe von irgendwelchen Argumenten, genau so wie du.

Dann lies nochmal, was ich geschrieben habe.

Leider ist das schwierig. Du vergleichst Äpfel mit Birnen und behauptest dann, dass ich dieses oder jenes behauptet habe. Dann schreibe ich, dass ich das gar nicht so geschrieben habe und dann meinst du, dass du das zitieren konntest. Allerdings finde ich das Zitat dann nicht. Auf Nachfragen weichst du leider auch aus.

Und beschäftige dich damit, was Upstream-Software ist und in welchem Verhältnis sie zu den Distributionen steht, die sie nutzen. Scheint dir nicht geläufig zu sein...

Erklär es doch kurz. Ist immer gut, auch mal eine völlig andere Sichtweise zu sehen.

Ich bekomme meinen Kernel wahrscheinlich von http://security.ubuntu.com/ubuntu/pool/main/.

Und du hast immernoch nicht verstanden, wo der Unterschied zwischen der von Upstream ausgelieferten und der von Distributionen verwendeten Software ist, wie es scheint.

Ich bezweifle sehr stark, dass Ubuntu den vanilla-Kernel ausliefert.

Wo habe ich anderes behauptet?

Siehe oben.

Wie weit oben? Du kannst es ja auch einfach zitieren. Und bitte vergrössere Dinge, die du zwischen den Zeilen liest.

Habe ich auch nirgendwo geschrieben.

Seltsam, das ich das, was du dann nie geschrieben hast, zitieren konnte.

Seltsam, dass das Zitat hier nicht angezeigt wird.

Also wurden die 5 Jahre Support für den Kernel aus den Ubunturepos von kernel.org festgelegt? Oder wurden die 5 Jahre Support für Kernel 3.13 von Canonical festgelegt?

Das wurde bereits mehrfach erklärt, bitte lesen.

Würde ich ja gerne lesen, aber ich sehe deine Antwort auf meine Fragen nicht.

Das Upstream-Projekt legt den Supportzeitraum fest, fertig aus. Die Distributionen können darüber hinaus selber noch Support leisten, das ist aber eben nicht der Supportzeitraum des Upstream-Projektes und auch nicht der Support für die Upstream-Software.

Habe ich auch weiterhin nirgendwo behauptet. Aber hier sieht man sehr deutlich, dass du Äpfel mit Birnen vergleichst.

Ich habe geschrieben, dass Kernel 3.13 5 Jahre lang von Canonical Support erhält, obwohl er im Upstream-Projekt kein Langzeitsupport erhält.

Du hast behauptet, dass für Kernel 3.13 nicht das Upstream-Projekt, sondern Canonical den Supportzeitraum festlegt.

Stimmt ja auch für den Kernel aus den Ubuntuquellen. Und um den Kernel aus den Ubuntuquellen geht es ja auch. Aber das habe ich ja auch schon mal geschrieben.

Und das ist schlechtweg falsch.

Fassen wir also deine Theorie zusammen: Das Upstream-Projekt legt den Supportzeitraum fest (fertig, aus). Infolgedessen ist Kernel 3.13 also seit Jahren EOL, erhält keine Sicherheitsaktualisierungen mehr und Canonical lügt seine Kunden an.

Fassen wir meine Theorie zusammen: Canonical entscheidet, dass Kernel 3.13 während fünf Jahren Support erhält. Und Canonical liefert weiterhin Kernel 3.13 mit Sicherheitsaktualisierungen aus.

Jetzt müssen wir nur noch nachprüfen, ob in einem Ubuntu 14.04.1 zwischen EOL des Upstream-Kernels bis April 2019 Sicherheitsaktualisierungen für Kernel 3.13 ausgeliefert werden oder nicht. Wenn dir die Antwort dann nicht passt, dann wird einfach wieder irgendein anderes Argument ins Feld geführt und munter behauptet, ich hätte sowieso irgendetwas anderes behauptet und ich solle mal lesen und die Antwort wurde schon "oben" gegeben und ich verstehe es ja sowieso nicht.

apt-ghetto schrieb:

Leider ist das schwierig. Du vergleichst Äpfel mit Birnen und behauptest dann, dass ich dieses oder jenes behauptet habe.

Na dann schauen wir doch mal:

apt-ghetto schrieb:

tomtomtom schrieb:

da frag ich mich dann, warum sich die Plasma und XFCE Macher nicht einfach dran hängen und auch 5 Jahre Support anbieten? 😇

Das Upstream-Projekt legt den Supportzeitraum seiner Software fest, nicht die Distribution, die die Software nutzt.

Das stimmt nicht in allen Fällen. Beispielsweise ist Kernel 3.13 kein Longtermkernel, wird aber von Canonical 5 Jahre lang mit Sicherheitsaktualisierungen versehen.

Zu zitierst also den Satz, dass das Upstream den Supportzeitraum seiner Software festlegt, und darunter schreibst du das dies nicht immer stimme und bringst ein Beispiel, in dem du meinst das es nicht so ist (was nicht der Fall ist).

apt-ghetto schrieb:

Erklär es doch kurz.

Habe ich, mehrmals. In diesem Thread. Suchmaschinen dürften dir auch ein Begriff sein.

Ist immer gut, auch mal eine völlig andere Sichtweise zu sehen.

Du meinst deine exklusive?

Ich bezweifle sehr stark, dass Ubuntu den vanilla-Kernel ausliefert.

Wurde auch nicht behauptet. Man sollte schon lesen, was geschrieben wurde. Vor allem auch den Zusammenhang...

Seltsam, dass das Zitat hier nicht angezeigt wird.

Siehe oben. Jetzt also schon zweimal zitiert, obwohl du es nicht geschrieben hast.

Würde ich ja gerne lesen, aber ich sehe deine Antwort auf meine Fragen nicht.

Zur Not halt mit Brille lesen.

Habe ich auch weiterhin nirgendwo behauptet. Aber hier sieht man sehr deutlich, dass du Äpfel mit Birnen vergleichst.

Siehe das Zitat oben, indem du genau das behauptet hast.

Fassen wir also deine Theorie zusammen: Das Upstream-Projekt legt den Supportzeitraum fest (fertig, aus).

Das ist keine Theorie, sondern eine Tatsache. Liegt daran, dass das Upstream-Projekt über den Support für seine Software bestimmt und sonst niemand. Weil es niemand kann außer dem Upstream-Projekt...

Infolgedessen ist Kernel 3.13 also seit Jahren EOL, erhält keine Sicherheitsaktualisierungen mehr und Canonical lügt seine Kunden an.

Nein, lesen und verstehen. Und Grundlagen über das Thema, über das man diskutieren will, aneignen, wäre auch praktisch.

Das Upstream-Projekt unterstützt den Kernel bis zu dessen EOL. Jeder Distribution kann jetzt den Kernel bei sich länger supporten, aber eben nicht die Upstream-Software. Bis zum EOL können sie die vom Upstream-Projekt bereitgestellten Patches und Fixes benutzen, nach dem EOL müssen sie diese aus neueren Kernelversionen rückportieren.

All das wird nur für die innerhalb der Distribution genutzte Software getan und kommt nirgendwo sonst hin. Es ändert weder etwas am Supportzeitraum der Upstream-Software noch legt es diesen in irgendeiner Weise anderweitig fest.

Jetzt müssen wir nur noch nachprüfen, ob in einem Ubuntu 14.04.1 zwischen EOL des Upstream-Kernels bis April 2019 Sicherheitsaktualisierungen für Kernel 3.13 ausgeliefert werden oder nicht.

Es gibt kein Ubuntu 14.04.1, in dem man sowas feststellen könnte. Das existiert ausschließlich auf den damaligen Installationsdatenträgern. Sobald Aktualisierungen eingespielt werden wird ein 14.04.1 zu einem 14.04.5. Wieder so absolute Grundlagen...

Der Rest des Satzes zeigt wieterhin, dass du nicht verstanden hast, worum es geht.

Wenn dir die Antwort dann nicht passt, dann wird einfach wieder irgendein anderes Argument ins Feld geführt und munter behauptet, ich hätte sowieso irgendetwas anderes behauptet und ich solle mal lesen und die Antwort wurde schon "oben" gegeben und ich verstehe es ja sowieso nicht.

Jeder - auch du selbst - kann nachlesen, was du hier geschrieben hast. Das braucht man nicht "behaupten", man kann es nachlesen.

Auch ist das nicht dermaßen viel, dass es dich überfordern dürfte, deine Beiträge in diesem Thread und die Antworten darauf zu lesen.

swkh schrieb:

Evangelisationsversuche gegenüber Mint-Usern so überflüssig wie ein Kropf. Gleiches gilt für die verbreitete Praxis, Mint-User hier gnadenlos "vor die Tür zu setzen".

Da liegt ein gewisser Widerspruch in Ihrem Post.

Ihr zweites trifft zu.

Denn hier wehrt man sich gegen die Ansprüche anderer Distris.

apt-ghetto schrieb:

Ausserdem müssten sich allfällige Supporter Wissen zu zwei Distributionen aneignen.

Das wäre nicht erfolgversprechend.

tomtomtom schrieb:

apt-ghetto schrieb:

Leider ist das schwierig. Du vergleichst Äpfel mit Birnen und behauptest dann, dass ich dieses oder jenes behauptet habe.

Na dann schauen wir doch mal:

apt-ghetto schrieb:

tomtomtom schrieb:

da frag ich mich dann, warum sich die Plasma und XFCE Macher nicht einfach dran hängen und auch 5 Jahre Support anbieten? 😇

Das Upstream-Projekt legt den Supportzeitraum seiner Software fest, nicht die Distribution, die die Software nutzt.

Das stimmt nicht in allen Fällen. Beispielsweise ist Kernel 3.13 kein Longtermkernel, wird aber von Canonical 5 Jahre lang mit Sicherheitsaktualisierungen versehen.

Zu zitierst also den Satz, dass das Upstream den Supportzeitraum seiner Software festlegt, und darunter schreibst du das dies nicht immer stimme und bringst ein Beispiel, in dem du meinst das es nicht so ist (was nicht der Fall ist).

Steht im Wiki allerdings nicht so: LTS Enablement Stacks

apt-ghetto schrieb:

Erklär es doch kurz.

Habe ich, mehrmals. In diesem Thread. Suchmaschinen dürften dir auch ein Begriff sein.

Erkärt hast du nichts.

Ist immer gut, auch mal eine völlig andere Sichtweise zu sehen.

Du meinst deine exklusive?

Ich kenne meine eigene Sichtweise. Ich verstehe nur deine nicht.

Ich bezweifle sehr stark, dass Ubuntu den vanilla-Kernel ausliefert.

Wurde auch nicht behauptet. Man sollte schon lesen, was geschrieben wurde. Vor allem auch den Zusammenhang...

Implizit schon. Aber hier scheinst du ja doch begriffen zu haben, dass Ubuntu Kernel 3.13 ausliefert und dementsprechend auch den Supportzeitraum von Kernel 3.13 definiert.

Seltsam, dass das Zitat hier nicht angezeigt wird.

Siehe oben. Jetzt also schon zweimal zitiert, obwohl du es nicht geschrieben hast.

Schade, dass dein Moment der Klarheit bereits wieder vorüber ist.

Würde ich ja gerne lesen, aber ich sehe deine Antwort auf meine Fragen nicht.

Zur Not halt mit Brille lesen.

Ich sehe die Antwort immer noch nicht. (Allerdings muss ich zugeben, dass ich momentan Kontaktlinsen trage)

Habe ich auch weiterhin nirgendwo behauptet. Aber hier sieht man sehr deutlich, dass du Äpfel mit Birnen vergleichst.

Siehe das Zitat oben, indem du genau das behauptet hast.

Oh, schön. Auch hier ein Äpfel-Birnen-Vergleich.

Fassen wir also deine Theorie zusammen: Das Upstream-Projekt legt den Supportzeitraum fest (fertig, aus).

Das ist keine Theorie, sondern eine Tatsache. Liegt daran, dass das Upstream-Projekt über den Support für seine Software bestimmt und sonst niemand. Weil es niemand kann außer dem Upstream-Projekt...

Ja, das kann bei Open-Source-Software ja niemand. Vor allem Canonical kann den Kernel-Code vom Upsream-Projekt nicht anpassen und kann auch selbst keine Sicherheitsaktualisierungen einpflegen. Da hast du völlig recht, sowas ist völlig unmöglich.

Infolgedessen ist Kernel 3.13 also seit Jahren EOL, erhält keine Sicherheitsaktualisierungen mehr und Canonical lügt seine Kunden an.

Nein, lesen und verstehen. Und Grundlagen über das Thema, über das man diskutieren will, aneignen, wäre auch praktisch.

Komisch, jetzt ist deine Theorie doch wieder nicht richtig.

Das Upstream-Projekt unterstützt den Kernel bis zu dessen EOL. Jeder Distribution kann jetzt den Kernel bei sich länger supporten, aber eben nicht die Upstream-Software. Bis zum EOL können sie die vom Upstream-Projekt bereitgestellten Patches und Fixes benutzen, nach dem EOL müssen sie diese aus neueren Kernelversionen rückportieren.

Und wieder ein Moment der Klarheit. Schön, dass du sie auch ab und zu wieder hast. Ich habe nie behauptet, dass das nicht so läuft. Allerdings ist es die Pflicht von Canonical, diese Patches anzupassen, einzupflegen und auszuliefern. Das Upstream-Projekt ist nicht dafür verantwortlich.

All das wird nur für die innerhalb der Distribution genutzte Software getan und kommt nirgendwo sonst hin. Es ändert weder etwas am Supportzeitraum der Upstream-Software noch legt es diesen in irgendeiner Weise anderweitig fest.

Und auch hier habe ich nie etwas anderes behauptet.

Jetzt müssen wir nur noch nachprüfen, ob in einem Ubuntu 14.04.1 zwischen EOL des Upstream-Kernels bis April 2019 Sicherheitsaktualisierungen für Kernel 3.13 ausgeliefert werden oder nicht.

Es gibt kein Ubuntu 14.04.1, in dem man sowas feststellen könnte. Das existiert ausschließlich auf den damaligen Installationsdatenträgern. Sobald Aktualisierungen eingespielt werden wird ein 14.04.1 zu einem 14.04.5. Wieder so absolute Grundlagen...

Hmmm: LTS Enablement Stacks

Kann von euch beiden jeder mal in einem Satz ausdrücken was er denn aussagen möchte?

HasserDesErfolges schrieb:

Denn hier wehrt man sich gegen die Ansprüche anderer Distris.

Äääh, "Ansprüche" hat hier eh keiner. Selbst als Ubuntunutzer nicht. Wenn keine Antwort kommt, kommt halt keine! Basta! Unabhängig davon, ob die Ausgrenzung anderer BS sinnvoll ist oder nicht.

L.G.