Beiträge anzeigen

Diese Sektion erlaubt es dir alle Beiträge dieses Mitglieds zu sehen. Beachte, dass du nur solche Beiträge sehen kannst, zu denen du auch Zugriffsrechte hast.


Nachrichten - Legend

Seiten: 1 ... 3 4 [5] 6 7 ... 32
81
Lowlevel-Coding / ...
« am: 18. July 2006, 10:27 »
Zitat von: hannibal
Zur Not koenntest du dir den Linux Source anschauen, der Bootcode ist da vielleicht aufschlussreich.


int grrrr;

sag ich dazu nur ;)

(war bei 2.0er oder 2.2er Kernel im Floppytreiber. ;)
82
Lowlevel-Coding / Bochs Debugmodus unter Linux
« 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.
83
Lowlevel-Coding / Bochs Debugmodus unter Linux
« 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.
84
Lowlevel-Coding / Bochs Debugmodus unter Linux
« 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. ;)
85
Lowlevel-Coding / Bochs Debugmodus unter Linux
« 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.
86
Das Wiki / Lowlevel?
« am: 16. July 2006, 10:26 »
Um dann das Wiki aufzubauen, kannste gut im Forum Dinge nachschlagen und als Referenz nehmen.

Aber wenn wirklich kein Administrator mehr hier rein guckt wäre es wohl generell gut sich mal zu überlegen das ganze neu aufzusetzen um wieder die Kontrolle zu haben.
87
Lowlevel-Coding / Bochs Debugmodus unter Linux
« 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. ;)
88
Lowlevel-Coding / Bochs Debugmodus unter Linux
« 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
89
Offtopic / OS-Entwickler Kevin hat wieder zugeschlagen
« am: 15. July 2006, 11:58 »
Wobei mir eins aufgefallen ist: VMWare (mal nicht für OS Development) auch nur installiert zu haben stört mich beim WoW spielen da ich nur 1 GB RAM habe. Denn ich habe immer erstmal ein paar Prozesse die zu VMWare im Hintergrund laufen und die ziehen doch etwas Speicher.
90
Lowlevel-Coding / Bochs Debugmodus unter Linux
« am: 15. July 2006, 11:07 »
Zitat von: taljeth
Was praktisch bedeutet, daß es eine zentrale Instanz gibt, die sagt, was es gibt und was nicht. Sowas hat sich zum Glück noch nicht einmal Microsoft getraut. Und wenn man sich mal vorstellt, daß diese eine zentrale Instanz ausfällt, dann ist es sowieso vorbei.


Jeder einzelne Linux-Distributor traut sich sowas für seine Distribution.

Zitat

Aber grundsätzlich ist das natürlich schon eine Strategie, wie man es sich einfach machen kann. Siehe Apple, die nur eine sehr begrenze Hardwareauswahl unterstützen müssen, weil es etwas anderes als die Standardauswahl eben nicht gibt.


Jo, und bei Linuxdistributionen kann ich entweder das was schon in Packages verpackt wurde nehmen oder auf doch nicht immer unproblematische (und speziell für das kompilieren, zu zeitaufwändige) Umwege auswechen.

Zitat
Falls du es nicht bemerkt hast: Du beschreibst genau die Realität unter Linux. Das Problem bei der Überlegung: Der Autor muß erstmal ein Repository mit den Binärpaketen bereitstellen. Und das geht eben an der Realität vorbei, besonders wenn man das Paket mit speziellen Optionen (also z.B. Bochs mit Debug) kompiliert haben möchte.


Nein, unter Linux habe ich nicht ein verteiltes Repository sondern viele verschiedene, zueinander binär-inkompatible Repositories. Daher kommen ja solche Probleme, denn als Autor kann ich nicht sinnvollerweise für jedes Repository ein Binary zur Verfügung stellen. Wenn ich das probieren würde, würde ich ja mehr für verschiedene Distros kompilieren als selber zu programmieren.

Das der Autor selber Binaries zur Verfügung stellen kann ist genau das warum man unter Windows keine Probleme hat wenn man unbekannte Software XYZ ausprobieren will. Vorrausgesetzt XYZ ist so unbekannt das meine Linuxdistribution die Linuxvariante XYZ nicht im Angebot hat. Windows muss gar nicht die Software selber so mitliefern wie eine Linuxdistribution.

