>Sie garantiert also nur Distributionsübergreifende kompatibilität, aber
Für kommerzielle Anbieter ist das bei über 380 (Distrowatch.org) verschiedenen Linuxdistributionen schon nicht uninteressant, denn nur so steht der Supportaufwand evtl. in einem sinnvollen Verhältnis zum Umsatz. NAtürlich wäre eine Kompatibilität zu späteren/früheren Versionen auch wünschenswert. Ich kann aber leider nicht sagen ob die LSB 3.0 dies wirklich ausschliesst.
Abwärtskompatiblität würde ja unter anderem die Nutzung der neuen Compiler-Generation nicht möglich machen. Irgenwo müssen Kompromisse gemacht werden. Und die nächsten Kompatiblitätsprobleme sind absehbar, dann wenn der gcc 4.0 herauskommt.
Das ist aber auch nicht tragisch, denn der Hersteller kann ja sein kommerzielles Produkt einmal auch durch eine LSB 1.0 und eine LSB2.0 Maschine jagen und alle 3 Versionen anbieten. Soviel Zeit wird dann ja wohl noch sein. Und wenn die Software nicht auf LSB laufen kann, weil bestimmte Komponenten nicht zur Verfügung stehen ist es eh Banane.
Doch das ist tragisch, denn meine Distri ist bald nur noch LSB 4.0 konform. Was mach ich dann mit der ganzen LSB 1 und 2 Software die ich mal gekauft habe? Wegschmeißen?
Verstehe ich nicht. Ich dachte ein ausführbarer Code der durch einen Compiler gejagt wird, ist immer ausführbar. Zumindest wenn er statisch gelinkt wird. Ein solches Programm sollte doch im idealfall auch unter verschiedenen Betriebssystemen laufen. Nach dem Compilieren ist doch eh alles Assembler. Ich könnte mir nur vorstellen das es Probleme mit Schnittstellen, z.B. mit dem Betriebssystem geben kann. Aber die haben doch nichts mit dem Compiler zu tun.
Es geht eben darum, daß man auf LSB-Systemen auch NICHT statisch linken muß und trotzdem überall lauffähig ist. Dynamisch zu linken hat ja einen Sinn. Und wenn man ein Programm schreibt, das gegen eine oder mehrere reine C++-Libs linkt, dann hat man eben von LSB 3.0 auf LSB 2.x und LSB 1.x keine Abwärtskompatibilität. Und das ist auch vollkommen in Ordnung, denn LSB-Distris sind nur dazu auserkoren, innerhalb einer LSB-Version kompatibel zu sein, das ist auch völlig ausreichend.
Wie kommst Du darauf? Woher nimmst Du die Information, dass SuSE keinen neuen gcc einsetzen wird? An Deinem Kommentar stört mich insbesondere das Wort "alle". PS: Falls Du die bisher verfügbaren Produkte von SuSE meinen solltest: Es ist klar, dass die LSB3 nicht unterstützen *können*, weil sie auf den Markt gekommen sind, *bevor* LSB3 überhaupt in trockenen Tüchern ist. Das sind aber erstens nicht "alle" und zweitens werden selbstverständlich sämtliche Produkte aller großen Distributionen zügig LSB3-konform gemacht, sobald LSB3 in trockenen Tüchern ist, aber keinen Tag vorher.
ich hoffe wirklich es ist nur eine dumme formulierung und die LSB meint die zu gcc 3.4 gehoerige ABI und nicht direkt gcc 3.4. So wollen doch bestimmt einige herstellen ihren teuren icc lizenzen nutzen (icc nutzt die gleiche abi), und neue compiler die es vll mal gibt sollte man doch auch nicht ausgrenzen
PS: aber die fehlende abwaertskompatibilitaet ist ne schlimme sache, wo liegt da eigentlich das problem? bis auf die libstdc++, die man ja in 2 versionen liefern kann, sind doch alles C APIs, deren ABI ist doch seit jahren gleich.
"Dadurch wird die Kompatibilität mit POSIX erhöht, eine Binärkompatibilität zu LSB 2.x gibt es jedoch nicht. Applikationen, die LSB-konform geschrieben sind, sollen auf jeder LSB-konformen Linux-Distribution ohne Neucompilierung laufen."
Was jetzt? Binär inkompatibel oder laufen Applikationen doch auf jeder LSB-konformen Distribution ohne Neukompilierung?
Dass die meisten Programme auf jeder LSB_konformen Distribution laufen, ist ja nichts ungewöhnliches. Aber wenn die GCC- und Glibc-Leute schon wieder binär inkompatible Änderungen in ihre Software eingebaut haben, wäre das schon sehr enttäuschend. Ich dachte, sie hätten inzwischen aus den GCC2.95/Gcc3.0/Gcc3.1-Schlamassel bei c++-Anwendungen gelernt...
Welches Schlamassel? Die libstdc++-Versionen sind sauber getrennt und da man auf neueren Systemen auch ältere libstdc++-Versionen parallel installieren kann, werden ältere Applikationen auch ohne Neucompilierung noch laufen.
LSB verlangt, dass die Distribution mit RPM-Paketen etwas anfangen können. Debian hat dafür alien. LSB verlangt nicht, dass die Distribution RPM als Standardpaketformat verwendet.
> Debian hat dafür alien. Aber nicht in einer Standardinstallation. Und sämtliche Zusatztools sind unter Debian auf .deb abgestimmt (aptitude, apt-proxy, etc.). Debian ist und bleibt eine .deb-Distribution, selbst wenn sie .rpm unterstützen.
Auch hier wieder die Frage: Verschiebt die Installation dieses Zusatzpakets auf einem x86_64-Debian-System die Libs nach /lib64, wo sie hingehören, oder bin ich nicht auf dem aktuellen Stand und dies ist schon der längst der Fall? Sollte es nicht so sein und sollten immer noch 64-Bit-Libs unter /lib installiert werden, dann wäre dies das k.o.-Kriterium, das der LSB-Konformität im Wege steht und auch nicht durch die Nachinstallation irgendwelcher Zusatzpakete behoben werden kann.
Keine Ahnung... An der Stelle hätte ich aber eine Frage: Befinden die 64-Bit-Libs sich auf einem x86_64-Debian-System eigentlich immer noch in /lib anstatt /lib64? Ich weiß das gar nicht. Falls es immer noch so sein sollte, wäre schon das ein k.o.-Kriterium, welches von den Debian-Leuten eigentlich recht leicht zu beheben sein sollte...
Nein, ist es nicht! Bei Dir vielleicht schon, das ist dann aber eine grobe Verletzung des Standards, genau so wie ich das in Erinnerung hatte. Schade eigentlich, aber so wird das nichts mit Debian und LSB-Konformität.
Das Verzeichnis /lib64 darf laut LSB niemals ein Link sein. Auf reinen 32-Bit-Architekturen (IA32) und reinen 64-Bit-Architekturen (IA64) darf es nicht existieren, weder als Link noch als echtes Verzeichnis, auf diesen Architekturen gibt es nur /lib. Auf hybriden Architekturen (AMD64, PPC64) muss es ein Verzeichnis /lib für 32-Bit-Libs und ein Verzeichnis /lib64 für 64-Bit-Libs geben, damit Softwarehersteller nur ein einziges RPM für IA32 und AMD64 bereitstellen müssen. Ein Verzeichnis /lib32 darf es laut LSB niemals geben!
Schade, aber so wird das nichts. Wenn es schon an so grundlegenden und simplen Dingen hapert, dann sollte das Debian-Projekt lieber ganz offen sagen, dass LSB für Debian kein Thema ist. Das wäre dann zumindest transparent und im Sinne der Benutzer.
hmm, bei mir hier ist /lib64 ein Link auf /lib. /lib32 gibt es auch, das ist echt (und leer). Sorum ist es auch logisch, denn die 64-Libs sind ja die normalen und der 32bit-Krempel läuft im Emulationsmodus. Auch würde ich unter /lib immer die zur Architektur gehörenden Libs erwarten (warum heißt das Verzeichnis wohl so?) und unter /libxx alles, was zwar kompatibel aber nicht native ist.
Davon abgesehen gibt man auf die Probleme der proprietären Hersteller viel zu viel und verschenkt damit immer mehr an Flexibilität und Mächtigkeit. Außerdem könnte man das ja auch über den elf-Loader bzw. den Linker lösen, dem ich per /etc/ld.conf sagen kann, wo er für welche Variante wo suchen soll. Bei der Endianness hat man es ja auch so gelöst und nicht noch /lible, /libbe, /lib32le, /lib32be, /lib64le, /lib64be, /lib128le usw. eingeführt.
Mal davon abgesehen, wie ist das bei der zseries? Dort müsste es ja dann auch /lib64, /lib31, /lib24, /lib16 und /lib12 geben (wenn /lib 32bittig ist). Völliger Blödsinn.
> hmm, bei mir hier ist /lib64 ein Link auf /lib. > /lib32 gibt es auch, das ist echt (und leer).
OK, dann ist das falsch und Debian somit, wie erwartet, auf absehbare Zeit nicht konform. Schade!
> Sorum ist es auch logisch, denn die 64-Libs sind > ja die normalen und der 32bit-Krempel läuft im > Emulationsmodus.
Falsch! Auf einem AMD64 ist BEIDES nativ. Du behauptest nur deshalb das Gegenteil, weil es bei Debian dank der mangelhaften und immer noch nicht BiArch-fähigen Paketverwaltung ein Riesen-Akt ist, die BiArch-Fähigkeit auch zu nutzen (Stichwort "chroot" - ist das etwa auch immer noch nötig, um OpenOffice.org zu nutzen? Falls ja - willkommen in der AMD64-Steinzeit). Das ist übrigens auch der Grund, weshalb sich die LSB auf das uneingeschränkt MultiArch-fähige RPM geeinigt hat, weil DEB schlicht und einfach nicht gut genug ist, ob die Debian-Leute es hören wollen oder nicht.
> Auch würde ich unter /lib immer die zur > Architektur gehörenden Libs erwarten (warum > heißt das Verzeichnis wohl so?) und unter /libxx > alles, was zwar kompatibel aber nicht native ist.
Man merkt sehr deutlich, wer mit diesen Sachen ernsthaft Geschäfte machen will und wer es einfach zum Spaß macht.
1. AMD64 ist keine reine 64-Bit-Architektur, sondern eine 64-Bit-Erweiterung einer 32-Bit-Architektur. 2. 32-Bit-Binaries auf einem AMD64 *sind* nativ und *keine* Emulation. Das Gegenteil behaupten nur Leute, die eine mangelhafte Paketverwaltung haben und dann versuchen, aus der Not eine Tugend zu machen. 3. Wer ernsthaft Geschäfte machen will, der wird von externen Paketherstellern garantiert nicht verlangen, dass sie für IA32 und AMD64 zwei verschiedene Pakete bereitstellen, in denen dieselben Binaries drin sind. Wenn doch, dann wird das nie was mit Linux auf dem Unternehmensdesktop.
> Davon abgesehen gibt man auf die Probleme der > proprietären Hersteller viel zu viel und verschenkt > damit immer mehr an Flexibilität und Mächtigkeit.
Wo liegt der Gewinn an Flexibilität, wenn man den Verzeichnisbaum in einer Art und Weise gestaltet, die völlig ohne Notwendigkeit die Kompatibilität zu IA32 bricht? Genau dafür ist AMD64 doch gebaut worden, um kompatibel zu IA32 zu sein. Soll man diesen Vorteil auf dem Software-Weg verspielen? Der Gewinn an Flexibilität ist gleich null. Wer eine reine 64-Bit-Architektur haben will, der soll IA64 nehmen oder Alpha, das gibt es wirklich noch. PS: Wenn "proprietären" Herstellern bewusst inkompatible Steine in den Weg gelegt werden, dann wird das nie was mit Linux auf Unternehmensdesktops.
> Außerdem könnte man das ja auch über den > elf-Loader bzw. den Linker lösen, dem ich per > /etc/ld.conf sagen kann, wo er für welche > Variante wo suchen soll. Bei der Endianness hat > man es ja auch so gelöst und nicht noch /lible, > /libbe, /lib32le, /lib32be, /lib64le, /lib64be, > /lib128le usw. eingeführt.
Nein, kann man nicht, weil diese Libs des öfteren mal denselben Namen haben. Das ist sogar nicht einmal die Ausnahme, sondern die Regel.
> Mal davon abgesehen, wie ist das bei der zseries? > Dort müsste es ja dann auch /lib64, /lib31, /lib24, > /lib16 und /lib12 geben (wenn /lib 32bittig ist).
Völliger Blödsinn ist es, in Hardware gegossene Kompatibilität softwareseitig zu torpedieren, ohne dass es überhaupt einen vernünftigen Grund dafür gibt. Debian soll erstmal auf eine MultiArch-fähige Paketverwaltung umstellen, dann reden wir vielleicht weiter. Aber so wird das nichts mit LSB. Von wegen, man müsse einfach nur ein LSB-Paket nachinstallieren.
> OK, dann ist das falsch und Debian somit, wie erwartet, auf absehbare Zeit nicht konform. Schade! absehbare zeit? woher nimmst du das wissen wann debian das vll aendert? kristallkugel?
Und zu 32bit auf amd64: es ist vollkommen arschlos. Nicht nur das man seine Architektur nicht voll ausnutzt (es betreibt ja auch keiner 16bit apps auf nem pentium4), man benoetigt auch von allen verwendeten libs extra eine 32bit version, da ja 32 und 64bit libs binaer inkompatibel sind. Ich finde es eigentlich eine Frechheit, dass sich manche Hersteller zu denken scheinen, da amd64 ja x86 kompatibel ist reichen auch x86 binaries und sie brauchen keine amd64 binaries zu liefern.
AMD64 ist mit 32bit Kompatibilitaet gebaut worden um am Markt erfolgreich zu sein, wer wuerde einen Prozessor kaufen wo keine bestehende Software drauf laeuft? Dadurch ist das Design auch nicht grade super toll, IA64 hat hier ein besseres, die Designfreiheit war auch viel groesser,da keiner mehr kompatibel zu x86 sein wollte.
Erstens geht es mir nicht darum, dass die Leute auf ihren AMD64-Systemen 32-Bit-Software installieren *sollen*, sondern darum, wie eine Distribution gestaltet sein soll, damit man 32-Bit-Software reibungslos benutzen *kann*. Beachte bitte den Unterschied zwischen *sollen* und *können*. Und zu einer reibungslosen Nutzung gehört es halt nach Ansicht derer, die den Standard gemacht haben, dass man Software nicht für die neue Umgebung neu verpacken muss, sondern die alten RPMs einfach weiternutzen kann. Dieser Ansicht stimme ich ausdrücklich zu.
Und zweitens ist Dir das typische Missverständnis unterlaufen, das vielen AMD64-Neulingen unterläuft, nämlich die Ansicht, dass 64-Bit-Software grundsätzlich performanter laufe und bevorzugt werden solle. Das ist *nicht* richtig. Bei einem Browser bringen 64 Bit genau *null* Vorteile. *Deshalb* ist die Kompatibilität wichtig, weil für manche Hersteller die Produktion einer 64-Bit-Version schon aus wirtschaftlichen Gründen nicht einmal ansatzweise in die Tüte kommt.
Es ist keine "Frechheit", dass es manche Software nicht als 64-Bit-Binary gibt, sondern *Wirtschaftlichkeit*, hast Du davon schon mal gehört? Denk doch einfach mal an OpenOffice.org. Das Ding läuft einfach nicht mit 64 Bit, mit 32 Bit läuft es wunderbar. Und jetzt stell Dir mal vor, das wäre nicht OpenSource, sondern ein kommerzielles Produkt von einer Firma, deren Chef Du bist. Würdest Du zusätzliche Leute einstellen und Geld für die Entwicklung einer 64-Bit-Version verschwenden, die erstens null Vorteile bietet und zweitens auch noch überflüssig ist?
Eben. Und deshalb sind Distributionen, die sich an Leute richten, die wirtschaftlich arbeiten wollen, gut beraten, die Kompatibilität ihrer RPMs zu wahren und das ist wiederum der Grund, weshalb laut LSB /lib64 vorgeschrieben ist. Aber mir soll es egal sein, sollen die Leute sich doch einreden, dass Mozilla als 64-Bit-Binary schneller laufe, was in der Realität nicht der Fall ist, und sich dann für OpenOffice.org eine chroot-Umgebung anlegen, weil die Paketverwaltung mal wieder rumzickt. Mir ist es wurscht, weil bei mir alles LSB-konform ist.
Nun ja, ich hatte das amd64 überlesen, hier werkeln zwei usparc4. Und bei smp laufen die alten 32bit Binaries eben nicht mehr native, sondern nur noch als Emulation und das geht nur im Usermode, 32bit Kernelmodule sind also tabu. Laut faq ist aber sonst das Mischen von 32 und 64bit Code möglich, 32bit Prozesse können also auch gegen 64bit Libs linken. Umgekehrt natürlich nicht.
Bei mir sind laut ldd Realplayer und OOo (beides 32bit) gegen /lib gelinkt. Mozilla ist 64bit und linkt als einziges gegen /lib64. Alles andere ist native 64bit und normal gegen /lib gelinkt. Bis auf Mozilla (wo wohl nur ein falsches configure-Flag gesetzt wurde) ist also ein /libxxx nicht notwendig. /lib32 ist für solche Fälle, in denen alte 32bit Programme Libs benötigen, die nur als 32bit vorliegen. Solche habe ich aber nicht, daher ist es bei mir leer.
Da amd64, wie Du schreibst, keine echte 64bit-Architektur ist, gelten da wohl andere Prioritäten, hatte damit leider noch nicht zu tun un nachdem ich mir erst dieses Wochenende einen neuen Powermac zugelegt habe, wird sich das wohl auch so bald nicht ändern.
> PS: Wenn "proprietären" Herstellern bewusst inkompatible Steine in den Weg gelegt werden, dann wird das nie was mit Linux auf Unternehmensdesktops.
Komisch, wir haben hier 470 Arbeitsplätze, bis auf zwei große Eisen für mySQL und den NFS dazu die unter Sol9 werkeln, läuft überall Linux. Und das schon seit fast fünf Jahren. Und nein, vorher lief auf den PCs, bzw. läuft auf ein paar noch heute, kein Windoof sondern OS/2.
> Und bei smp laufen die alten 32bit Binaries eben nicht mehr native, sondern nur noch als Emulation und das geht nur im Usermode, 32bit Kernelmodule sind also tabu.
Hat sich mit 2.6.9 erledigt.
> Laut faq ist aber sonst das Mischen von 32 und 64bit Code möglich, 32bit Prozesse können also auch gegen 64bit Libs linken. Umgekehrt natürlich nicht.
Die Libs müssen dafür aber ein 32bit-compatible Flag in ihrer ABI haben, standardmäßig haben das auch alle, wenn man selbst ohne -m64 compiliert, ist das auch der Fall, gibt man aber -m64 an, erhält man dann eine reine 64bit Lib ohne 32bit ABI. Das sollte nicht sein, bisher ist das aber nur in sid behoben. Der Größenunterschied soll knapp 10% betragen, was ich für etwas viel halte.
> Und nein, vorher lief auf den PCs, bzw. läuft auf ein paar noch heute, kein Windoof sondern OS/2.
Wie ich soeben erfahren habe, hatten wir früher auch noch einige BSD/OS Maschinen als Druckspooler und für den Telefonpool. Ersteres macht jetzt auch Linux, für die Anlage haben wir seit drei Jahren eine Fujitsu mit einem mir völlig unbekannten Betriebssystem. Scheint ein Echtzeitsystem zu sein, zum Glück müssen wir es aber nicht selber warten (auch wenn ich mittlerweile die meisten Manga im Original lesen kann, schätze ich meine Fähigkeiten als doch so gering ein, das das nicht gut enden würde).
>> Laut faq ist aber sonst das Mischen von 32 und 64bit Code möglich, 32bit Prozesse können also auch gegen 64bit Libs linken. Umgekehrt natürlich nicht. > >Die Libs müssen dafür aber ein 32bit-compatible Flag in ihrer ABI haben, standardmäßig haben das auch alle,
Es sollte vielleicht erwähnt werden, dass Sun diese Funktionalität durch teils gewagte Patches am ELF-Loader, am ld und der gcc erreicht hat und das es erhebliche Probleme im Zusammenhang mit PaX, Lids oder auch nur Prelinking gibt. Natürlich ist es ein enormer Verkaufsvorteil, wenn sowohl für 64- als auch 32bit Produkte nur eine gemeinsame Bibliothek vonnöten ist. Dennoch sollte man nicht außer Acht lassen, dass die Sicherheit erheblich darunter leidet, denn schon mehrfach sind gravierende Fehler in den Patches gefunden worden.
(auch wenn ich mittlerweile die meisten Manga im Original lesen kann, schätze ich meine Fähigkeiten als doch so gering ein, das das nicht gut enden würde).
da hat wohl jemand zuviel bilingual gelesen... willkommen im club
Debian soll erstmal auf eine MultiArch-fähige Paketverwaltung umstellen, dann reden wir vielleicht weiter.
Ist schon in Planung. Allerdings wird man auf eine andere Lösung setzen, die weitere Probleme ausräumt und die Zukunft darstellen wird: http://www.linuxbase.org/futures/ideas/multiarch/
Heißt das etwa, das es keine Abwärtskompatibilität gibt?
Wenn ja, dann ist die LSB für Software, die nur in compilierter Form ausgeliefert wird,
nur von geringem Nutzen.
Sie garantiert also nur Distributionsübergreifende kompatibilität, aber
keine Kompatibität für spätere oder ältere Versionen.
Für kommerzielle Anbieter ist das bei über 380 (Distrowatch.org) verschiedenen Linuxdistributionen schon nicht uninteressant, denn nur so steht der Supportaufwand evtl. in einem sinnvollen Verhältnis zum Umsatz.
NAtürlich wäre eine Kompatibilität zu späteren/früheren Versionen auch wünschenswert. Ich kann aber leider nicht sagen ob die LSB 3.0 dies wirklich ausschliesst.
Und wenn die Software nicht auf LSB laufen kann, weil bestimmte Komponenten nicht zur Verfügung stehen ist es eh Banane.
Was mach ich dann mit der ganzen LSB 1 und 2 Software die ich mal gekauft habe?
Wegschmeißen?
Ich könnte mir nur vorstellen das es Probleme mit Schnittstellen, z.B. mit dem Betriebssystem geben kann. Aber die haben doch nichts mit dem Compiler zu tun.
Bitte erklärt mir das einmal.
Schöne Grüße
Mark
lg
Erik
und wech
PS: aber die fehlende abwaertskompatibilitaet ist ne schlimme sache, wo liegt da eigentlich das problem? bis auf die libstdc++, die man ja in 2 versionen liefern kann, sind doch alles C APIs, deren ABI ist doch seit jahren gleich.
Applikationen, die LSB-konform geschrieben sind, sollen auf jeder LSB-konformen Linux-Distribution ohne Neucompilierung laufen."
Was jetzt? Binär inkompatibel oder laufen Applikationen doch auf jeder LSB-konformen Distribution ohne Neukompilierung?
Dass die meisten Programme auf jeder LSB_konformen Distribution laufen, ist ja nichts ungewöhnliches. Aber wenn die GCC- und Glibc-Leute schon wieder binär inkompatible Änderungen in ihre Software eingebaut haben, wäre das schon sehr enttäuschend. Ich dachte, sie hätten inzwischen aus den GCC2.95/Gcc3.0/Gcc3.1-Schlamassel bei c++-Anwendungen gelernt...
Ja. Aber ein gcc2.95- oder gcc3.0-Plugin läuft nicht in einem gcc3.1-kompilierten Webbrowser. Ähnliche Probleme gibt's bei binären Treibermodulen.
lg
Erik
Jein.
LSB verlangt, dass die Distribution mit RPM-Paketen etwas anfangen können. Debian hat dafür alien.
LSB verlangt nicht, dass die Distribution RPM als Standardpaketformat verwendet.
Aber nicht in einer Standardinstallation. Und sämtliche Zusatztools sind unter Debian auf .deb abgestimmt (aptitude, apt-proxy, etc.). Debian ist und bleibt eine .deb-Distribution, selbst wenn sie .rpm unterstützen.
lg
Erik
Das Verzeichnis /lib64 darf laut LSB niemals ein Link sein. Auf reinen 32-Bit-Architekturen (IA32) und reinen 64-Bit-Architekturen (IA64) darf es nicht existieren, weder als Link noch als echtes Verzeichnis, auf diesen Architekturen gibt es nur /lib. Auf hybriden Architekturen (AMD64, PPC64) muss es ein Verzeichnis /lib für 32-Bit-Libs und ein Verzeichnis /lib64 für 64-Bit-Libs geben, damit Softwarehersteller nur ein einziges RPM für IA32 und AMD64 bereitstellen müssen. Ein Verzeichnis /lib32 darf es laut LSB niemals geben!
Schade, aber so wird das nichts. Wenn es schon an so grundlegenden und simplen Dingen hapert, dann sollte das Debian-Projekt lieber ganz offen sagen, dass LSB für Debian kein Thema ist. Das wäre dann zumindest transparent und im Sinne der Benutzer.
Sorum ist es auch logisch, denn die 64-Libs sind ja die normalen und der 32bit-Krempel läuft im Emulationsmodus. Auch würde ich unter /lib immer die zur Architektur gehörenden Libs erwarten (warum heißt das Verzeichnis wohl so?) und unter /libxx alles, was zwar kompatibel aber nicht native ist.
Davon abgesehen gibt man auf die Probleme der proprietären Hersteller viel zu viel und verschenkt damit immer mehr an Flexibilität und Mächtigkeit. Außerdem könnte man das ja auch über den elf-Loader bzw. den Linker lösen, dem ich per /etc/ld.conf sagen kann, wo er für welche Variante wo suchen soll. Bei der Endianness hat man es ja auch so gelöst und nicht noch /lible, /libbe, /lib32le, /lib32be, /lib64le, /lib64be, /lib128le usw. eingeführt.
Mal davon abgesehen, wie ist das bei der zseries? Dort müsste es ja dann auch /lib64, /lib31, /lib24, /lib16 und /lib12 geben (wenn /lib 32bittig ist). Völliger Blödsinn.
> /lib32 gibt es auch, das ist echt (und leer).
OK, dann ist das falsch und Debian somit, wie erwartet, auf absehbare Zeit nicht konform. Schade!
> Sorum ist es auch logisch, denn die 64-Libs sind
> ja die normalen und der 32bit-Krempel läuft im
> Emulationsmodus.
Falsch! Auf einem AMD64 ist BEIDES nativ. Du behauptest nur deshalb das Gegenteil, weil es bei Debian dank der mangelhaften und immer noch nicht BiArch-fähigen Paketverwaltung ein Riesen-Akt ist, die BiArch-Fähigkeit auch zu nutzen (Stichwort "chroot" - ist das etwa auch immer noch nötig, um OpenOffice.org zu nutzen? Falls ja - willkommen in der AMD64-Steinzeit). Das ist übrigens auch der Grund, weshalb sich die LSB auf das uneingeschränkt MultiArch-fähige RPM geeinigt hat, weil DEB schlicht und einfach nicht gut genug ist, ob die Debian-Leute es hören wollen oder nicht.
> Auch würde ich unter /lib immer die zur
> Architektur gehörenden Libs erwarten (warum
> heißt das Verzeichnis wohl so?) und unter /libxx
> alles, was zwar kompatibel aber nicht native ist.
Man merkt sehr deutlich, wer mit diesen Sachen ernsthaft Geschäfte machen will und wer es einfach zum Spaß macht.
1. AMD64 ist keine reine 64-Bit-Architektur, sondern eine 64-Bit-Erweiterung einer 32-Bit-Architektur.
2. 32-Bit-Binaries auf einem AMD64 *sind* nativ und *keine* Emulation. Das Gegenteil behaupten nur Leute, die eine mangelhafte Paketverwaltung haben und dann versuchen, aus der Not eine Tugend zu machen.
3. Wer ernsthaft Geschäfte machen will, der wird von externen Paketherstellern garantiert nicht verlangen, dass sie für IA32 und AMD64 zwei verschiedene Pakete bereitstellen, in denen dieselben Binaries drin sind. Wenn doch, dann wird das nie was mit Linux auf dem Unternehmensdesktop.
> Davon abgesehen gibt man auf die Probleme der
> proprietären Hersteller viel zu viel und verschenkt
> damit immer mehr an Flexibilität und Mächtigkeit.
Wo liegt der Gewinn an Flexibilität, wenn man den Verzeichnisbaum in einer Art und Weise gestaltet, die völlig ohne Notwendigkeit die Kompatibilität zu IA32 bricht? Genau dafür ist AMD64 doch gebaut worden, um kompatibel zu IA32 zu sein. Soll man diesen Vorteil auf dem Software-Weg verspielen? Der Gewinn an Flexibilität ist gleich null. Wer eine reine 64-Bit-Architektur haben will, der soll IA64 nehmen oder Alpha, das gibt es wirklich noch. PS: Wenn "proprietären" Herstellern bewusst inkompatible Steine in den Weg gelegt werden, dann wird das nie was mit Linux auf Unternehmensdesktops.
> Außerdem könnte man das ja auch über den
> elf-Loader bzw. den Linker lösen, dem ich per
> /etc/ld.conf sagen kann, wo er für welche
> Variante wo suchen soll. Bei der Endianness hat
> man es ja auch so gelöst und nicht noch /lible,
> /libbe, /lib32le, /lib32be, /lib64le, /lib64be,
> /lib128le usw. eingeführt.
Nein, kann man nicht, weil diese Libs des öfteren mal denselben Namen haben. Das ist sogar nicht einmal die Ausnahme, sondern die Regel.
> Mal davon abgesehen, wie ist das bei der zseries?
> Dort müsste es ja dann auch /lib64, /lib31, /lib24,
> /lib16 und /lib12 geben (wenn /lib 32bittig ist).
Wie wäre es mit Lesen?
http://www.pathname.com/fhs/pub/fhs-2.3.html#LIB64
> Völliger Blödsinn.
Völliger Blödsinn ist es, in Hardware gegossene Kompatibilität softwareseitig zu torpedieren, ohne dass es überhaupt einen vernünftigen Grund dafür gibt. Debian soll erstmal auf eine MultiArch-fähige Paketverwaltung umstellen, dann reden wir vielleicht weiter. Aber so wird das nichts mit LSB. Von wegen, man müsse einfach nur ein LSB-Paket nachinstallieren.
absehbare zeit? woher nimmst du das wissen wann debian das vll aendert? kristallkugel?
Und zu 32bit auf amd64: es ist vollkommen arschlos. Nicht nur das man seine Architektur nicht voll ausnutzt (es betreibt ja auch keiner 16bit apps auf nem pentium4), man benoetigt auch von allen verwendeten libs extra eine 32bit version, da ja 32 und 64bit libs binaer inkompatibel sind. Ich finde es eigentlich eine Frechheit, dass sich manche Hersteller zu denken scheinen, da amd64 ja x86 kompatibel ist reichen auch x86 binaries und sie brauchen keine amd64 binaries zu liefern.
AMD64 ist mit 32bit Kompatibilitaet gebaut worden um am Markt erfolgreich zu sein, wer wuerde einen Prozessor kaufen wo keine bestehende Software drauf laeuft? Dadurch ist das Design auch nicht grade super toll, IA64 hat hier ein besseres, die Designfreiheit war auch viel groesser,da keiner mehr kompatibel zu x86 sein wollte.
Und zweitens ist Dir das typische Missverständnis unterlaufen, das vielen AMD64-Neulingen unterläuft, nämlich die Ansicht, dass 64-Bit-Software grundsätzlich performanter laufe und bevorzugt werden solle. Das ist *nicht* richtig. Bei einem Browser bringen 64 Bit genau *null* Vorteile. *Deshalb* ist die Kompatibilität wichtig, weil für manche Hersteller die Produktion einer 64-Bit-Version schon aus wirtschaftlichen Gründen nicht einmal ansatzweise in die Tüte kommt.
Es ist keine "Frechheit", dass es manche Software nicht als 64-Bit-Binary gibt, sondern *Wirtschaftlichkeit*, hast Du davon schon mal gehört? Denk doch einfach mal an OpenOffice.org. Das Ding läuft einfach nicht mit 64 Bit, mit 32 Bit läuft es wunderbar. Und jetzt stell Dir mal vor, das wäre nicht OpenSource, sondern ein kommerzielles Produkt von einer Firma, deren Chef Du bist. Würdest Du zusätzliche Leute einstellen und Geld für die Entwicklung einer 64-Bit-Version verschwenden, die erstens null Vorteile bietet und zweitens auch noch überflüssig ist?
Eben. Und deshalb sind Distributionen, die sich an Leute richten, die wirtschaftlich arbeiten wollen, gut beraten, die Kompatibilität ihrer RPMs zu wahren und das ist wiederum der Grund, weshalb laut LSB /lib64 vorgeschrieben ist. Aber mir soll es egal sein, sollen die Leute sich doch einreden, dass Mozilla als 64-Bit-Binary schneller laufe, was in der Realität nicht der Fall ist, und sich dann für OpenOffice.org eine chroot-Umgebung anlegen, weil die Paketverwaltung mal wieder rumzickt. Mir ist es wurscht, weil bei mir alles LSB-konform ist.
Bei mir sind laut ldd Realplayer und OOo (beides 32bit) gegen /lib gelinkt. Mozilla ist 64bit und linkt als einziges gegen /lib64. Alles andere ist native 64bit und normal gegen /lib gelinkt. Bis auf Mozilla (wo wohl nur ein falsches configure-Flag gesetzt wurde) ist also ein /libxxx nicht notwendig. /lib32 ist für solche Fälle, in denen alte 32bit Programme Libs benötigen, die nur als 32bit vorliegen. Solche habe ich aber nicht, daher ist es bei mir leer.
Da amd64, wie Du schreibst, keine echte 64bit-Architektur ist, gelten da wohl andere Prioritäten, hatte damit leider noch nicht zu tun un nachdem ich mir erst dieses Wochenende einen neuen Powermac zugelegt habe, wird sich das wohl auch so bald nicht ändern.
> PS: Wenn "proprietären" Herstellern bewusst inkompatible Steine in den Weg gelegt werden, dann wird das nie was mit Linux auf Unternehmensdesktops.
Komisch, wir haben hier 470 Arbeitsplätze, bis auf zwei große Eisen für mySQL und den NFS dazu die unter Sol9 werkeln, läuft überall Linux. Und das schon seit fast fünf Jahren. Und nein, vorher lief auf den PCs, bzw. läuft auf ein paar noch heute, kein Windoof sondern OS/2.
> Und bei smp laufen die alten 32bit Binaries eben nicht mehr native, sondern nur noch als Emulation und das geht nur im Usermode, 32bit Kernelmodule sind also tabu.
Hat sich mit 2.6.9 erledigt.
> Laut faq ist aber sonst das Mischen von 32 und 64bit Code möglich, 32bit Prozesse können also auch gegen 64bit Libs linken. Umgekehrt natürlich nicht.
Die Libs müssen dafür aber ein 32bit-compatible Flag in ihrer ABI haben, standardmäßig haben das auch alle, wenn man selbst ohne -m64 compiliert, ist das auch der Fall, gibt man aber -m64 an, erhält man dann eine reine 64bit Lib ohne 32bit ABI. Das sollte nicht sein, bisher ist das aber nur in sid behoben. Der Größenunterschied soll knapp 10% betragen, was ich für etwas viel halte.
> Und nein, vorher lief auf den PCs, bzw. läuft auf ein paar noch heute, kein Windoof sondern OS/2.
Wie ich soeben erfahren habe, hatten wir früher auch noch einige BSD/OS Maschinen als Druckspooler und für den Telefonpool. Ersteres macht jetzt auch Linux, für die Anlage haben wir seit drei Jahren eine Fujitsu mit einem mir völlig unbekannten Betriebssystem. Scheint ein Echtzeitsystem zu sein, zum Glück müssen wir es aber nicht selber warten (auch wenn ich mittlerweile die meisten Manga im Original lesen kann, schätze ich meine Fähigkeiten als doch so gering ein, das das nicht gut enden würde).
>
>Die Libs müssen dafür aber ein 32bit-compatible Flag in ihrer ABI haben, standardmäßig haben das auch alle,
Es sollte vielleicht erwähnt werden, dass Sun diese Funktionalität durch teils gewagte Patches am ELF-Loader, am ld und der gcc erreicht hat und das es erhebliche Probleme im Zusammenhang mit PaX, Lids oder auch nur Prelinking gibt.
Natürlich ist es ein enormer Verkaufsvorteil, wenn sowohl für 64- als auch 32bit Produkte nur eine gemeinsame Bibliothek vonnöten ist. Dennoch sollte man nicht außer Acht lassen, dass die Sicherheit erheblich darunter leidet, denn schon mehrfach sind gravierende Fehler in den Patches gefunden worden.
da hat wohl jemand zuviel bilingual gelesen...
willkommen im club
Ist schon in Planung. Allerdings wird man auf eine andere Lösung setzen, die weitere Probleme ausräumt und die Zukunft darstellen wird: http://www.linuxbase.org/futures/ideas/multiarch/