tomtomtom
Supporter
Anmeldungsdatum: 22. August 2008
Beiträge: 53610
Wohnort: Berlin
|
UlfZibis schrieb: Welche außer Unity wird denn von Canonical selbst angeboten? GNOME kommt doch genauso von woanders, wie die anderen Desktopumgebungen der Derivate?
Mit "selbst angeboten" war hier wohl gemeint, dass das Ubuntu-Image von Canonical angeboten wird, während die Derivate (Kubuntu, Xubuntu, Lubuntu ...) aus der Community heraus kommen und nicht von den Hauptentwicklern betreut werden.
Ja, denn mir ist nicht klar, was Du unter "Support" verstehst, Bereitstellung (in den Quellen), Wartung (Sicherheitsupdates) oder Weiterentwicklung.
Unter Support verstehe ich das, was seit Jahr und Tag in diesem Forum unter Support verstanden wird. In deiner Aufzählung wäre das die Wartung. Bereitgestellt wird ja auch noch 4.10, dass dies keinen Support mehr hat dürfte klar sein. Weiterentwicklung findet über die Entwicklungsversionen statt, dass es darum nicht geht dürfte ebenfalls klar sein. Da die Abhängigkeiten von ubuntu-gnome-desktop Pflichtbestandteil von Ubuntu 18.04 (LTS) sind, sollte ich doch wohl davon ausgehen können, dass die darüber auf Lubuntu (minimal) nachinstallierten Pakete dann auch die gleiche Aktualität haben.
Nochmal: Support bekommst du für die vorgesehenen Distributionen. Also (im Fall von 18.04) entweder 5 Jahre für die GNOME-Version oder 3 Jahre für Lubuntu. Jedes System ist so sicher wie seine unsicherste Stelle, insofern hast du keinen Support mehr, wenn du eine abgelaufene Version (im Falle von Lubuntu ab 04/2021) verwendest. Da es kein Ubuntu (mit GNOME-Standardoberfläche) für 18.04 gibt hat es auch keinen Support.
... woraus dann doch geschlossen werden kann, dass sie de facto dennoch weiter supportet werden?
Du kannst daraus schließen, dass es möglich ist, dass Pakete noch Updates erhalten. Offiziell Support haben die nicht, da sie den niemals hatten. In Wiki-Artikel gehören da auch keine "könnte vielleicht sein"-Prognosen, sondern Fakten.
Und damit muss dann für das 32-Bit-Wine doch auch eine 32-Bit-Schittstelle zu (im Fall von Ubuntu 20.04 LTS) GNOME weitergepflegt werden?
Nein, denn wie geschrieben hat Wine keinerlei Abhängigkeiten zu GNOME. Daran ändert sich auch nichts, wenn du es noch so oft behauptest. Außerdem "muss" da gar nichts gepflegt werden, da wine im universe -Repo lag und noch nie offiziell Support hatte. Hierum kümmern sich nur die MOTUs, wenn sie denn überhaupt während eines Releases etwas daran tun.
|
UlfZibis
Anmeldungsdatum: 13. Juli 2011
Beiträge: 3035
Wohnort: Köln
|
Letalis_Sonus schrieb: Wann ist bei dir die Einschränkung "signifikant" erfüllt, wo liegt bei dir die Grenze zur Messungenauigkeit?
In 64-Bit-Code brauchen Zeiger bzw. Basisadressen für 32-Bit-Offsets doppelt so viel RAM und auch Cache wie in 32-Bit-Code, das halte ich für signifikant.
Schon klar. Wie die "Auswirkungen" für Firefox unter 64-Bit-Ubuntu aussehen, habe ich in meinem Test gesehen.
Die Einschätzung setzt voraus, dass Firefox für unterschiedliche Architekturen exakt die gleichen Code-Pfade benutzt. Dies ist nicht gegeben, was ich bereits mehrfach ausgeführt habe.
Die folgt aus den Ausgaben von free -m , ob dafür andere Codepfade verantwortlich sind, ist doch schnuppe.
Außerdem sind auch 32-Bit-Programme nicht daran gehindert festzustellen, dass sie auf einer 64-Bit-CPU laufen, und dafür optimierte Codesegmente bereitzustellen.
Jetzt driftest du langsam wirklich ins okkulte ab. Wenn du das auf den allgemein verfügbaren Software-Fundus überträgst bleibt als Fazit nur übrig: Das macht kein Arsch.
Nein, aber die Java-VM.
Dasgleiche unterstelle ich auch den standardmäßig verwendeten gut optimierten Video-Codecs. Wie komme ich sonst zu dem Ergebnis, dass das Enkodieren eines MP4-Videos unter 32-Bit-Ubuntu genausowenig CPU-Last erzeugt, wie unter 64-Bit, wenn doch der Deiner Meinung nach nur dann verfügbare 64-Bit-Befehlssatz effektiver sein soll?
Jetzt mal im Ernst: ... Bestes Beispiel hierfür ist der Bytecode von Java und C#/.NET, hier spuckt nicht einmal mehr der Compiler direkt von der Hardware ausführbaren Code aus.
Aber die Laufzeitumgebung tut das dann on-the-fly mittels des JIT-Compilers.
Wenn du dich mal ernsthaft gefragt hast warum überhaupt für den gleichen Zweck immer mehr Hardware benötigt wird ...
Weil immer mehr visuelle Effekte, Bildchen, Hilfe-Tutorials und 64-Bit-Zeiger eingesetzt werden 😉
Unterm Strich belegt das 32-Bit-Ubuntu aber ca. 0,5 GiB weniger Plattenplatz.
Wieviel davon fällt auf Code für die 32-bit Unterstützung zurück, wieviel wird von davon unabhängigen Alignment Anforderungen des Binärformats künstlich aufgeblasen? ELF hat sehr viel Overhead, siehe dazu auch die Geschichte hinter BusyBox. Die Komprimierbarkeit gibt dafür auch eine gute Aussage an, da sich Speicherbereiche die nur als Padding dienen extrem gut komprimieren lassen. Dementsprechend fällt der Größeunterschied beim Installationsimage deutlich geringer aus.
Richtig, aber das Allozieren von 64-Bit-Zeigern (auch wenn diese hauptsächlich mit Nullen gefüllt sind) kostet zur Laufzeit doppelt so viel RAM und Cache und bremst signifikant die Performance, sobald letztere auf schwachbrüstiger Hardware ausgereizt sind.
Z.B. indem sie auch in 32-Bit-Programme für zeitkritische Routinen Verzweigungen in X64-optimierte Codesegmente einbinden.
Nein, nein, und nochmals nein. Die verfügbaren Betriebsmodi der CPU werden durch den Kernel bestimmt, nicht durch die Anwendung und die Hardware.
"Der Kernel" ist doch auch nichts anderes als ein Stück Software. Warum soll Anwendersoftware nicht dieselben CPU-Modi- und -Befehle nutzen können, wie der Kernel?
Wenn der Kernel bereits keinen AMD64 Betriebsmodi unterstützt, kannst du auch keine AMD64 Code benutzen.
Wenn der Navi meines Autos nur Autobahnen unterstützt (z.B. im Ausland), kann ich doch dennoch Landstraßen benutzen, bzw. ich kann auch Abkürzungen über schlammlöchrige Feldwege nutzen, wenn meine Hardware (SUV) das hergibt. (Vergleiche hinken natürlich meist.)
Und was wird jetzt genau in welchem Kontext ausgeführt? Chrome/Chromium beispielsweise legt bekanntermaßen für jeden Tab einen eigenen Thread an, der aus Sicherheitsgründen jeweils in einer isolierten Sandbox läuft. Hier läuft auch in jedem Thread eine komplette Kopie des Adblockers,
Nur die jeweiligen Prozessdaten, nicht der Code und dessen Fixdaten (z.B. Domain-Listen). Sandboxen werden auch nicht durch Threads geschützt, sondern durch abgegrenzte Prozessräume. Threads im gleichen Prozess können auf ihre jeweiligen Daten untereinander zugreifen.
UlfZibis schrieb: Bei vielen offenen Tabs dürfte der Vorteil aber überwiegen und die Blocklisten müssen nicht zwingenderweise komplett ins RAM geladen werden, ist ja so 'ne Art Datenbank, die zunächst erst mal auf der Platte beheimatet ist.
Und wie genau willst du wissen, welche Informationen zu einer Domain auf der Platte und welche im RAM gelagert werden?
Dazu müsste man in den Code gucken, ob der die gesamten Blocklisten komplett ins RAM kopiert werden (schlimmstenfalls sogar in den jeweiligen Adressraum des jeweiligen Prozesses) oder nur die gerade benötigten Records (Datenbankprinzip). Auch der Einsatz eines Profilers würde das sichtbar machen, aber auf meinem 2-GIB-Maschinchen sicher zum kompletten Kollaps führen.
Du hast ein wirklich naives Verständnis davon wie Software und Hardware interagieren.
Siehe weiter unten ...
Außerdem geht es bei meinem Vergleich nicht um um eine X32 sondern um eine moderne X64-CPU, jeweils unter 32- oder 62-Bit-Ubuntu betrieben.
x32 ist eine ABI, das ist eine reine Software-Geschichte. Es gibt keine x32 CPU, ...
Ach ja, die Begriffe, ich meinte X86 im Vergleich zu X86_64.
Äpfel und Kiwis...
sind zwar nicht das gleiche, können aber das gleiche Volumen haben und entsprechend den Magen (RAM) füllen und zur Unterbrechung der Nahrungsaufnahme (Swapping) führen.
Ein Trend bildet die Realität ab und bestimmt damit statistisch die Ausgangsgröße. Es erwartet ja auch keiner ...
Aber Du erwartest, dass ich mit einem 5 Jahre alten Netbook den Trends von vor 2011 folge – sprich Wegwerfen – oder alternativlos dem jetzigen Trend – 64-Bit – fröne.
Hast du da auch ein paar konkrete Modellbezeichnungen für uns?
Siehe hier.
Lass dir von jemanden sagen, der beruflich 6 unterschiedliche 32/64-bit Architekturen in Assembler programmieren können muss (x86 und AMD64 sind dort noch nicht einmal enthalten!), dass du grundlegende Wissenslücken hast, die dir schlichtweg jegliche Grundlage für so pauschalisierende Aussagen entziehen.
Bei mir fing das 1978 mit dem SC/MP an, dann folgten HP-19C Z80, 6502, 68000, PDP-11, 8086, Diplomarbeit Videokompression mit systolischen Zellenfeldern mittels VLSI-Chip-Design bei Siemens für die RWTH Aachen (Elektrotechnik – Fachrichtung Technische Informatik), NEC 4-Bit-CPU, VAX, TI 16-Bit-CPU, neuronale Netze. Meine X86-Kenntnisse beschränken sich auf meine Erfahrungen in der Mitentwicklung der OpenJDK core-libs und auf den HotSpot-JIT-Compiler. Da war ich in meiner aktiven Phase bis ca. 2013 noch auf Platz 5 des Rankings (siehe "Who sent it" links unten), heute Platz 14 ("View more"), und darunter damals wohl der einzige, der nicht auf der Gehaltsliste von damals Sun Microsystems stand. Dann folgte noch Platz 1 bei den NetBeans-Beta-Testern. Jedes Projekt das ich anpackte, konnte ich im technischen Aufwand reduzieren (Hardware bis auf 1/3, Software bis auf 1/7) unter gleichzeitiger Steigerung der Performance. Solange mir keiner ein nachvollziehbares das Gegenteil belegende Test-Szenario liefert, bleibe ich bei meiner These, dass ein 32-Bit-Ubuntu auf einem x86_64-System weniger RAM braucht, und deshalb mit ⇐ 2 GiB RAM im allgemein üblichen Gebrauch performanter ist (210 Tabs (wiederhergestellt, aber nicht geladen) sind natürlich extrem und dienten nur der Demonstration des Kollaps unter 64 Bit). Deshalb halte ich meinen von Berlin_1946 gelöschten einzeiligen Hinweis IMHO für richtig, hilfreich, sinnvoll und erheblich weniger überfrachtend, als die angesprochenen absätzelangen Redundanzen. Im Zweifelsfall weniger sinnvoll und hilfreich erachte ich den noch bestehenden Hinweis: Die Installation auf Netbooks mit einer Grafik-Auflösung von 1024x600 ist auch möglich. Allerdings werden dann manche Dialog-Fenster unten leicht abgeschnitten.
|
Letalis_Sonus
Anmeldungsdatum: 13. April 2008
Beiträge: 12990
Wohnort: Oldenburg/Erlangen
|
tomtomtom schrieb: Mit "selbst angeboten" war hier wohl gemeint, dass das Ubuntu-Image von Canonical angeboten wird, während die Derivate (Kubuntu, Xubuntu, Lubuntu ...) aus der Community heraus kommen und nicht von den Hauptentwicklern betreut werden.
Gemeint waren die main und restricted Paketquellen. Alles was dort enthalten ist wird von Canonical betreut und damit auch über den kompletten Supportzeitraum mit Sicherheitsupdates versorgt, das geht noch ein ganzes Stück über die vorinstallierte Software hinaus. Diese sind in Synaptic immer gut am kleinen Ubuntu Logo in der Paketliste zu erkennen - keine Ahnung, ob das Software Center etwas ähnliches implementiert hat bzw überhaupt anzeigt, woher die Pakete kommen, habe es selbst nie benutzt. tomtomtom schrieb: Bereitgestellt wird ja auch noch 4.10, dass dies keinen Support mehr hat dürfte klar sein.
Die Paketquellen sind allerdings längst abgeschaltet, selbst die veralteten Pakete bekommt man erst wenn man diese auf eine entsprechend archivierte Kopie der Paketquellen umstellt. UlfZibis schrieb: In 64-Bit-Code brauchen Zeiger bzw. Basisadressen für 32-Bit-Offsets doppelt so viel RAM und auch Cache wie in 32-Bit-Code, das halte ich für signifikant.
Nur wenn du auch entsprechend viele Adressen verarbeitest, das hängt eben von der Beschaffenheit des Codes ab. Ebenfalls kann der Compiler dir dies einfach wegoptimieren - die Daten verteilen sich eher selten quer im virtuellen Adressbereich, das kann man ausnutzen. Insbesondere die relativen Sprungbefehle mit 32-bit Offset sparen im Vergleich zum äquivalenten 32-bit Code unheimlich viele Adressen ein. UlfZibis schrieb: Die folgt aus den Ausgaben von free -m , ob dafür andere Codepfade verantwortlich sind, ist doch schnuppe.
Es wird ab dem Punkt relevant, an dem du diese Aussage auf andere Programme übertragen oder für die gesamte Architektur verallgemeinern willst. UlfZibis schrieb: Nein, aber die Java-VM.
Hast du dazu einen Quellverweis zur Hand? Mir ist dazu nur die PAE Unterstützung vom Server Modus bekannt - und PAE hat nichts mit 64-bit zu tun, das gab es schon im Pentium Pro. UlfZibis schrieb: Dasgleiche unterstelle ich auch den standardmäßig verwendeten gut optimierten Video-Codecs. Wie komme ich sonst zu dem Ergebnis, dass das Enkodieren eines MP4-Videos unter 32-Bit-Ubuntu genausowenig CPU-Last erzeugt, wie unter 64-Bit, wenn doch der Deiner Meinung nach nur dann verfügbare 64-Bit-Befehlssatz effektiver sein soll?
Weil dafür SSE verwendet wird, das sind eben genau jene Fälle bei denen sich separate Code-Pfade für solche Erweiterungen lohnen, weil die Codecs praktisch nichts anderes machen als permanent SSE mit Daten zu füttern. CPU-Erweiterungen haben aber auch herzlich wenig mit der Grundarchitektur der CPU zu tun, da auch hier weder die zusätzlichen Register der Grundarchitektur noch deren effizientere Instruktionen verwendet werden, sondern eben ein davon unabhängiges Rechenmodul. Steam ist zB mehrere Male bei Updates negativ aufgefallen, weil sie Compiler Optimierungen angeschaltet hatten, die Instruktionen einer relativ neuen SSE Version generiert hatten - wodurch das Programm auf etwas älteren CPUs einfach nur mit einer Unknown Instruction Exception abgestürzt ist. Es gibt von Steam nebenbei immer noch keine 64-bit Version. UlfZibis schrieb: Aber die Laufzeitumgebung tut das dann on-the-fly mittels des JIT-Compilers.
...und frisst dennoch ungeheure Mengen an RAM. Ich finde ja speziell bei Java durchaus bemerkenswert, dass dies sogar für den Bedarf an reinen Adressbereichen gilt - es werden wahnsinnige Mengen gemappt, aber jeweils nur ein Bruchteil davon auch alloziert. Ich habe es bei einem alten Thinkpad mit 32-bit CPU schon mal hinbekommen, dass mir ein Java Programm reproduzierbar abgeschmiert ist, weil der virtuelle Adressraum zu klein war - freier RAM war noch vorhanden. UlfZibis schrieb: Richtig, aber das Allozieren von 64-Bit-Zeigern (auch wenn diese hauptsächlich mit Nullen gefüllt sind) kostet zur Laufzeit doppelt so viel RAM und Cache und bremst signifikant die Performance, sobald letztere auf schwachbrüstiger Hardware ausgereizt sind.
...wenn überhaupt ähnlich viele Pointer benötigt werden, siehe oben. Wine hatte übrigens einen sehr interessanten Ansatz um alte 16-bit DOS Programme auf 64-bit Systemen zum laufen zu kriegen, obwohl einige dafür benötigte Betriebsmodi der CPU im 64-bit Betrieb nicht mehr zur Verfügung stehen. Man konnte mit einem kleinen x86-spezifischen Trick die Systemaufrufe einfach auf die schon vorhandenen 32-bit Funktionen legen, wenn man diese so in einen Speicherbereich mappt, dass die oberen 16 bits identisch waren. Microsoft hat hingegen die 16-bit Unterstützung damals einfach komplett ausgemerzt - sie ist aber in den 32-bit Versionen von Windows noch vorhanden, inkl. Relikten wie edit.com. Soweit ich weiß wurde die DOS Unterstützung aber inzwischen weitestgehend aus Wine entfernt. UlfZibis schrieb: Wenn der Navi meines Autos nur Autobahnen unterstützt (z.B. im Ausland), kann ich doch dennoch Landstraßen benutzen, bzw. ich kann auch Abkürzungen über schlammlöchrige Feldwege nutzen, wenn meine Hardware (SUV) das hergibt. (Vergleiche hinken natürlich meist.)
Um beim Vergleich zu bleiben: Das Betriebssystem müsste dazu erst einmal die Nagelstreifen von den Abfahrten entfernen. Ein Programm im Userspace hat nunmal keine Narrenfreiheit, sondern wird in einem CPU Betriebsmodus mit eingeschränkten Rechten betrieben. Du hast weder Zugriff auf privilegierte Instruktionen, noch lässt dich die MPU bzw MMU an irgendwelche Hardware Register der Peripherie ran. Bei Aarch64 (bzw ARM64) war man zB bei dieser Separation extrem gründlich, dort ist es wirklich technisch unmöglich in den 64-bit Modus zu schalten, wenn das mächtigste Exception Level nur mit 32-bit läuft - selbst wenn du ungehinderten Vollzugriff auf die Hardware hast. UlfZibis schrieb: Nur die jeweiligen Prozessdaten, nicht der Code und dessen Fixdaten (z.B. Domain-Listen).
Blöderweise handelt es sich um JavaScript Code, da ist das mit der Separation gar nicht so einfach. UlfZibis schrieb: Bei mir fing das 1978 mit dem SC/MP an, dann folgten HP-19C Z80, 6502, 68000, PDP-11, 8086, Diplomarbeit Videokompression mit systolischen Zellenfeldern mittels VLSI-Chip-Design bei Siemens für die RWTH Aachen (Elektrotechnik – Fachrichtung Technische Informatik), NEC 4-Bit-CPU, VAX, TI 16-Bit-CPU, neuronale Netze.
Ziemlich Out-of-date, würde ich sagen. Das würde aber durchaus die Sache mit der Naivität erklären - es hat sich sehr viel geändert bei den CPUs, in jeglicher Hinsicht. Ich habe hier übrigens auch noch einen alten Brotkasten mit 8500 stehen - ist vor 10 Jahren beim Aufräumen der Chemie Sammlung einer Schule ans Tageslicht gekommen, noch in Originalverpackung samt 5¼" Laufwerk, da konnte ich nicht nein sagen 😉 UlfZibis schrieb: Meine X86-Kenntnisse beschränken sich auf meine Erfahrungen in der Mitentwicklung der OpenJDK core-libs und auf den HotSpot-JIT-Compiler.
Wenn man unter sich ein Betriebssystem hat das einem die ganze Drecksarbeit abnimmt, ist die Sache auch noch recht überschaubar. Richtig schmutzig macht man sich erst in den Bereichen, wo Hand-gezimmerter Assembler keine Wahl ist, sondern aufgrund der Hardware zur Pflicht wird. Die Architektur der Java VM wiederum wurde ja speziell dafür entwickelt, gut auf echter Hardware "emulierbar" zu sein, das hat dann mit richtiger Hardware nicht mehr ganz so viel gemeinsam.
|
UlfZibis
Anmeldungsdatum: 13. Juli 2011
Beiträge: 3035
Wohnort: Köln
|
tomtomtom schrieb Mit "selbst angeboten" war hier wohl gemeint, dass das Ubuntu-Image von Canonical angeboten wird, während die Derivate (Kubuntu, Xubuntu, Lubuntu ...) aus der Community heraus kommen und nicht von den Hauptentwicklern betreut werden.
Merkwürdigerweise sind aber auch ubuntu-gnome-desktop, gnome-session, gnome-shell etc. unter universe gehosted. Das würde nach Deiner Logik bedeuten, dass GNOME auch in LTS-Releases nur 9 Monate Support hat.
Unter Support verstehe ich das, was seit Jahr und Tag in diesem Forum unter Support verstanden wird. In deiner Aufzählung wäre das die Wartung.
OK, dann gibt es aber auch noch Bug-Fixes, die nicht sicherheitsrelevant sind, fallen nicht mehr unter den Support?
Bereitgestellt wird ja auch noch 4.10, ...
Sieht hier aber nicht so aus.
Weiterentwicklung findet über die Entwicklungsversionen statt, ...
Nicht nur, auch in den offiziellen Releases werden neue Funktionalitäten eingeführt, z.B. durch neue Firefox-Versionen, neue GNOME-Features etc..
Da die Abhängigkeiten von ubuntu-gnome-desktop Pflichtbestandteil von Ubuntu 18.04 (LTS) sind, sollte ich doch wohl davon ausgehen können, dass die darüber auf Lubuntu (minimal) nachinstallierten Pakete dann auch die gleiche Aktualität haben.
Nochmal: Support bekommst du für die vorgesehenen Distributionen. Also (im Fall von 18.04) entweder 5 Jahre für die GNOME-Version oder 3 Jahre für Lubuntu.
Nicht nach Deiner Logik, siehe oben, ... oder wenn doch, dann noch 16 Monate unter Lubuntu 18.04 (auch 32-Bit), und nicht nur bis Ende 2018, wie von Dir hier behauptet.
... woraus dann doch geschlossen werden kann, dass sie de facto dennoch weiter supportet werden?
Du kannst daraus schließen, dass es möglich ist, dass Pakete noch Updates erhalten. Offiziell Support haben die nicht, da sie den niemals hatten.
Woraus folgen würde, dass die GNOME-Pakete aus universe für Ubuntu 20.04 LTS nur noch möglicherweise Updates über Dezember 2020 hinaus erhalten.
Und damit muss dann für das 32-Bit-Wine doch auch eine 32-Bit-Schittstelle zu (im Fall von Ubuntu 20.04 LTS) GNOME weitergepflegt werden?
Nein, denn wie geschrieben hat Wine keinerlei Abhängigkeiten zu GNOME. Daran ändert sich auch nichts, wenn du es noch so oft behauptest.
Ich behaupte nicht, dass Wine Paket-Abhängigkeiten zu GNOME hat, aber ohne 32-Bit-Schnittstelle zu GNOME oder irgendeinem anderen Desktop-Manager ist Wine-32 nutzlos, also halt auf andere Weise abhängig.
|
Letalis_Sonus
Anmeldungsdatum: 13. April 2008
Beiträge: 12990
Wohnort: Oldenburg/Erlangen
|
UlfZibis schrieb: Ich behaupte nicht, dass Wine Paket-Abhängigkeiten zu GNOME hat, aber ohne 32-Bit-Schnittstelle zu GNOME oder irgendeinem anderen Desktop-Manager ist Wine-32 nutzlos, also halt auf andere Weise abhängig.
Nope. Wine verbindet sich direkt mit dem X Server. Das ganze ist weder Desktop-Abhängig, noch hat das verwendete Protokoll etwas mit der Architektur zu tun. Es wird lediglich eine einfache 32-bit Programmbibliothek benötigt, die jede Software benutzt um über den X Server eine Oberfläche darzustellen. Wenn überhaupt wird ein GUI Toolkit verwendet, und dies ist im Falle von Gnome GTK. Wine Staging kann von diesem zwar die Theme Informationen beziehen um das Aussehen zu harmonisieren, hierbei handelt es sich aber um eine optionale Abhängigkeit, die Programmbibliothek dafür wird zur Laufzeit geladen und nicht verlinkt.
|
UlfZibis
Anmeldungsdatum: 13. Juli 2011
Beiträge: 3035
Wohnort: Köln
|
Letalis_Sonus schrieb: Nope. Wine verbindet sich direkt mit dem X Server. Das ganze ist weder Desktop-Abhängig, noch hat das verwendete Protokoll etwas mit der Architektur zu tun. Es wird lediglich eine einfache 32-bit Programmbibliothek benötigt, die jede Software benutzt um über den X Server eine Oberfläche darzustellen.
OK, Danke, so kann ich das nachvollziehen. Meine Überlegung dient also nicht dem Nachweis, dass mit 32-Bit-Wine auch 32-Bit-GNOME bereitgestellt werden muss. Dann bin ich noch gespannt auf die Auflösung der "Kuriositäten" aus meinem vorigen Post.
|
Letalis_Sonus
Anmeldungsdatum: 13. April 2008
Beiträge: 12990
Wohnort: Oldenburg/Erlangen
|
UlfZibis schrieb: Dann bin ich noch gespannt auf die Auflösung der "Kuriositäten" aus meinem vorigen Post.
Dann versuch ich mich auch noch mal damit... UlfZibis schrieb: OK, dann gibt es aber auch noch Bug-Fixes, die nicht sicherheitsrelevant sind, fallen nicht mehr unter den Support?
Zielgruppe der LTS Versionen sind nicht einzelne Benutzer, sondern Admins von Rechnerzoos. Wer hunderte von Rechnern gleichzeitig verwalten muss, für den ist jegliche Veränderung ein Problem, denn jeder einzelne Rechner kann potentiell im Detail als Einzelfall Probleme machen. Deshalb sind aus dieser Sicht jene Udpates am besten, die die bisherige Version beibehalten und lediglich selektiv eine Lücke stopfen. Die Entwickler selbst beheben Sicherheitslücken und insbesondere Bugfixes aber oft nur in der jeweils aktuellen Version (sofern kein eigener LTS Zweig angeboten wird), was letztendlich darauf hinaus läuft dass Canonical bei den Paketen selbst aktiv werden muss um die Änderungen zurück zu portieren, damit möglichst wenig verändert wird. Da das mit dem gesamten Software-Fundus ziemlich viel Zeit kosten würde, beschränkt man sich aufs wesentliche - Bugfixes werden nur ausgeliefert wenn sie trivial oder das Problem besonders schwerwiegend sind, man fokussiert sich vor allem auf Sicherheitslücken. UlfZibis schrieb: Sieht hier aber nicht so aus.
Canonical bietet dafür http://old-releases.ubuntu.com/ an. Dort sind sowohl die alten ISOs zu finden, als auch die bereits erwähnten archivierten Paketquellen. UlfZibis schrieb: Nicht nur, auch in den offiziellen Releases werden neue Funktionalitäten eingeführt, z.B. durch neue Firefox-Versionen, neue GNOME-Features etc..
Die Anzahl der Pakete, die innerhalb des Support Zeitraums wirklich eine neue Version über die Updates erhalten, ist sehr gering. Firefox ist eine davon, da sich das Zurückportieren von Sicherheitslücken als extrem aufwändig erweist. Man veröffentlicht ja gerade deshalb alle 6 Monate eine neue Version, damit man nicht die Pakete im einzelnen auf neue Versionen bringen muss - hierfür gibt es Rolling Release Distributionen wie Arch Linux (sehr populär im Team hier, nutze es selbst schon seit einigen Jahren). Diese bieten dementsprechend auch keine konkrete Systemversion an, da es keine Meilensteine gibt an denen man so etwas festmachen könnte - stattdessen bekommt man höchstens einen Snapshot des Status Quo. UlfZibis schrieb: Nicht nach Deiner Logik, siehe oben, ... oder wenn doch, dann noch 16 Monate unter Lubuntu 18.04 (auch 32-Bit), und nicht nur bis Ende 2018, wie von Dir hier behauptet.
Im Detail läuft es eben auf die main und restricted Paketquellen hinaus. Probleme kommen in erster Linie davon, dass man selten wirklich nur mit diesen beiden Paketquellen auskommt. UlfZibis schrieb: Woraus folgen würde, dass die GNOME-Pakete aus universe für Ubuntu 20.04 LTS nur noch möglicherweise Updates über Dezember 2020 hinaus erhalten.
Unity wurde schon vor langer Zeit fallen gelassen, was du inzwischen bekommst ist nur eine Gnome Shell die so konfiguriert wurde, dass sie aussieht wie Unity. Hier wird schlicht strikt zwischen den Versionen getrennt: Alte Ubuntu Versionen behalten ihre Unity Version bei und krigeen nur einfache Sicherheitsupdates während viele ungenutzte Gnome Komponenten nicht supported werden, während sich dies bei neueren Ubuntu Versionen umkehrt.
|
UlfZibis
Anmeldungsdatum: 13. Juli 2011
Beiträge: 3035
Wohnort: Köln
|
Letalis_Sonus schrieb: Dann versuch ich mich auch noch mal damit...
Danke für die gut nachvollziehbaren Erklärungen. Wenn ich Dich richtig verstanden habe, kann ich also im großen und ganzen davon ausgehen, dass alles, was hier noch gelistet ist, noch mit Sicherheitsupdates versorgt wird, also auch die GNOME- und Unity-Pakete mit universe -Status. Die Rückportierungen und deren Version von Canonical erkenne ich dann an den hier markierten Werten:
paket-name-1.2.3-0ubuntu45:amd64
Um festzustellen, ob auch 32-Bit-Pakete beim Rückportieren berücksichtigt wurden, müsste ich also prüfen, ob die markierten Werte mit denen der 64-Bit-Pakete übereinstimmen. Da mir da bisher nie Unterschiede aufgefallen sind, müsste ich bei den auf Lubuntu-32 LTS nachinstallierten Paketen ubuntu-gnome-desktop bzw. ubuntu-unity-desktop und deren Abhängikeiten also auf einer sicheren Seite sein. Bei den 64-Bit-Paketen sowieso, denn die kommen für Lubuntu und Ubuntu (GNOME) ja aus der gleichen Quelle und müssen "zwangsweise" für die LTS-Versionen mit Sicherheitsüpdates versorgt werden.
Unity wurde schon vor langer Zeit fallen gelassen, was du inzwischen bekommst ist nur eine Gnome Shell die so konfiguriert wurde, dass sie aussieht wie Unity.
Leider an den für mich entscheidenden Stellen nicht so wirklich. Die bildschirmflächenplatzsparenden Features wie Verschmelzen von Panel-, Fenstertitel- und Menü-Leisten und schmale Menüeinträge vermisse ich schmerzlich.
|
ChickenLipsRfun2eat
Anmeldungsdatum: 6. Dezember 2009
Beiträge: 12067
|
UlfZibis schrieb: Wenn ich Dich richtig verstanden habe, kann ich also im großen und ganzen davon ausgehen, dass alles, was hier noch gelistet ist…
Mach es dir nicht so leicht - oder so schwer. ubuntu-support-status deckt das doch super ab. Mit --list sogar einzeln auswertbar.
|
UlfZibis
Anmeldungsdatum: 13. Juli 2011
Beiträge: 3035
Wohnort: Köln
|
ChickenLipsRfun2eat schrieb: Mach es dir nicht so leicht - oder so schwer. ubuntu-support-status deckt das doch super ab. Mit --list sogar einzeln auswertbar.
Danke für den Tipp. Interessant, was dabei auf meiner 18.04-64-Bit-Installation herauskommt. Bei den nicht mehr unterstützten sind auch überwiegend viele dabei, die nichts mit meiner Unity-Erweiterung zu tun haben: $ ubuntu-support-status --show-unsupported
Unterstützungsüberblick für »T500«:
Sie haben 585 Pakete (19.0%), die bis April 2021 (Gemeinschaft - 3y) unterstützt werden
Sie haben 2079 Pakete (67.4%), die bis April 2023 (Canonical - 5y) unterstützt werden
Sie haben 3 Pakete (0.1%), die bis April 2021 (Canonical - 3y) unterstützt werden
Sie haben 23 Pakete (0.7%), die nicht/nicht mehr heruntergeladen werden können
Sie haben 394 nicht unterstützte Pakete (12.8%)
Nicht mehr herunterzuladen:
cnijfilter-common-64 cnijfilter-mx880series-64 deltachat-desktop
epson-inkjet-printer-escpr epson-pc-fax epson-printer-utility
firefox-esr firefox-esr-locale-de gir1.2-nm-1.0 iscan iscan-data
iscan-network-nt jfritz k9copy libnm-glib4 libnm-util2 libnm0
libtiff4 master-pdf-editor net.downloadhelper.coapp network-manager
network-manager-config-connectivity-ubuntu zoom
Nicht unterstützt:
ace-of-penguins alien aptik aptik-battery-monitor aptik-gtk arronax
arronax-nautilus arronax-nemo ash audacity audacity-data
audio-recorder autoconf-archive boot-info-script cabextract cdcd
cdda2wav cdrecord cgdb cinnamon-desktop-data cinnamon-l10n clang
classicmenu-indicator clonezilla dconf-editor dconf-tools ddd
debugedit dialog djvulibre-bin drbl dvdrip dvdrip-doc dvdrip-utils
easytag easytag-nautilus faac fatresize fig2dev
fonts-crosextra-caladea fonts-crosextra-carlito fonts-linuxlibertine
fonts-nanum fonts-sil-gentium fonts-sil-gentium-basic
fonts-takao-pgothic fping fslint geany geany-common geoclue
geoclue-ubuntu-geoip ghex gimp gimp-data gimp-help-common
gimp-help-de gimp-help-en gir1.2-cinnamondesktop-3.0
gir1.2-goocanvas-2.0 gir1.2-nemo-3.0 gitg gnome-tweak-tool
gnome-tweaks gnulib gocr google-chrome-stable gpac gpac-modules-base
gperf grub-customizer gscan2pdf gstreamer1.0-fluendo-mp3
gstreamer1.0-vaapi gtk3-nocsd gtkdialog handbrake hplip-gui hud
hunspell-en-med hwinfo indicator-applet indicator-appmenu
indicator-datetime indicator-kdeconnect indicator-printers
indicator-privacy ipcalc isomaster jayatana jeex jhead jpilot
jpilot-plugins k4dirstat lame launchpad-getkeys libanyevent-perl
libapache-pom-java libasync-interrupt-perl libaudio-scrobbler-perl
libbabl-0.1-0 libbit-vector-perl libboost-regex1.65.1 libcapi20-3
libcapi20-3:i386 libcdaudio1 libcinnamon-desktop4 libcolumbus1-common
libcolumbus1v5 libcommons-logging-java libcommons-net-java
libcommons-parent-java libdate-calc-perl libdate-calc-xs-perl
libdisasm0 libdvd-pkg libdvdcss2 libevent-execflow-perl libevent-perl
libevent-rpc-perl libfaac0 libfont-ttf-perl libframe6
libfreeimage-dev libfreeimage3 libfreenect0.5 libgegl-0.3-0 libgeis1
libgeoclue0 libgeonames-common libgeonames0 libgimp2.0
libgit2-glib-1.0-0 libglewmx1.13 libgoocanvas-2.0-9
libgoocanvas-2.0-common libgoocanvas2-perl libgpac4 libgrail6
libgraphicsmagick++-q16-12 libgraphicsmagick-q16-3 libgsasl7
libgsecuredelete0 libgsettings-qt1 libgsoap-2.8.60
libgtk2-ex-formfactory-perl libgtk3-nocsd0 libgtk3-simplelist-perl
libgtkhex-3-0 libgtksourceviewmm-3.0-0v5 libguard-perl libhd21
libimage-magick-perl libimage-magick-q16-perl libimage-sane-perl
libintl-perl libintl-xs-perl libipc-shareable-perl libisoburn1
libjpeg-turbo-progs libjpeg62 libjvmti-oprofile0 libjxr0
libkyotocabinet16v5 liblog-dispatch-perl liblog-log4perl-perl
libmailutils5 libmediainfo0v5 libmotif-common libnemo-extension1
libntlm0 libnux-4.0-0 libnux-4.0-common libopagent1 libopenjfx-java
libopenjfx-jni libopusfile0 liboro-java libossp-uuid-perl
libossp-uuid16 libpanel-applet3 libpango1.0-0 libpangox-1.0-0
libpdf-api2-perl libportsmf0v5 libproc-processtable-perl
libpugixml1v5 libpyside1.2 librarian0 libreoffice
libreoffice-librelogo libreoffice-report-builder
libreoffice-report-builder-bin libreoffice-script-provider-python
libreoffice-sdbc-postgresql librhino-java librpm8 librpmbuild8
librpmio8 librpmsign8 libsereal-decoder-perl libsereal-encoder-perl
libsereal-perl libset-intspan-perl libshiboken1.2v5 libsuil-0-0
libtagsoup-java libtext-unidecode-perl libtiff-tools libtinyxml2-6
libunity-core-6.0-9 libunity-gtk2-parser0 libunity-gtk3-parser0
libunity-misc4 libunity-settings-daemon1 libvamp-hostsdk3v5
libvte-common libvte9 libx86emu1 libxapp1 libxine2 libxine2-bin
libxine2-doc libxine2-ffmpeg libxine2-misc-plugins libxine2-plugins
libxine2-x libxm4 libzeitgeist-1.0-1 libzen0v5 lsb lsb-core
lsb-printing lsb-security lsdvd lshw-gtk mailutils mailutils-common
mediainfo mediainfo-gui meld mencoder mjpegtools mjpegtools-gtk
mkisofs mkvtoolnix mp3diags mp3gain mpg321 mplayer-fonts mplayer-gui
mplayer-skins multisystem nasm nautilus-compare nautilus-wipe nemiver
nemo nemo-audio-tab nemo-compare nemo-data nemo-fileroller nemo-share
nilfs-tools normalize-audio notify-osd notify-osd-icons nux-tools
ogmtools openbsd-inetd openclipart-libreoffice openclipart-png
openjfx openjfx-source overlay-scrollbar overlay-scrollbar-gtk2
p7zip-rar partclone partimage pdf2djvu phonon4qt5-backend-vlc pigz
project-x python-appindicator python-mutagen python-nemo
python-pyside python-pyside.phonon python-pyside.qtcore
python-pyside.qtdeclarative python-pyside.qtgui python-pyside.qthelp
python-pyside.qtnetwork python-pyside.qtopengl python-pyside.qtscript
python-pyside.qtsql python-pyside.qtsvg python-pyside.qttest
python-pyside.qtuitools python-pyside.qtwebkit python-pyside.qtxml
python-zeitgeist python3-requests-oauthlib qemu qemu-system
qemu-system-mips qemu-system-misc qemu-system-sparc qemu-user
qemu-user-binfmt rarian-compat rename rhythmbox-plugin-zeitgeist rpm
rpm-common rpm2cpio sane secure-delete session-shortcuts
skypeforlinux subtitleripper tcpd teamviewer testdisk texinfo
transfig ttf-ancient-fonts-symbola ubuntu-restricted-addons
ubuntu-touch-sounds ubuntu-unity-desktop unity
unity-accessibility-profiles unity-asset-pool unity-control-center
unity-greeter unity-gtk-module-common unity-gtk2-module
unity-gtk3-module unity-lens-applications unity-lens-files
unity-lens-music unity-lens-photos unity-lens-video unity-schemas
unity-scope-calculator unity-scope-chromiumbookmarks
unity-scope-colourlovers unity-scope-devhelp
unity-scope-firefoxbookmarks unity-scope-home unity-scope-manpages
unity-scope-openclipart unity-scope-texdoc unity-scope-tomboy
unity-scope-video-remote unity-scope-virtualbox unity-scope-yelp
unity-scope-zotero unity-scopes-master-default unity-scopes-runner
unity-services unity-session unity-settings-daemon unity-tweak-tool
unpaper unrar unsettings virtualbox virtualbox-dkms
virtualbox-guest-additions-iso virtualbox-guest-utils
virtualbox-guest-x11 virtualbox-qt wine-stable wine-stable-amd64
wine-stable-i386:i386 winehq-stable winff winff-data winff-doc
winff-gtk2 wxhexeditor x86dis xapps-common xfonts-100dpi xine-ui
xorriso xsane xsane-common xvid4conf xvidenc y-ppa-manager yad
|
ChickenLipsRfun2eat
Anmeldungsdatum: 6. Dezember 2009
Beiträge: 12067
|
Liegt wohl auch an den Fremdquellen, die dir z.B. den network-manager ändern. Der hat im Standard 5y Support. Ein "Bastelbuntu" wie deins, sieht aber immer so aus. Ist bei meinen nicht anders. Das einzige produkitive Ubuntu, dass ich noch habe sieht so aus:
You have 1043 packages (82.5%) supported until April 2023 (Canonical - 5y)
You have 55 packages (4.3%) supported until April 2021 (Community - 3y)
You have 1 packages (0.1%) that can not/no-longer be downloaded
You have 166 packages (13.1%) that are unsupported
Das 1 Paket ist ein Python-Paket, die 166 Fremdpakete sind einige Qemu, BackupPC, Multimedia-Konverter, Netzwerktools und sowas. Da muss halt der Admin immer manuell ran.
|
tomtomtom
Supporter
Anmeldungsdatum: 22. August 2008
Beiträge: 53610
Wohnort: Berlin
|
UlfZibis schrieb: Merkwürdigerweise sind aber auch ubuntu-gnome-desktop, gnome-session, gnome-shell etc. unter universe gehosted.
Erstmal ist die Aussage schlichtweg falsch, weil undifferenziert. Das Metapaket ubuntu-gnome-desktop liegt natürlich in universe , weil es nie Teil des offiziellen Ubuntu war. Gleiches gilt für das Metapaket gnome-session, im Gegensatz zum Paket mit dem tatsächlich genutzten Inhalt namens gnome-session-bin. Das Paket gnome-shell wiederum liegt unter 16.04 in universe und in 18.04 und neuer in main , da es jetzt nunmal Teil des Standard-Ubuntu ist. Das Metapaket für die angepasste GNOME-Session, die in 18.04 (und neuer) verwendet wird heißt ubuntu-session. Dieses Metapaket existiert auch in 16.04, dort enthält es aber die Unity-Session (die ihrerseits auch wieder gnome-session-bin verwendet, denn Unity war auch nur eine alternative Shell für GNOME). Das würde nach Deiner Logik bedeuten, dass GNOME auch in LTS-Releases nur 9 Monate Support hat.
Nein, und dafür müsstest du wohl erst einmal verstehen, wovon du schreibst. Das ist alles einfach nachzulesen...
OK, dann gibt es aber auch noch Bug-Fixes, die nicht sicherheitsrelevant sind, fallen nicht mehr unter den Support?
Doch, natürlich. Hast du aber nicht angegeben. Ich habe auf deine Frage geantwortet, welche "deiner Definitionen" am nächsten kommt...
Sieht hier aber nicht so aus.
Tja, wenn du nicht mal weißt, wo du gucken musst... http://old-releases.ubuntu.com/, wurde bereits verlinkt. Wenn man nicht weiß, worum es in einem Wiki-Artikel geht, könnte es helfen diesen zu lesen.
Nicht nur, auch in den offiziellen Releases werden neue Funktionalitäten eingeführt, z.B. durch neue Firefox-Versionen, neue GNOME-Features etc..
Firefox und Thunderbird sind seit etlichen Jahren die Ausnahmen, ab und an gab es auch mal eine neue Chromium-Version, seit 19.10 ist dies ja komplett auf Snap umgestellt worden, was die dürftige Pflege verbessern sollte (Ergebnis bisher: Hängt hinterher und es werden ganze Versionen ausgelassen). Das ist auch seit Jahren bekannt und ändert nichts am Release-Modell einer stabilen Version, die grundsätzlich nicht mit neueren Versionen versorgt wird. Ausnahmen kann es eben immer geben, Firefox, Thunderbird und Chromium sind als solche standardmäßig definiert, vlc bekam vor kurzem auch mal ein Upgrade verpasst, ebenso network-manager-openconnect, da dort die Version nicht zu der des NetworkManager passte. Ist also immer mal vereinzelt möglich, gehört aber nicht zum eigentlichen Modell.
Da die Abhängigkeiten von ubuntu-gnome-desktop Pflichtbestandteil von Ubuntu 18.04 (LTS) sind, sollte ich doch wohl davon ausgehen können, dass die darüber auf Lubuntu (minimal) nachinstallierten Pakete dann auch die gleiche Aktualität haben.
Nochmal: Support bekommst du für die vorgesehenen Distributionen. Also (im Fall von 18.04) entweder 5 Jahre für die GNOME-Version oder 3 Jahre für Lubuntu.
Nicht nach Deiner Logik, siehe oben, ... oder wenn doch, dann noch 16 Monate unter Lubuntu 18.04 (auch 32-Bit), und nicht nur bis Ende 2018, wie von Dir hier behauptet.
Mal abgesehen davon, dass ubuntu-gnome-desktop gar nicht zu Ubuntu 18.04 gehört (was jeder leicht nachgucken kann, besonders wenn er einen Wiki-Artikel zum Thema schreiben will): Du hast nirgends beschrieben, ein sauberes Lubuntu verwenden zu wollen. Du wolltest selbst basteln. Das ist dann - völlig überraschend - keine LTS-Version.
Woraus folgen würde, dass die GNOME-Pakete aus universe für Ubuntu 20.04 LTS nur noch möglicherweise Updates über Dezember 2020 hinaus erhalten.
Pakete aus universe erhalten schon immer nur möglicherweise Updates, das liegt in den Händen der MOTUs (das Thema hatten wir auch schon, Links zu folgen könnte wirklich unheimlich hilfreich sein).
Ich behaupte nicht, dass Wine Paket-Abhängigkeiten zu GNOME hat
Wenn du das nicht behauptest, warum behauptest du es dann ständig? Hint: Die Abhängigkeiten der Pakete werden nicht ausgelost, sondern basieren auf den Abhängigkeiten, die die Software benötigt.
aber ohne 32-Bit-Schnittstelle zu GNOME oder irgendeinem anderen Desktop-Manager ist Wine-32 nutzlos, also halt auf andere Weise abhängig.
Wurde dir ja soweit alles schon erklärt. Ergänzend: GNOME ist kein Desktop-Manager (was immer das auch sein soll), sondern eine Desktop-Umgebung.
|
tomtomtom
Supporter
Anmeldungsdatum: 22. August 2008
Beiträge: 53610
Wohnort: Berlin
|
ChickenLipsRfun2eat schrieb: Mach es dir nicht so leicht - oder so schwer. ubuntu-support-status deckt das doch super ab. Mit --list sogar einzeln auswertbar.
Leider auch nicht wirklich, da das nicht korrekt gepflegt wird. Siehe https://lists.ubuntu.com/archives/ubuntu-devel-discuss/2016-April/016477.html. Edit: Oh, dafür gibt es doch tatsächlichen einen Bugfix, nach mehreren Jahren. https://bugs.launchpad.net/ubuntu/+source/update-manager/+bug/1574670/comments/28
|
ChickenLipsRfun2eat
Anmeldungsdatum: 6. Dezember 2009
Beiträge: 12067
|
tomtomtom schrieb: Leider auch nicht wirklich, da das nicht korrekt gepflegt wird. Siehe https://lists.ubuntu.com/archives/ubuntu-devel-discuss/2016-April/016477.html.
Richtig, aber nach 1574670 ist die Situation wohl nicht mehr so ganz so schlimm ☺
|