Und btw - welcher Volltrottel (sorry) hat bei der Distro von scales denn bitte Bochs ohne den Debugger übersetzt oder nicht als Extrapacket bereitgestellt (ich denke mal er hat diese Option vor dem Thread hier überprüft)? Ich hab auch schon Squids gesehen die so kompiliert waren das man über sie keine Foren wie dieses hier benutzen konnte.
Wenn man solche unsinnigen Optionen entfernen würde, dann gäbe es gar nicht so viel Auswahl Programme verschiedene zu kompilieren.
91
Lowlevel-Coding / Bochs Debugmodus unter Linux
« am: 14. July 2006, 14:43 »
Ne, das der Autor von Bochs ein funktionsfähiges Binary bereit stellen kann ist eine Vorraussetzung die für mein OS dann hätte. Bei Windows geht das ja auch - bei Linux hingegen nicht, da kannste höchstens für ein paar Distros selber was machen aber für alle, völlig unmöglich. Ausser du kompilierst statisch. ;)

Nur sind Installer bei der Linuxcommunity recht unbeliebt, und zwei echte Gründe habe ich gefunden:

1. Installer schleppen häufig Dinge mit sich rum die Anwendungen dann doch teilen (z.B. VB-Runtimes ;)) Statisch gelinkte Binaries haben das selbe Problem.
2. Unter Windows gibt es kein Kommando um mal eben alles zu updaten (wie gut das in jeder Situation ist, sei mal dahingestellt)

Tja, wie kombiniert man beides?

Also mein Ansatz ist bislang - es gibt nur ein Repository für das OS. Ein Fork ist immer ein Problem wenn man solche Probleme wie ich sie im Visier habe vermeiden will.

Desweiteren muss das ganze etwas verteilter sein. Eine Idee wäre z.B. das jeder Autor sein eigenes kleines Repository hat auf seiner Webseite und Abhängikeiten repository übergreifend sein können. Also wenn ich von Entwickler A mir ein Package ziehen, doppelt draufklicken in der GUI startet dann automatisch den grafischen Packagemanager der das Ding installiert und die Abhängigkeiten aus den Repositories von den Entwicklern B und C zieht. Dann hätten wir ein grosses, verteiltes Repository. Keine zueinander Distribution wo ich in Distribution A Programm B finde was ich lieber mit Distribution C benutzen würde.

Das grösste Problem ist dabei nur, was passiert wenn Entwickler B seine Seite dichtmacht, hmm. Jedem Package sollte man wohl eine eindeutige ID zuweisen und ein BitTorrent-ähnliches Netzwerk als Ausweichmöglichkeit wäre wohl nicht verkehrt. ;)

Dann kann ich auch meinem Packagemanager sagen, update mal alle Programme, und er zieht sich alles aus den Repositories selber, ich muss natürlich jedes installierte Packet seine Herkunft speichern lassen.

Apropos Packagemanager, das ganze funktioniert nur richtig wenn es genau 1 Format gibt.

Das ganze ist natürlich komplizierter als das was bislang gemacht wird, aber was bislang gemacht wird erfüllt nun mal nicht meine Anforderungen, ich finde so wie es bislang eingesetzt wird Package Managment ehrlich gesagt eher hinderlich als förderlich.

Bei FreeBSD wäre es wohl auch Möglich Binaries anzubieten, aber damit alles schön automatisch abläuft muss man die z.B. auf die FTP Server von denen kriegen usw. Da ist also auch noch Potential es besser zu machen.

Ich habe mal gehört das man auch bei apt-get oder ähnlichem verschiedene Repositories nebeneinander benutzen kann, aber das ist im Moment eher als schmückendes Beiwerk eingesetzt und da diese Repositories auf Debian und verwandte Distros beschränkt sind für das Gesamtbild wertlos.

So könnte man die Vorteile von Installern (Finden, Ziehen, Installieren, Läuft im Vergleich zu Finden, Nachgucken ob es in der Distro ist, wenn ja gut, wenn nicht extrem beschissen) und Packages (Typischerweise kleiner, besser zu updaten) vereinen.
92
Lowlevel-Coding / Bochs Debugmodus unter Linux
« am: 14. July 2006, 11:14 »
Sourcen compilieren nur um ein Programm auf einem einzigem Rechner zu installieren.
93
Lowlevel-Coding / Bochs Debugmodus unter Linux
« am: 14. July 2006, 09:34 »
Genau, der Weg den ich in einen OS das ich schreiben würde NICHT als Ausweg akzeptieren würde.
94
Lowlevel-Coding / Bochs Debugmodus unter Linux
« am: 13. July 2006, 23:30 »
Zitat von: taljeth
Ganz so extrem würde ich das nicht sagen, aber grundsätzlich hast du recht - nicht immer geht alles problemlos. Nur glaube ich, daß eine .deb per alien installieren sicher auch nicht in 100% der Fälle gutgeht...


