Autor Thema: Bochs Debugmodus unter Linux  (Gelesen 10875 mal)

Legend

  • Beiträge: 635
    • Profil anzeigen
    • http://os.joachimnock.de
Gespeichert
« Antwort #20 am: 16. July 2006, 00:29 »
Zitat von: Termite
mich beschleicht das Gefühl, das hier jemand mit "Linux" eigentlich eine Linux Distribution meitn. Ein RedHead Linux , ein Suse Linux, Gentoo oder Debian Linux basiert zwar alle auf dem Linux Kern von Linus. Aber das angebot drumm herum, der Aufbau, die Versorgung mit zusätzlicher Software, kann ggf sehr unterschiedlich aussehen.


Okay, dann nennen wir das aber alles lieber unterschiedliche Betriebssysteme, denn richtig kompatibel ist da nichts.

Zitat
Es harmonisiert sich mitlerweile, da gerade die suse unsitten von früher weniger werden, config fils an orten zu speichern, wo sie laut Standart gar nicht hingehören, ...


Welcher Standard?

Zitat

Debian z.B. unterstützt sowol seine eigenen deb pakete als auch die RPM (RedheadPackatManager) Dateien. Das RPMs sich ggf auf einem System nicht sauber installieren lässt, hängt meist mit problemen oder Standardabweichungen der distry zusammen als damit das der Produzent des RPMs misst gebaut hat. ( wobei das auch sein könnte )


Genau das solche Abweichungen ein Problem sind, darum geht es doch hier.

Zitat

Es ist änlich wie der verglich, wieso ein Programm für Windows XP nicht auf einem Windows 95 oder NT4 läuft. ist doch auch alles Windows oder etwa nicht. Bei einem grossteil der Programme geht das auch ohne probleme. nur bei manchen kann es probleme machen. Nur wieso? es ist doch alles Windows?


Das funktioniert sogar erstaunlich gut noch. Das schaffen die Linux Distributionen sogar bei selbem technischen Stand untereinander nicht. o_O
*post*

bluecode

  • Beiträge: 1 391
    • Profil anzeigen
    • lightOS
Gespeichert
« Antwort #21 am: 16. July 2006, 00:59 »
Zitat von: Legend
Zitat von: Termite
Es harmonisiert sich mitlerweile, da gerade die suse unsitten von früher weniger werden, config fils an orten zu speichern, wo sie laut Standart gar nicht hingehören, ...

Welcher Standard?

Linux Standard Base
lightOS
"Überlegen sie mal 'nen Augenblick, dann lösen sich die ganzen Widersprüche auf. Die Wut wird noch größer, aber die intellektuelle Verwirrung lässt nach.", Georg Schramm

Legend

  • Beiträge: 635
    • Profil anzeigen
    • http://os.joachimnock.de
Gespeichert
« Antwort #22 am: 16. July 2006, 09:45 »
Das kenne ich, als richtiger Standard ist mir das aber noch nicht verbindlich genug. Wobei diese tatsächlich auch in die richtige Richtung gehen.

Aber ein Problem das gerne zitiert wird ist das LSB nur RPM berücksichtigt, so dass man bei Distributionen die z.B. mit apt-get laufen umwegen machen muss. Und solange ein einheitliches Packetformat zumindestens von manchen Leuten als Problem (evtl. von euch ja nicht) angesehen wird, sind noch Probleme vorhanden. ;)
*post*

bluecode

  • Beiträge: 1 391
    • Profil anzeigen
    • lightOS
Gespeichert
« Antwort #23 am: 16. July 2006, 11:55 »
Zitat von: Legend
Aber ein Problem das gerne zitiert wird ist das LSB nur RPM berücksichtigt, so dass man bei Distributionen die z.B. mit apt-get laufen umwegen machen muss. Und solange ein einheitliches Packetformat zumindestens von manchen Leuten als Problem (evtl. von euch ja nicht) angesehen wird, sind noch Probleme vorhanden. ;)

