Am Dienstag, 4. Januar 2005 16:03 schrieb Philipp Thomas:
* Ulf Möller (u.moeller@gmx.de) [20050104 15:42]:
Generell sehe ich die 64-Bit-Umsetzung aber weiterhin als problematisch an.
Was daran ist problematisch? Die Grenzen setzt hier die Hardware, nicht das Betriebssystem.
Erstmal vorweg: Ich greifen niemanden an, auch nicht SuSE, also die Krallen bitte wieder einfahren. Ich möchte verstehen, was ein 64-Bit Linux mit 64Bit-LIBs und 32Bit-Libs macht und wie diese parallel installiert werden können. Ich installiere meine erste 64-Bit-Linux-Version und versuche nur, das Konzept, welches hier hinter steht, zu verstehen (und seine Auswirkungen) Ich schildere jetzt einfach mal meine Vorgehensweise: 1) SuSE 9.2 64-Bit wird installiert (funktioniert super, mit die Beste SuSE-Installation seit langem, riesen Lob... alles wird erkannt 2) Ich versuche Moneyplex zu starten und stelle, fest, meine Chipkarten-Treiber sind nicht installiert, also DVD rein und die Towitoko-Treiber installieren. SuSE nimmt jetzt automatisch die 64-Bit-Treiber (wie man im RPM-System sehen kann). 3.) In Moneyplex will ich die Treiber auswählen und nun sagt mir das Programm (bei dem es sich um ein 32-Bit-Programm handelt, was der normale Anwender aber nicht weiss !), dass das keine Chipkarten-Treiber sind. Warum das keine seinen sollen, sagt niemand, um welche Bit-Version es sich bei den Programmen handelt, weiss der Anwender normalerweise auch nicht. 4.) Ich schliesse auf eine fehlerhafte rpm-Datei und hole mir die tar-Files. Schnell compiliert, Moneyplex aufgerufen und ... dieselbe Sch*** (jetzt klar, da 64-Bit-Treiber erzeugt wurden) Also manuell im i586-Verzeichnis der DVD die pcsc-towitoko.rpm rausgesucht und installiert Nun geht es ! ABER: Eine andere (fiktive) 64-Bit-Anwendung, die den Towitoko-Treiber benötigt, funktioniert nun nicht mehr !!! Beide Pakete (32Bit und 64Bit) kann ich nicht installieren (package pcsc-towitoko-1.1.1-248 is already installed) Ich muss also auf eine Anwendung verzichten !
Die Probleme, auf die du hier stösst haben mit dem Betriebssystem erst einaml nichts zu tun. Doch ! Mit was sollen die denn sonst zu tun haben ! Wenn man natürlich als BS nur den Kernel sieht, dann hast Du recht, für mich ist ein BS die gesammte Architektur (incl. Bibliothekenverwaltung, Programmverwaltng usw.) (Ich weiss, dass man hierüber ganze Doktorarbeiten schreiben kann und sich die Gelehrten hierüber streiten)
Theoretisch würde das heissen, dass man sowohl die 64, als auch die 32 Bit-Bilbiotheken einspielen müßte, das geht aber auch nicht, da i.d.R. diverse Files aus den 32Bit-Paketen mit denen aus den 64-Bit in Konflikt miteinander geraten.
Die zur Laufzeit benötigten Bibliotheken überschneiden sich nicht und nur die werden benötigt. Das funktioniert prima! Das Beispiel oben zeigt, dass es nicht geht. Hier steht zwar nur die RPM-Verwaltung im Wege, aber der normale Anwender ist jetzt aufgeschmissen. Bei der Bibliothek libdv sieht das aber schon ganz anders aus: Hier überschneiden sich die Files im Verzeichnis /usr/bin (file /usr/bin/dubdv from install of libdv-*** conflicts with file from package libdv.****) Hier muss der Anwender jetzt schon sehr genau wissen, was er tut.
Zur Laufzeit überschneiden sich die Pakete in der Tat nicht (wir sind ja zum Glück nicht bei M$)
Solange das Installieren von Programmen nicht einfacher wird, wird es den Massenmarkt nie erreichen ! (einige von Euch wollen das ja auch gar nicht - bitte keine Diskussion hierüber).
Wo ist das Installieren schwierig? Der RPM-Mechanismus schlägt den in Windows verwendeten um Längen! Oder willst du jetzt auch unter Linux Pakete, die dir mal eben Systembibliotheken wie glibc mit einer anderen Version überschreiben? Der RPM-Mechanismus mit seinen ganzen Abhängigkeiten ist IMHO extrem anfällig. Entweder ich mache alles über RPM oder gar nichts ! Beispiel 1: Firefox 1.0 PRE Engl. wurde von SuSE mitgeliefert und ist ein RPM-Paket Ich habe mir die neue Version 1.0 gezogen und mittels vorgegebenen Script installiert. Oh, jetzt habe zweimal Firefox installiert, also schnell RPM-Version deinstallieren Und schon weiss das RPM-System nicht mehr, dass ich Firefox installiert habe Die Firefox-Version aus dem Internet kann ich nicht über RPM-Installieren.
Beispiel 2: Ich installiere ein tar-File mit make install. Auch hier bekommt RPM nichts mit. Also muss man z.B. checkinstall verwenden. Beispiel 3: Es kam in der Vergangenheit öfters vor, dass ich eine neuere LIB benötigte. Die Namensgebung der RPMs ist aber jedem RPM-Bauer selbst überlassen, so dass eine neuere Version der LIB (aus dem Internet) einen anderen Namen als der orig. SUSE-RPM-Name war. Dadurch kam die gesammte RPM-Verwaltung durcheinander. (ich kann den Vorgang nicht genau erklären, so tief stecke ich in dem RPM-Kram nicht drinne und ist auch schon über 6 Monate her).
So wie es jetzt mit den 64-bittigen Programmen / libs aussieht, kann man von einem 64-Bit Linux nur dringend abraten.
Dem kann ich nur widersprechen. Bei mir funktioniert es prächtig und nicht jeder braucht proprietären 32Bit Kram. Du kannst dir z.B. prima einen (fast) vollständigen 64Bit MPlayer bauen. Nur auf die Windows-Codecs musst du verzichten, denn die sind 32bittig. Stop ! Warum soll ich auf die W32-Codecs verzeichten ? Das will und kann ich nicht ! Schon muss der MPlayer 32-Bittig sein und so weiter. Du wirst nur dann auf 32Bit Kram verzeichten können, wenn Du ausschließlich auf OpenSource setzt und zur Not alles selbst compilieren kannst. Das geht doch schon bei der o.g. Banking-Software los. Die OpenSource-Treiber unterstützen nur einen Bruchteil der sich am Markt befindlichen Chipkarten und Authentifikationsmöglichkeiten. Und von solchen Bereichen gibt es sicherlich noch mehr.
BTW, auf einem 64bittigen Windows wird man dieselben Schwierigkieten haben, denn - oh Wunder - auch Windows kann nicht 32bittigen und 64bittigen Code mischen. Ach ja, 16bittige Windowssoftware wird dann garnicht mehr unterstützt. Ich habe die 64Bit-Version nicht ausprobiert. Ich kann mir aber nicht vorstellen, dass ein 64Bit-VB-Runtime -Paket sich nicht installieren lässt, nur weil bereits ein 32Bit-VB-Runtime-Paket bereits installiert wurde (das würde in etwas dem obigen RPM-Problem entsprechen.
Tschüß Ulf