Das stimmt wohl auch. Abgesehen von den Referenzen in Bibliothek die so ein installiertes Bochs nachher möglicherweise gar nicht findet. Oder man könnte sich ja praktisch alles doppelt installieren, einmal normal, und einmal für Bochs, ...
95
Lowlevel-Coding / Bochs Debugmodus unter Linux
« am: 13. July 2006, 20:30 »
Also ich muss sagen, "einfach" und "selber bauen" ist eine Kombination die nur mit Glück funktioniert. Bestes Beispiel waren C++ Programme und der Wechsel von Gcc, ich glaub 3.3, auf 3.4 und die total veränderte Templatebehandlung.

Und schon an anderen Stellen gab selber kompilieren schon mehr als genug Probleme und ich möchte eigentlich nicht unnötigerweise in mir fremden Quellcode rumprobieren - aber bei Linux war das jedes mal irgendwann nötig.
96
Lowlevel-Coding / Bochs Debugmodus unter Linux
« am: 11. July 2006, 19:43 »
Gibts nicht bochs_dbg?
97
Lowlevel-Coding / Sound-Ausgabe
« am: 08. July 2006, 00:29 »
Na ja, ganz alte Spiele evtl. Aber so ein DBZ ME2 hab ich noch NIE irgendwie richtig unter XP zum laufen bekommen ...
98
Lowlevel-Coding / Fonts ...
« am: 06. July 2006, 16:07 »
Ich glaube die kann zu Puffern im Speicher reden, dann also jeden Buchstaben in einen Puffer rendern und dann die Puffer passend in den Bildspeicher kopieren, wäre eine von vielen Möglichkeiten.
99
Lowlevel-Coding / Kommunikation zwischen Kernel und Programm
« am: 06. July 2006, 16:06 »
Was bedeutet denn "nichts"? NULL, falsche Addresse? Hast du auch immer brav mit unsigned gearbeitet? ;)

Ist deine Architektur flach, d.h. ist Addresse XYZ für Kernel und Applikation die selbe Speicherzelle?
100
OS-Design / Re: Idee zum 36 bzw. 64 bit großen Addressraum
« am: 06. July 2006, 16:04 »
Zitat von: BadBeu
im Buch von Tanenbaum habe ich eine interessante Idee gelesen.Da ja ab dem Pentium II (oder III - muss ich nochmal nachlesen) ja lineare Addressräume bis 64 GByte unterstützt werden bzw. bei 64 bit CPUs sogar einige tausend Terrabyte, habe ich mir gedacht, da ich sowieso auf moderne Architekturen setzen wollte, dass ich Dateien nicht nur lese, sondern einfach komplett in den Addressraum des Programs lade, das diese Datei öffnet.


Jop, unter Linux könnte dir mmap wahrscheinlich weiterhelfen, Windows hat da auch Mechanismen dafür.

Zitat

1. Der Page-Daemon muss das Dateiformat verstehen, in welchem die Dateien vorliegen. Wenn man also mehrere Datei-Format unterstützt müsste dann immer zunächst der Treiber für dieses Format aufgerufen werden - d.h. mehr Overhead


Wozu? Bei Pagefault einfach die entsprechenden 4kb in denen der Offset der zum Fault geführt hat aus der Datei laden. Wenn du physische Speicherseiten freimachen willst ein paar dieser Seiten in die Datei speichern. Kein Problem, auch ohne Kenntnis des Dateiformates.

Zitat

2. Der Programmierstil ändert sich gravierend gegenüber anderen OS. Ich bekomme dann nicht mehr meine Bytes, die ich auslesen wollte, sondern einen Pointer zum Begin der Datei, die in meinem Addressraum liegt. Durch einfach Pointerarithmetik komme ich dann zu meinen Bytes, die ich haben möchte, aber es ist eine Umstellung.


Manche Programme müssten eher umgestellt werden wenn du so eine Funktion nicht bietes, hab leider grad nicht den c't Artikel wo darüber (im Rahmen von 64 Bit glaub ich war das) gesprochen wurde.

Zitat
Haltet ihr sowas für realisierbar. Eben einmal OS-technisch und einmal User-technisch?


Nicht nur für realisierbar, sondern sogar schon realisiert.
Seiten: 1 ... 3 4 [5] 6 7 ... 32

Einloggen