Ok, das halte ich für ein Problem. Ich hatte bis jetzt nur Schwierigkeiten mit RPM (apg-get hab ich noch nicht probiert) und hab mir deshalb vor ca. nem 3/4 Jahr gentoo installiert. Und ich muss sagen emerge rockt einfach :)
lightOS
"Überlegen sie mal 'nen Augenblick, dann lösen sich die ganzen Widersprüche auf. Die Wut wird noch größer, aber die intellektuelle Verwirrung lässt nach.", Georg Schramm

kevin

  • Administrator
  • Beiträge: 2 767
    • Profil anzeigen
Gespeichert
« Antwort #24 am: 16. July 2006, 11:55 »
Du meinst, Distributionen, die deb benutzen. Denn apt ist unabhängig vom Paketformat. Letztlich ist das Paketformat aber auch nicht so wichtig (auch wenn da deb soweit ich weiß, ein bißchen mehr bietet als RPM), wenn die Paketnamen/-versionen und Verzeichnisstrukturen einheitlich wären. Dann könnte ich eine RPM unter Debian installieren (was in der Praxis oft geht) und dabei auch die Abhängigkeiten auflösen (was eben nicht geht).
Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end.

Legend

  • Beiträge: 635
    • Profil anzeigen
    • http://os.joachimnock.de
Gespeichert
« Antwort #25 am: 16. July 2006, 14:46 »
Zitat von: taljeth
Du meinst, Distributionen, die deb benutzen. Denn apt ist unabhängig vom Paketformat.


Gut, ich hab apt immer bislang mit .deb verbunden.

Zitat
Letztlich ist das Paketformat aber auch nicht so wichtig (auch wenn da deb soweit ich weiß, ein bißchen mehr bietet als RPM), wenn die Paketnamen/-versionen und Verzeichnisstrukturen einheitlich wären.


Nun, das gehört zu dem Teil von dem von mir beschriebenen Problem. ;)

Zitat
Dann könnte ich eine RPM unter Debian installieren (was in der Praxis oft geht) und dabei auch die Abhängigkeiten auflösen (was eben nicht geht).


Also Packages aus einer anderen Distro funktioniert oft? Glückspilz, bei mir ging das nicht so oft, und dann meistens war das auch nicht stabil - und konzeptionell besteht nun mal genau keine Absicherung das es dir mit einem Programm nicht auch mal so ergehen könnte.
*post*

kevin

  • Administrator
  • Beiträge: 2 767
    • Profil anzeigen
Gespeichert
« Antwort #26 am: 16. July 2006, 15:24 »
Zitat
Zitat
Letztlich ist das Paketformat aber auch nicht so wichtig (auch wenn da deb soweit ich weiß, ein bißchen mehr bietet als RPM), wenn die Paketnamen/-versionen und Verzeichnisstrukturen einheitlich wären.

Nun, das gehört zu dem Teil von dem von mir beschriebenen Problem. ;)

Ja, sicher. Aber das Problem ist nur zu vermeiden, wenn es keine Distributionen gibt. Das ist bei freier Software eigentlich kaum zu vermeiden - ansonsten müßtest du es von Anfang an allen recht machen.

Zitat
Also Packages aus einer anderen Distro funktioniert oft? Glückspilz, bei mir ging das nicht so oft, und dann meistens war das auch nicht stabil - und konzeptionell besteht nun mal genau keine Absicherung das es dir mit einem Programm nicht auch mal so ergehen könnte.

Naja, ich muß die Abhängigkeiten von Hand erfüllen, das ist problematisch, aber das Auflösen von Abhängigkeiten ist ja auch der Punkt, von dem ich gesagt habe, daß es nicht funktioniert. Ansonsten steht RPM unter Debian für mich ungefähr auf einer Stufe mit Wine Benutzen - es funktioniert oft irgendwie, aber es ist halt nicht das Gelbe vom Ei.
Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end.

Legend

  • Beiträge: 635
    • Profil anzeigen
    • http://os.joachimnock.de
