> The GTK+ library suite has been upgraded from the 2.6 API set to 2.8.
Die haben doch tatsächlich die GTK+ Version von 2.6 nur auf 2.8 upgedated und das ist echt ein Witz wenn man berücksichtigt, daß der offizielle stabile Zeig von GTK+ schon bei Version 2.14.x ist. Damit fehlen auch die Änderungen bezüglich der Druckunterstützung die mit GTK+ Version 2.10.x kamen.
Von Kevin Krammer am Fr, 26. Dezember 2008 um 15:40 #
Das ist leider ein Zugeständnis an die sehr langsame Modernisierungsgeschwindigkeit von Enterprise Distributions (RHEL, SLED/SLES).
Ich war am Linux Collaboration Summit im April 2008 in einer der LSB Arbeitssitzungen und die Vertreter von Trolltech haben ein "Uplifting" (also einen Umstieg auf eine neuere Version) sowohl von Qt als auch von GTK vorgeschlagen.
Leider hat selbst die IMHO sehr gute Begründung, dass in beiden Toolstacks massive Verbesserungen gemacht wurden und praktisch alle neuen Produkte diese auch nutzen möchten, nichts gegen "aber Red Hat und Novell würden das nicht in ihren derzeitigen Versionen umsetzen" ausrichten konnten.
LSB-Desktop ist damit praktisch nur für Anbieter interessant, die ohnehin selten neuere Versionen rausbringen und auch keine Endkunden-Software machen, d.h. z.B. interessant für Tools zur Serveradministration, etc.
Und was ist mit DBUS?
Das aktuelleste was ich auf die Schnelle finden konnte ist das hier: http://www.linuxfoundation.org/en/LSB_DBus
Praktisch sehr ähnliches Problem wie oben. Anstatt RH und Novell zu bitten, statt Developersnapshots einen echten Release auszuliefern, wird besser eine der wichtigsten Standardtechnologien um Jahre verzögert.
Danke für die ausführliche Erklärung. Ich dachte mir schon so etwas Ähnliches, konnte auf die Schnelle aber nichts darüber finden.
Vielleicht gibt es ja bald wieder ein Update zur LSB. RedHat und Novell wollen doch bald eine neue Version ihrer Enterprise-Distributionen herausbringen, welche dann wieder dem Stand der Technik entsprechen.
Von Kevin Krammer am Fr, 26. Dezember 2008 um 16:22 #
Vielleicht gibt es ja bald wieder ein Update zur LSB.
Ja, schon, Die Frage ist, in welchem Ausmaß so ein Update Neuerungen beinhalten kann. Ich denke es wäre vernünftiger gewesen, LSB4.0 noch ein bischen zu verzögern und dann aber auch gleich als neue Messlatte vorgeben, nicht immer hinter dem aktuell verfügbaren Stand hinterher laufen lassen.
RedHat und Novell wollen doch bald eine neue Version ihrer Enterprise-Distributionen herausbringen, welche dann wieder dem Stand der Technik entsprechen.
Wenn ich mich jetzt richtig erinnere, sind die aktuellen Versionen noch nicht so alt. RHEL5 war gerade erst "kürzlich" 2007 oder sogar 2008?
Abgesehen davon ist die Vorgehesnsweise einfach zu sehr auf diese beiden Produkte fixiert. Man opfert für die schnelle Verbreitung einer neuen LSB Version (die vorhandenen Enterprise Distris können einfach gleich ihre Zertifizierung bekommen), die Aktualität der Software und damit die Anwendbarkeit für gewisse Einsatzbereiche (Endbenutzersoftware).
Dabei ist speziell in diesem Bereich der Nutzen der LSB größer, weil eben eine größere Anzahl von Distributionen zum Einsatz kommt.
Nachdem was ich bei der Arbeitssitzung gesehen habe ist das aber weniger auf Unverständnis oder Sturheit der LSB Leute zurück zu führen, sondern ein Mangel an Input entsprechender "Stakeholder", d.h. von Firmen, die Software außerhalb des Server und Firmendesktop Sektors herstellen.
Der Kasperl (Flashplayer für Linux Entwickler) war da nicht sehr hilfreich, also blieben als Vertreter der ISVs nur die Leute von Trolltech. Alles andere waren Distro Leute und vermutlich war keiner davon aus dem respektiven Desktopteam.
Vielleicht wird das ja beim nächsten Mal besser, zumal die Interessen hunderter ISVs nicht mehr durch die kleine Firma Trolltech sondern durch den Linux Foundation Gold Member Nokia vertreten werden.
dazu muss man aber wissen wie das ganze in der industrie aussieht. nette features im desktopbereich sind absolut uninteressant und interessieren nur am rande.
wichtig ist koniunitaet fuer den kunden der diese produkte einsetzt, denn dieser wiederum muss seinen kunden ebenfalls 5-10 jahre unterstuetzung einraeumen.
unterstuetzung heusst hier nicht "das neuste und tollste soll immer dazukommen" sonder wichtig ist in diesem bereich, das alles so bleibt und auftretende fehler gewartet werden.
wenn du eine entwicklungsumgebung hast und stellst software fuer einen handychipsatz her, und in 5 jahren wird in dieser version ein fehler bekannt, dann muss der fehler in dieser version gefixt werden. eine neuere umgbung gibts nicht, da steigt dir evtl der hersteller vom handy aufs dach, der deinen chip jetzt verbaut und auf einmal laeuft bei dem nix mehr, weil der wieder andere versionen in der entwicklung hat.
diese kontiunitaet is zwingende voraussetzung und zieht sich quer durch die ganze industrie. es sind nicht redhat und novell die mauern, die sitzen nur an einem ende der langen schlange.
Anders ausgedrueckt, so is es eben, und auch wenn es euch endanwendern spanisch vorkommt, nun, so wird es auch bleiben. eine distribution die ernshaft in industrieumfeld/big business mitspielen will kommt da nicht dran vorbei, und auch die lsb ist nicht stur, sondern sie bedient die industrie und nur am rande ein paar endanwender.
Von Kevin Krammer am Fr, 26. Dezember 2008 um 17:43 #
dazu muss man aber wissen wie das ganze in der industrie aussieht. nette features im desktopbereich sind absolut uninteressant und interessieren nur am rande.
Würden wir hier über "netter features im desktopbereich" sprechen, wäre das auch verständlich. Aber wir reden hier über Softwareinfrastruktur, Features die es der Industrie ermöglichen das zu liefern, was ihre Kunden als selbstverständlich erachten.
Zum Beispiel im Falle des genwünschten Upliftings von Qt auf Version 4.4 essentielle Sachen wie multiplattform Multimedia API, "Web" Renderengine (WebKit). Ich gehe davon aus, dass es im Falle von GTK ähnlich massive Verbesserungen bringen würde.
Das Uplifting ändert auch nichts an der Kontinuität, die entsprechenden neuen Versionen sind API und ABI kompatibel zu den derzeit eingesetzten und etwaig obsolete Funktionalität unterliegt natürlich weiterhin der mehrjährigen LSB Deprecation Policy.
...auch die lsb ist nicht stur, sondern sie bedient die industrie und nur am rande ein paar endanwender.
Ich sagte ja bereits, dass die LSB nicht stur ist. Das Problem ist aber, dass sie eben nicht die Industrie bedient, sondern nur einen Teil davon. Bedürfnisse andere Teile werden nicht entsprechend wahrgenommen, vielleicht weil sie bisher eben nicht stark genug kommuniziert wurden.
Endanwender haben mit der LSB ohnehin nichts zu schaffen, sehr wohl aber die Firmen deren Kunden sie sind.
Von =HAL-9000= am Mo, 29. Dezember 2008 um 17:58 #
Als ich vor ca. zwei Jahren in einem Projekt in der profitabelsten Firma der Welt war wurde das zentrale R/3 System noch mit Windows NT4 betrieben. Die hatten extra mit MS einen Vertrag abgeschlossen damit das OS noch länger supported wird. Im Linux Bereich kam dort RHEL3 zum Einsatz, das war für die Firma geradezu fortschrittlich war. In anderen großen Unternehmen ist die Situation nicht ganz so extrem, aber im Grunde nicht viel anders. Ein neues OS kommt erst zum Einsatz wenn es entsprechend lange getestet wurde. Anschließend wird noch eine ganze Menge Geld für die Applikationen ausgegeben. Danach möchte man halt dass das System so lange läuft bis es vollständig abgeschrieben ist und anfängt sich zu rentieren. Das findet aber nicht nach zwei, drei Jahren statt sondern erst wenn man so ein System mind. sieben, acht Jahre betreibt.
Genau für diese Situation wurde die LSB ins Leben gerufen, daher die manchmal schwer verständlichen Entscheidungen innerhalb der LSB.
Von Kevin Krammer am Di, 30. Dezember 2008 um 03:21 #
Die LSB ist dafür gedacht, Softwareherstellern eine sichere Basis für ihre Produkte zu geben.
Daher werden Symbole auch nicht von heute auf morgen aus der LSB entfernt, siehe Deprecation Policy.
Logischerweise werden alte Distributionen keine neueren Version der LSB unterstützen, aber die Unterstützung der älteren Versionen hört damit nicht auf. Wenn ein Hersteller unbedingt Software verkaufen möchte, das auf sieben oder acht Jahre alten Sytemen läuft, wird er eine entsprechende Version der LSB heranziehen.
Das ist kein Grund neuere Versionen künstliche auf veraltetem Stand zu halten. Leider ist die schwer nachvollziehbare Entscheidung, eine neue LSB Version so zu gestalten, dass sie bei Veröffentlichung praktisch schon umgesetzt ist, mit dem wesentlich Nachteil beladen, dass ein Softwarehersteller nicht einfach ein modernes Produkt anbieten kann und dass dann über mehrere Jahre pflegt, sondern er muss schon mit einem veralteten Produkt starten.
Jeder andere Plattformvertreiber bieten mit neueren Versionen auch entsprechend verbesserte Funktionen an und überlässt es den Applikationsanbietern, ob sie diese nutzen oder kompatibel mit älteren Versionen bleiben möchten. Aus welchem Grund hier einige Leute zu glauben scheinen, die selben Anbieter könnten diese Entscheidung bei Linux als Plattform nicht treffen, entzieht sich meiner Vorstellungskraft.
Na ja der Grund liegt wohl darin das die ihre 1000$ teure Lizensierungen verkaufen wollen. Leider. Ich verstehe nicht warum man einen Desktop Branch der LSB hat wenn man eigentlich an modernen Desktop Anwendungen nicht interessiert ist. Auf dem Server läuft das doch alles relativ gut auch ohne LSB und mit einfachen Angaben von Suse und Red Hat Enterprise Versionsnummern.
Durch all das wird die LSB völlig witzlos. Ich denke auch nicht das im Land der Linux Exzentriker sich wirklich was verbessern lässt wenn die meisten Distros nicht endlich mal Out Of the Box mit LSB kompatibilität kommen (zumindest im Desktop Bereich will man es nicht das der User das manuell nachinstallieren muss). Das könnte man einfach erreichen indem endlich Linus ein einsehen hätte und Sanktionen gegen nicht LSB Distris verhängt (indem er ihnen das Linux im Namen und auf den Webseiten verbietet).
Linux demontiert sich weiter selbst und die Situation wird permanent schlechter als besser. Ein Trauerspiel. Nun ja mit dem MacOSX (und für die "Cheap Charlies" den Hackintosh) gibts ja endlich ein vernünftiges Desktop Unix und Solaris für die Übergeeks.
Und wer dann mal den Fehler gemacht hat und DesktopBSD oder PCBSD als Alternative angesehen hat. Da gibts zwar nicht den Distri Wahnsinn aber bei der Qualität der System kann man nur sagen: Good night and good luck.
P.S: Wie lange wird es wohl dauern bis man mit Webkit eine zentrale Ansprechbare Rendering Komponente hat. Wenn ich mir die Libs ansehe und feststelle das nichtmal libCURL in der LSB 4.0 ist, von libicu ganz zu schwiegen. Nur Portland was toter als Tot ist haben sie dafür integriert. Welche Distri hat das eigentlich als default installiert?
Von Kevin Krammer am Mi, 31. Dezember 2008 um 13:13 #
Na ja der Grund liegt wohl darin das die ihre 1000$ teure Lizensierungen verkaufen wollen.
Soweit ich weiß, wurde das ausgesetzt. Kann mich jetzt nicht erinnern für wie lange, aber sicher schon das ganze Jahr 2008.
Ich verstehe nicht warum man einen Desktop Branch der LSB hat wenn man eigentlich an modernen Desktop Anwendungen nicht interessiert ist. Auf dem Server läuft das doch alles relativ gut auch ohne LSB und mit einfachen Angaben von Suse und Red Hat Enterprise Versionsnummern.
Wie du ja schön sehen kannst, wird das praktisch von allen hier einstimmig bemängelt.
Von Felix Schwarz am Fr, 26. Dezember 2008 um 21:26 #
Wenn ich mich jetzt richtig erinnere, sind die aktuellen Versionen noch nicht so alt. RHEL5 war gerade erst "kürzlich" 2007 oder sogar 2008?
Nun ja, 5.0 wurde im März 2007 veröffentlicht (http://de.wikipedia.org/wiki/Red_Hat_Enterprise_Linux#Versionen). Für Linux-Desktop-Verhältnisse schon eine "Ewigkeit" (insbesondere, wenn man bedenkt, dass die meisten Versionen schon einige Monate vorher 'eingefroren' wurden).
Von Kevin Krammer am Sa, 27. Dezember 2008 um 13:15 #
Für Linux-Desktop-Verhältnisse schon eine "Ewigkeit"...
Das ist schon richtig, aber trifft im Wesentlichen auf die "normalen" Distributionen zu. Die Enterprise Produkte haben üblicherweise einen mehrjährigen Zyklus, ich glaube im Falle von RHEL sind das drei Jahre. D.h. vor Ende 2009 oder Anfang 2010 ist nicht mit RHEL 6.0 nicht zu rechnen.
Nun ja die Leute die halt eher mit dem Computer Geld verdienen müssen als die jungen Kellerkinder Admins die als Update Junkies durch die Rechnerräume hüpfen.
Ich finde /srv in der FHS sehr nützlich. Nutze es als Platz für diverse chroot-Umgebungen. /opt benutze ich hingegen nicht, aber andere Menschen sehr wohl. Also nicht abschaffen.
/srv : Data for services provided by this system Purpose
/srv contains site-specific data which is served by this system.
Tip Rationale
This main purpose of specifying this is so that users may find the location of the data files for particular service, and so that services which require a single tree for readonly data, writable data and scripts (such as cgi scripts) can be reasonably placed. Data that is only of interest to a specific user should go in that users' home directory.
The methodology used to name subdirectories of /srv is unspecified as there is currently no consensus on how this should be done. One method for structuring data under /srv is by protocol, eg. ftp, rsync, www, and cvs. On large systems it can be useful to structure /srv by administrative context, such as /srv/physics/www, /srv/compsci/cvs, etc. This setup will differ from host to host. Therefore, no program should rely on a specific subdirectory structure of /srv existing or data necessarily being stored in /srv. However /srv should always exist on FHS compliant systems and should be used as the default location for such data.
Distributions must take care not to remove locally placed files in these directories without administrator permission. [20]
Habe ich die Beschreibung des FHS richtig verstanden, daß dieses Verzeichnis für die Daten von Serverdiensten wie z.b. git, svn, cvs, http, https, ftp etc. ist?
Und wann wurde dieses Verzeichnis in den FHS Standard aufgenommen?
Hat diese Spezifikation eigentlich wirklich einen praktischen Nutzen? Bei uns in der Firma müssen wir bald eine closed-source Software für Linux ausliefern. Trotz LSB noch immer die selben Issues: GLIBC-Inkompatiblitäten, inkompatible Paketmanager (mind. XYZ-2.3.23, die Distribution liefert aber "nur" XYZ-2.3.24-inkompatibles_namensflag...) usw. Dauert wohl mindestens bis LSB 10.0, bis es möglich ist für ein Programm EIN Binärpaket pro Hardwarearchitektur auszuliefern...
Von Kevin Krammer am Fr, 26. Dezember 2008 um 20:22 #
Wenn man mit den in der LSB festgelegten Versionen auskommt, d.h. keine neuere Version einer Bibliothek braucht, dann sollte das auch funktionieren.
Auf der Website der LSB gibt es einen Applikation Checker, eine Art Testkit mit dem man die eigene Applikation auf LSB Kompatibiltät prüfen kann, d.h. welche Bibliotheken etwa noch mitgeliefert werden müssen.
Bei manchen Distributionen braucht man als Paketabhängigkeit bzw. als Vorbereitungssschritt (zum Beispiel indem man das als Requirement angibt) das jeweilige LSB Metapaket (wobei ich bisher immer die gleiche Paketbenennung, z.B. lsb-base, lsb-desktop) gesehen habe.
Ob man die Software dann als Archiv, als LSB-RPM (nicht zu verwechseln mit einem distributionsspezifischen RPM) oder mit einem Installer ausliefert, ist vielleicht von der Zielgruppe anhängig.
aus dem vorigen kommentar entnehme ich, dass es auch mit LSB 4.0 noch nicht zu einem einheitlichen paketformat für linux gekommen ist. das ist eines der größten knackpunkte, denn auf dem desktop sind derzeit nur Linux Freaks in der Lage proprietäre software (oder sagen wir software die sich nicht in den repositories der distributionen befindet) einzuspielen. Ich hoffe wir erleben alle noch ein einheitliches paketformat.
die glibc-inkompatibilitäten sollten aber durch LSB ausgeräumt sein. die software muss mit den lsb-compilers erstellt und gegen die lsb-bibliotheken gelinkt werden, alle anderen bib's statisch einlinken. fertig. nützt allerding nur was, wenn die zieldistro auch LSB unterstützt. Das machen aber wie oben gehört die Enterprise distris auf den fall und sogar openSuSE ist LSB-konform.
Von Kevin Krammer am Sa, 27. Dezember 2008 um 13:24 #
aus dem vorigen kommentar entnehme ich, dass es auch mit LSB 4.0 noch nicht zu einem einheitlichen paketformat für linux gekommen ist.
Das ist nur eine teilweise richtige Interpretation: ein LSB System unterstützt immer LSB-RPM Pakete, d.h. für eine Software, deren Zielplattform eine LSB kompatible Distribution ist, hat die Wahl der Distribution bezüglich ihres Systempaketmanagers keine Relevanz.
Ganz abgesehen davon gibt es natürlich auch die von anderen Plattformen bekannte Möglichkeit, sich ausschließlich auf das Vorhandensein der Runtime-Requirements (z.B. Library-Symbole) zu verlassen und die Software über einen Stand-Alone Installer einzuspielen.
Von nochmals blabb am Sa, 27. Dezember 2008 um 17:28 #
ok, kann man dann ein LSB-rpm (sagen wir 3.0 kompatibel) out-of-the-box auf einem ubuntu/kubuntu system installieren? auf openSUSE/SLED/SLES/Fedora/RHEL geht das ja.
> ok, kann man dann ein LSB-rpm (sagen wir 3.0 kompatibel) out-of-the-box > auf einem ubuntu/kubuntu system installieren? Dürfte es sich sonst LSB-RPM nennen? Dafür sorgt ein gleichnamiges Debianpaket.
Okay, ein rudimentäres aber überall vorhandenes RPM für init Scripte etc. sollte ausreichen. Aber kannst du mir jetzt sagen wie die Kommandozeile aussieht um das RPM zu installieren. Oder muss ich da auch schreiben "Liebe User bitte probiert auf der Console aus ob es ein rpm oder ein alien Programm gibt oder lest in der bei Linux üblicherweise nicht vorhandenen Doku nach wie der LSB Installer heisst und installiert es dann wie beschrieben"?
Sorry aber Max Mustermann zeigt dir dann den Stinkefinger und bootet wieder Windows oder MacOSX.
Dann gibt es bezüglich Distributionen noch eine Liste die auch Einträge enthält, wo die Zertifizierung noch aussteht, bzw. LSB Unterstützung noch in Arbeit ist: http://www.linuxfoundation.org/en/LSB_Distribution_Status
Die haben doch tatsächlich die GTK+ Version von 2.6 nur auf 2.8 upgedated und das ist echt ein Witz wenn man berücksichtigt, daß der offizielle stabile Zeig von GTK+ schon bei Version 2.14.x ist.
Damit fehlen auch die Änderungen bezüglich der Druckunterstützung die mit GTK+ Version 2.10.x kamen.
Und was ist mit DBUS?
Ich war am Linux Collaboration Summit im April 2008 in einer der LSB Arbeitssitzungen und die Vertreter von Trolltech haben ein "Uplifting" (also einen Umstieg auf eine neuere Version) sowohl von Qt als auch von GTK vorgeschlagen.
Leider hat selbst die IMHO sehr gute Begründung, dass in beiden Toolstacks massive Verbesserungen gemacht wurden und praktisch alle neuen Produkte diese auch nutzen möchten, nichts gegen "aber Red Hat und Novell würden das nicht in ihren derzeitigen Versionen umsetzen" ausrichten konnten.
LSB-Desktop ist damit praktisch nur für Anbieter interessant, die ohnehin selten neuere Versionen rausbringen und auch keine Endkunden-Software machen, d.h. z.B. interessant für Tools zur Serveradministration, etc.
Und was ist mit DBUS?
Das aktuelleste was ich auf die Schnelle finden konnte ist das hier: http://www.linuxfoundation.org/en/LSB_DBus
Praktisch sehr ähnliches Problem wie oben. Anstatt RH und Novell zu bitten, statt Developersnapshots einen echten Release auszuliefern, wird besser eine der wichtigsten Standardtechnologien um Jahre verzögert.
Vielleicht gibt es ja bald wieder ein Update zur LSB. RedHat und Novell wollen doch bald eine neue Version ihrer Enterprise-Distributionen herausbringen, welche dann wieder dem Stand der Technik entsprechen.
Ja, schon, Die Frage ist, in welchem Ausmaß so ein Update Neuerungen beinhalten kann.
Ich denke es wäre vernünftiger gewesen, LSB4.0 noch ein bischen zu verzögern und dann aber auch gleich als neue Messlatte vorgeben, nicht immer hinter dem aktuell verfügbaren Stand hinterher laufen lassen.
RedHat und Novell wollen doch bald eine neue Version ihrer Enterprise-Distributionen herausbringen, welche dann wieder dem Stand der Technik entsprechen.
Wenn ich mich jetzt richtig erinnere, sind die aktuellen Versionen noch nicht so alt. RHEL5 war gerade erst "kürzlich" 2007 oder sogar 2008?
Abgesehen davon ist die Vorgehesnsweise einfach zu sehr auf diese beiden Produkte fixiert.
Man opfert für die schnelle Verbreitung einer neuen LSB Version (die vorhandenen Enterprise Distris können einfach gleich ihre Zertifizierung bekommen), die Aktualität der Software und damit die Anwendbarkeit für gewisse Einsatzbereiche (Endbenutzersoftware).
Dabei ist speziell in diesem Bereich der Nutzen der LSB größer, weil eben eine größere Anzahl von Distributionen zum Einsatz kommt.
Nachdem was ich bei der Arbeitssitzung gesehen habe ist das aber weniger auf Unverständnis oder Sturheit der LSB Leute zurück zu führen, sondern ein Mangel an Input entsprechender "Stakeholder", d.h. von Firmen, die Software außerhalb des Server und Firmendesktop Sektors herstellen.
Der Kasperl (Flashplayer für Linux Entwickler) war da nicht sehr hilfreich, also blieben als Vertreter der ISVs nur die Leute von Trolltech. Alles andere waren Distro Leute und vermutlich war keiner davon aus dem respektiven Desktopteam.
Vielleicht wird das ja beim nächsten Mal besser, zumal die Interessen hunderter ISVs nicht mehr durch die kleine Firma Trolltech sondern durch den Linux Foundation Gold Member Nokia vertreten werden.
wichtig ist koniunitaet fuer den kunden der diese produkte einsetzt, denn dieser wiederum muss seinen kunden ebenfalls 5-10 jahre unterstuetzung einraeumen.
unterstuetzung heusst hier nicht "das neuste und tollste soll immer dazukommen" sonder wichtig ist in diesem bereich, das alles so bleibt und auftretende fehler gewartet werden.
wenn du eine entwicklungsumgebung hast und stellst software fuer einen handychipsatz her, und in 5 jahren wird in dieser version ein fehler bekannt, dann muss der fehler in dieser version gefixt werden. eine neuere umgbung gibts nicht, da steigt dir evtl der hersteller vom handy aufs dach, der deinen chip jetzt verbaut und auf einmal laeuft bei dem nix mehr, weil der wieder andere versionen in der entwicklung hat.
diese kontiunitaet is zwingende voraussetzung und zieht sich quer durch die ganze industrie. es sind nicht redhat und novell die mauern, die sitzen nur an einem ende der langen schlange.
Anders ausgedrueckt, so is es eben, und auch wenn es euch endanwendern spanisch vorkommt, nun, so wird es auch bleiben. eine distribution die ernshaft in industrieumfeld/big business mitspielen will kommt da nicht dran vorbei, und auch die lsb ist nicht stur, sondern sie bedient die industrie und nur am rande ein paar endanwender.
gruss,
die mad
Würden wir hier über "netter features im desktopbereich" sprechen, wäre das auch verständlich.
Aber wir reden hier über Softwareinfrastruktur, Features die es der Industrie ermöglichen das zu liefern, was ihre Kunden als selbstverständlich erachten.
Zum Beispiel im Falle des genwünschten Upliftings von Qt auf Version 4.4 essentielle Sachen wie multiplattform Multimedia API, "Web" Renderengine (WebKit).
Ich gehe davon aus, dass es im Falle von GTK ähnlich massive Verbesserungen bringen würde.
Das Uplifting ändert auch nichts an der Kontinuität, die entsprechenden neuen Versionen sind API und ABI kompatibel zu den derzeit eingesetzten und etwaig obsolete Funktionalität unterliegt natürlich weiterhin der mehrjährigen LSB Deprecation Policy.
...auch die lsb ist nicht stur, sondern sie bedient die industrie und nur am rande ein paar endanwender.
Ich sagte ja bereits, dass die LSB nicht stur ist. Das Problem ist aber, dass sie eben nicht die Industrie bedient, sondern nur einen Teil davon.
Bedürfnisse andere Teile werden nicht entsprechend wahrgenommen, vielleicht weil sie bisher eben nicht stark genug kommuniziert wurden.
Endanwender haben mit der LSB ohnehin nichts zu schaffen, sehr wohl aber die Firmen deren Kunden sie sind.
Genau für diese Situation wurde die LSB ins Leben gerufen, daher die manchmal schwer verständlichen Entscheidungen innerhalb der LSB.
MfG =HAL-9000=
Daher werden Symbole auch nicht von heute auf morgen aus der LSB entfernt, siehe Deprecation Policy.
Logischerweise werden alte Distributionen keine neueren Version der LSB unterstützen, aber die Unterstützung der älteren Versionen hört damit nicht auf.
Wenn ein Hersteller unbedingt Software verkaufen möchte, das auf sieben oder acht Jahre alten Sytemen läuft, wird er eine entsprechende Version der LSB heranziehen.
Das ist kein Grund neuere Versionen künstliche auf veraltetem Stand zu halten.
Leider ist die schwer nachvollziehbare Entscheidung, eine neue LSB Version so zu gestalten, dass sie bei Veröffentlichung praktisch schon umgesetzt ist, mit dem wesentlich Nachteil beladen, dass ein Softwarehersteller nicht einfach ein modernes Produkt anbieten kann und dass dann über mehrere Jahre pflegt, sondern er muss schon mit einem veralteten Produkt starten.
Jeder andere Plattformvertreiber bieten mit neueren Versionen auch entsprechend verbesserte Funktionen an und überlässt es den Applikationsanbietern, ob sie diese nutzen oder kompatibel mit älteren Versionen bleiben möchten.
Aus welchem Grund hier einige Leute zu glauben scheinen, die selben Anbieter könnten diese Entscheidung bei Linux als Plattform nicht treffen, entzieht sich meiner Vorstellungskraft.
Ich verstehe nicht warum man einen Desktop Branch der LSB hat wenn man eigentlich an modernen Desktop
Anwendungen nicht interessiert ist. Auf dem Server läuft das doch alles relativ gut auch ohne LSB
und mit einfachen Angaben von Suse und Red Hat Enterprise Versionsnummern.
Durch all das wird die LSB völlig witzlos. Ich denke auch nicht das im Land der Linux Exzentriker
sich wirklich was verbessern lässt wenn die meisten Distros nicht endlich mal Out Of the Box mit LSB
kompatibilität kommen (zumindest im Desktop Bereich will man es nicht das der User das manuell
nachinstallieren muss). Das könnte man einfach erreichen indem endlich Linus ein einsehen hätte und
Sanktionen gegen nicht LSB Distris verhängt (indem er ihnen das Linux im Namen und auf den Webseiten
verbietet).
Linux demontiert sich weiter selbst und die Situation wird permanent schlechter als besser.
Ein Trauerspiel. Nun ja mit dem MacOSX (und für die "Cheap Charlies" den Hackintosh) gibts ja
endlich ein vernünftiges Desktop Unix und Solaris für die Übergeeks.
Und wer dann mal den Fehler gemacht hat und DesktopBSD oder PCBSD als Alternative angesehen hat.
Da gibts zwar nicht den Distri Wahnsinn aber bei der Qualität der System kann man nur sagen:
Good night and good luck.
P.S: Wie lange wird es wohl dauern bis man mit Webkit eine zentrale Ansprechbare
Rendering Komponente hat. Wenn ich mir die Libs ansehe und feststelle das nichtmal
libCURL in der LSB 4.0 ist, von libicu ganz zu schwiegen. Nur Portland was toter
als Tot ist haben sie dafür integriert. Welche Distri hat das eigentlich als default
installiert?
Soweit ich weiß, wurde das ausgesetzt. Kann mich jetzt nicht erinnern für wie lange, aber sicher schon das ganze Jahr 2008.
Ich verstehe nicht warum man einen Desktop Branch der LSB hat wenn man eigentlich an modernen Desktop
Anwendungen nicht interessiert ist. Auf dem Server läuft das doch alles relativ gut auch ohne LSB
und mit einfachen Angaben von Suse und Red Hat Enterprise Versionsnummern.
Wie du ja schön sehen kannst, wird das praktisch von allen hier einstimmig bemängelt.
Nun ja, 5.0 wurde im März 2007 veröffentlicht (http://de.wikipedia.org/wiki/Red_Hat_Enterprise_Linux#Versionen). Für Linux-Desktop-Verhältnisse schon eine "Ewigkeit" (insbesondere, wenn man bedenkt, dass die meisten Versionen schon einige Monate vorher 'eingefroren' wurden).
fs
Das ist schon richtig, aber trifft im Wesentlichen auf die "normalen" Distributionen zu. Die Enterprise Produkte haben üblicherweise einen mehrjährigen Zyklus, ich glaube im Falle von RHEL sind das drei Jahre.
D.h. vor Ende 2009 oder Anfang 2010 ist nicht mit RHEL 6.0 nicht zu rechnen.
Immer diese Ewig-Gestrigen. :/
ABM, mehr ist das nicht. Eine ABM, die Linux behindert.
/opt benutze ich hingegen nicht, aber andere Menschen sehr wohl. Also nicht abschaffen.
Hoffentlich nie. Mir gefällt's.
/srv : Data for services provided by this system
Purpose
/srv contains site-specific data which is served by this system.
Tip Rationale
This main purpose of specifying this is so that users may find the location of the data files for particular service, and so that services which require a single tree for readonly data, writable data and scripts (such as cgi scripts) can be reasonably placed. Data that is only of interest to a specific user should go in that users' home directory.
The methodology used to name subdirectories of /srv is unspecified as there is currently no consensus on how this should be done. One method for structuring data under /srv is by protocol, eg. ftp, rsync, www, and cvs. On large systems it can be useful to structure /srv by administrative context, such as /srv/physics/www, /srv/compsci/cvs, etc. This setup will differ from host to host. Therefore, no program should rely on a specific subdirectory structure of /srv existing or data necessarily being stored in /srv. However /srv should always exist on FHS compliant systems and should be used as the default location for such data.
Distributions must take care not to remove locally placed files in these directories without administrator permission. [20]
Habe ich die Beschreibung des FHS richtig verstanden, daß dieses Verzeichnis für die Daten von Serverdiensten wie z.b. git, svn, cvs, http, https, ftp etc. ist?
Und wann wurde dieses Verzeichnis in den FHS Standard aufgenommen?
Dauert wohl mindestens bis LSB 10.0, bis es möglich ist für ein Programm EIN Binärpaket pro Hardwarearchitektur auszuliefern...
Auf der Website der LSB gibt es einen Applikation Checker, eine Art Testkit mit dem man die eigene Applikation auf LSB Kompatibiltät prüfen kann, d.h. welche Bibliotheken etwa noch mitgeliefert werden müssen.
Bei manchen Distributionen braucht man als Paketabhängigkeit bzw. als Vorbereitungssschritt (zum Beispiel indem man das als Requirement angibt) das jeweilige LSB Metapaket (wobei ich bisher immer die gleiche Paketbenennung, z.B. lsb-base, lsb-desktop) gesehen habe.
Ob man die Software dann als Archiv, als LSB-RPM (nicht zu verwechseln mit einem distributionsspezifischen RPM) oder mit einem Installer ausliefert, ist vielleicht von der Zielgruppe anhängig.
Ich hoffe wir erleben alle noch ein einheitliches paketformat.
die glibc-inkompatibilitäten sollten aber durch LSB ausgeräumt sein. die software muss mit den lsb-compilers erstellt und gegen die lsb-bibliotheken gelinkt werden, alle anderen bib's statisch einlinken. fertig. nützt allerding nur was, wenn die zieldistro auch LSB unterstützt. Das machen aber wie oben gehört die Enterprise distris auf den fall und sogar openSuSE ist LSB-konform.
Das ist nur eine teilweise richtige Interpretation: ein LSB System unterstützt immer LSB-RPM Pakete, d.h. für eine Software, deren Zielplattform eine LSB kompatible Distribution ist, hat die Wahl der Distribution bezüglich ihres Systempaketmanagers keine Relevanz.
Ganz abgesehen davon gibt es natürlich auch die von anderen Plattformen bekannte Möglichkeit, sich ausschließlich auf das Vorhandensein der Runtime-Requirements (z.B. Library-Symbole) zu verlassen und die Software über einen Stand-Alone Installer einzuspielen.
auf openSUSE/SLED/SLES/Fedora/RHEL geht das ja.
> auf einem ubuntu/kubuntu system installieren?
Dürfte es sich sonst LSB-RPM nennen? Dafür sorgt ein gleichnamiges Debianpaket.
lg
Erik
Aber kannst du mir jetzt sagen wie die Kommandozeile aussieht um das RPM zu installieren.
Oder muss ich da auch schreiben "Liebe User bitte probiert auf der Console aus ob es
ein rpm oder ein alien Programm gibt oder lest in der bei Linux üblicherweise nicht
vorhandenen Doku nach wie der LSB Installer heisst und installiert es dann wie beschrieben"?
Sorry aber Max Mustermann zeigt dir dann den Stinkefinger und bootet wieder Windows oder MacOSX.
Ich bin kein RPM Spezialist, d.h. ich kenn dessen Syntax nicht, aber vielleicht
% lsb-rpm -i paketname
Also sowas wie SuSE 10.1 erfüllt LSB x.y etc.
Wäre dankbar für einen Link.
https://www.linuxfoundation.org/lsb-cert/productdir.php?by_prod
Dann gibt es bezüglich Distributionen noch eine Liste die auch Einträge enthält, wo die Zertifizierung noch aussteht, bzw. LSB Unterstützung noch in Arbeit ist:
http://www.linuxfoundation.org/en/LSB_Distribution_Status
Versteh ich nicht??