Gespeichert
« Antwort #27 am: 16. July 2006, 15:49 »
Zitat von: taljeth
Ja, sicher. Aber das Problem ist nur zu vermeiden, wenn es keine Distributionen gibt. Das ist bei freier Software eigentlich kaum zu vermeiden - ansonsten müßtest du es von Anfang an allen recht machen.


Nun, in anbetracht das es so vergleichweise einfach ist zu forken bekommt man manchmal das Gefühl das dieses Mittel manchmal zu schnell angewandt wird. Ein guter Fork war damals egcs, oder wie der Abkömmling vom gcc 2.95 hiess. Der Fork war besonders deswegen gut weil die beiden dann irgendwann wieder ein Programm wurden.

Zitat
Naja, ich muß die Abhängigkeiten von Hand erfüllen, das ist problematisch, aber das Auflösen von Abhängigkeiten ist ja auch der Punkt, von dem ich gesagt habe, daß es nicht funktioniert. Ansonsten steht RPM unter Debian für mich ungefähr auf einer Stufe mit Wine Benutzen - es funktioniert oft irgendwie, aber es ist halt nicht das Gelbe vom Ei.


Ja, und ich sehe da Potenzial sowas bei einem eigenen OS zu vermeiden. ;)
*post*

kevin

  • Administrator
  • Beiträge: 2 767
    • Profil anzeigen
Gespeichert
« Antwort #28 am: 16. July 2006, 16:05 »
Bei Linux ist sicher auch das Problem, daß Linus am Anfang nicht festgelegt hat, wie ein Linux-Userland auszusehen hat, sondern eben nur den Kernel produziert und das Userland müssen sich die Anwender selbst zusammensuchen. Das ist z.B. bei BSD anders und davon gibt es auch nicht diese Vielfalt von Distributionen, aber trotzdem gibt es auch dort verschiedene Varianten. Man kann also sicher beeinflussen, wie stark die Tendenz zur Bildung von Distributionen ist, aber komplett vermeiden kann man sie genauso sicher nicht.
Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end.

Legend

  • Beiträge: 635
    • Profil anzeigen
    • http://os.joachimnock.de
Gespeichert
« Antwort #29 am: 16. July 2006, 16:56 »
Nun, die BSDs schaffen es schon mal das ganze Problem auf ein halbwegs vernünftiges Maß zu definieren. Was schliessen wir daraus? Man liefert besser zumindestens das grundlegende Userland (C-Library und so was) mit.
*post*

kevin

  • Administrator
  • Beiträge: 2 767
    • Profil anzeigen
Gespeichert
« Antwort #30 am: 16. July 2006, 17:32 »
Man könnte jetzt aber auch argumentieren, daß es von BSD nur nicht so viele Varianten gibt, weil es nicht so weit verbreitet ist wie Linux. Wenn man mal die wirklich großen Distributionen von Linux zählt, sind das nicht viel mehr als es BSD-Varianten gibt.
Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end.

Legend

  • Beiträge: 635
    • Profil anzeigen
    • http://os.joachimnock.de
Gespeichert
« Antwort #31 am: 16. July 2006, 18:12 »
Gut, dann hast du wohl mit den grössten Distributionen bestimmt sagen wir mal 90% der Linuxuser abgedeckt. Stellt sich nur die Frage wie weit man BSD auffächter, so ist PC BSD z.b. nur FreeBSD mit nem Aufsatz, aber binärkompatibel soll es sein.

Dann stellt sich natürlich die Frage, suche ich mir 3-4 meiner Lieblingsdistros raus und kompiliere für die?

Hmm, ja, stimmt, es muss doch irgendwie noch besser als bei BSDs gehen ...

EDIT: Verschiedene Konfigurationstools oder verschieden aussehende Programme  die ein OS von der CD z.B. installieren kann man ja machen, ohne das die Binärkompatibilität leidet. Durchaus geht das Problem wohl noch tiefer als nur Package Management, so ist speziell bei Linux die oft mutierende ABI vom g++ ein Störfaktor bei dem kein Package Manager der Welt endgültig helfen kann.
*post*

 

Einloggen