Thema: Wir suchen...

[stultus]

hängt mit dem Einsatz von dash statt bash als Standardshell zusammen, iirc. Versuch mal /bin/sh zu löschen und auf /bin/bash zu linken, dann sollte alles gehen.

[bluecode]

Weißt du ob das irgendwelche ungewollten Auswirkungen hat? Ich mein Ubuntu wird nicht zum Spaß dash einsetzten, oder?

[kevin]

dash soll angeblich schneller sein. Kann auch gut sein, wenn es dafür nichts mehr kann. Mit bash als /bin/sh wird man jedenfalls definitiv weniger Probleme haben als mit dash, auch mit anderen Projekten. Zusammengefaßt: Nachteil der Rückersetzung ist, daß Skripte etwas langsamer laufen; Vorteil ist, viele Skripte laufen überhaupt erst mit bash.

Übrigens ist mittlerweile eine erste fdisk-Version eingecheckt, vielen Dank an DarkThing. In Sachen Usability (und auch featuremäßig) gibt noch manches zu tun, aber hey, es läuft.

[kevin]

Nicolas hat sich gemeldet, daß er am Setupprogramm basteln möchte, ich habe die Liste entsprechend aktualisiert. Außerdem habe ich zwei neue Punkte hinzugefügt: Zum einen könnte die Shell ein paar Erweiterungen vertragen, z.B. Dateinamenvervollständigung oder Auswerten von Umgebungsvariablen. Wer sich die Shell anschaut, findet sich auch ein paar andere Sachen, wo er anpacken möchte - so genau wollen wir das gar nicht vorgeben.

Zum anderen drücken wir uns seit Ewigkeiten darum, curses zu portieren bzw. zu implementieren, weil es etwas zu groß wirkt, um mal so nebenbei gemacht zu werden. Allerdings fehlen uns dadurch Ports von vielen Programmen mit Textmodusoberfläche. Falls also jemand Lust hätte, wäre cool.

[ChristianF]

Also
da ich ja versuche den VI zu portieren, ist ncurses für das Syntax Higlighting zwingend notwendig.
Deshalb arbeite ich gerade an einer Portierung von ncurses, habe aber wegen meiner Ausbildung nicht sehr viel Zeit und komme deshalb auch nicht so schnell voran, wie ich es gerne hätte. 
 
Gruß
ChristianF

[kevin]

Ah, gut. Das klang beim letzten Mal noch etwas unentschlossener. ncurses ist ja doch ein rechter Brocken, da ist es nur verständlich, wenn es etwas länger dauert (wenn man mal mit dem billigen sis900-Netzwerktreiber vergleicht, an dem ich jetzt schon Ewigkeiten hänge... ).

Vielleicht ein kleines Statusupdate - wie weit bist du denn im Moment? Könntest du Hilfe von anderen gebrauchen (vorausgesetzt natürlich immer, irgendjemand interessiert sich dafür) oder soll ich den ncurses-Eintrag aus der Liste wieder entfernen?

[ChristianF]

Ich bin noch am "verstehen" des Codes, da das ganze doch recht komplex ist und ich nicht unbedingt so viel Zeit habe.
Die VI portierung danach ist wie ich das bis jetzt überblickt habe dann recht einfach, da nur die Datei mit der Abfrage eines Tastendrucks geändert werden muss.
Den Rest macht ja dann ncurses.
Aus meiner Sicht kannst du ncurses aus der Liste raus nehmen oder du schreibst meinen Name dahinter.

[Svenska]

Weißt du ob das irgendwelche ungewollten Auswirkungen hat? Ich mein Ubuntu wird nicht zum Spaß dash einsetzten, oder?

Ubuntu möchte die Leute dazu zwingen, auch nach /bin/bash zu verlangen, wenn eine bash notwendig ist. Die dash ist eine Bourne-kompatible Shell und damit POSIX-kompatibel; aber viele Scripteschreiber benutzen bash-Features, ohne es zu wissen.

Das stört besonders die Nicht-Linuxe (*BSD), weil dort die bash eben nicht Standardshell ist, sondern csh und andere. Der "richtige" Weg ist, die Scripte anzupassen und auf bash zu verweisen.

Da aber fast alle Linux-Distributionen /bin/sh auf /bin/bash linken, kannst du das auch tun. Das ist dann ein "dirty hack", den alle machen (, und damit die Misere erst erschaffen haben). Du wirst jedenfalls keine ungewollten Auswirkungen haben.

[Devproger]

Hi!

Ich hatte schonmal eine (äußerst, äußerst, ÄUßERST) simple Version eines Editors (wenn man das denn nennen konnte) geschrieben, allerdings war ich dann mit anderen Dingen und der Schule beschäftigt...

Da ich im Moment viel Zeit habe und sehr viel Lust dazu habe, an LOST mitzuwerkeln, würde ich gern bei den User-Programmen mithelfen.

Ich würde gern bei jemanden im Team mitprogrammieren, kann aber auch alleine etwas auf die Beine stellen

Eine Idee wäre doch übrigens (was aber auch nur mit curses möglich wäre?), eine Art Midnight Commander (oder Norton Commander für alles DOSser ) zu schreiben. Desweiteren sind so viele kleinere Sachen eine Idee, wie ein Kalender oder einen erweiterten Taskmanager (wie top unter Unix).

Also, ich biete meine Hilfe gerne an!

[Devproger]

Also ich hab ja schon im IRC geschrieben dass ich gerne mich an die Shell ranmache. Bin dabei, die Dateinameerweiterung zu implementieren (bzw. hab sie schon implementiert, muss aber Linux installieren um alles zu testen) sowie endlich die Pipes zu implementieren.

[ChristianF]

Ahoi Ahoi,
ich meine den code von ncurses jetzt soweit verstanden zu haben, damit ich mit der Portierung anfangen kann.
 
Ich habe mir grad ncurses 5.6 geholt und werde heute Abend damit beginnen, das zu portieren.
Wie ich das Compilieren muss und alles, werde ich noch herausfinden müssen, was allerdings kein Problem darstellen sollte.

Gruß Christian

[Feuermonster]

Ich wuerde auch gerne meinen kleinen Teil zum Community-OS beitragen. Gibt es vlt schon irgendwelche Dokumente wie man Applikationen hinzufuegt/kompiliert. (Evtl ist auch eine API-Dokumentation vorhanden?)

[bluecode]

Die API ist POSIX für normale Anwendungen. Eine Anwendung kommt meines Wissens nach in src/modules/c/<appdir>, schau dir am besten mal die anderen apps dadrin an, um herauszufinden was du buildtechnisch noch tun musst.

[kevin]

POSIX ist nicht unbedingt die native API für LOST, sondern mehr eine Art Kompatibilitätsschicht. In manchen Fällen ist es wahrscheinlich trotzdem das beste, POSIX-Funktionen zu verwenden, aber zum Beispiel Dinge wie Netzwerk sind alles andere als POSIX-artig. Als eine Art Dokumentation der API können die Headerdateien in src/modules/include herhalten.

Für neue Apps einfach das Verzeichnis anlegen und eine Makefile.all kopieren und anpassen.

Und ansonsten, den IRC-Channel kennst du ja.

[ChristianF]

Nun da ich gestern erfahren habe, dass ncurses schon portiert sei, habe ich mir etwas anderes vorgenommen.
Und zwar habe ich hier ein paar alte Grafikkarten herumliegen und in Testrechnern verbaut. Da ich mich so oder so mit diesen beschäftigt hätte, kann ich auch Treiber dafür schreiben.
Die Frage ist jetzt nur, es hieß es gibt im CDI ein Grafik Subsystem. Gibt es dazu schon eine Dokumentation?
Des Weiteren habe ich noch eine andere Frage: Im Internet habe ich eine Datenbank gefunden, die besagt, dass z.B. die ATI Mach64 VT die ID 0x4654 hat. Wenn ich das dann so richtig verstanden habe, sind die IDs IDs von ATI Karten. Das würde heißen, dass andere Hersteller, die den gleichen Chip benutzen, aber andere IDs haben oder liege ich da falsch?
 
Gruß Christian
 
*EDIT*
Wie sieht es mit dem VBE/AF Standard aus?
Wäre es eventuell nicht besser Treiber nach diesem Standard zu schreiben?

[kevin]

Die Frage ist jetzt nur, es hieß es gibt im CDI ein Grafik Subsystem. Gibt es dazu schon eine Dokumentation?

Am besten mal im IRC phoenix oder janosch fragen, die haben die aktuelle Headerdatei.

Des Weiteren habe ich noch eine andere Frage: Im Internet habe ich eine Datenbank gefunden, die besagt, dass z.B. die ATI Mach64 VT die ID 0x4654 hat. Wenn ich das dann so richtig verstanden habe, sind die IDs IDs von ATI Karten. Das würde heißen, dass andere Hersteller, die den gleichen Chip benutzen, aber andere IDs haben oder liege ich da falsch?

PCI-Karten haben eine Vendor-ID und eine Device-ID. Was du hast, scheint die Device-ID zu sein, d.h. eine andere Karte eines anderen Herstellers könnte dieselbe ID haben. Erst wenn du noch die Vendor-ID von ATI dazunimmst, wird die Sache eindeutig.
 

*EDIT*
Wie sieht es mit dem VBE/AF Standard aus?
Wäre es eventuell nicht besser Treiber nach diesem Standard zu schreiben?

Welchen Vorteil hätte man davon?

[ChristianF]

Des Weiteren habe ich noch eine andere Frage: Im Internet habe ich eine Datenbank gefunden, die besagt, dass z.B. die ATI Mach64 VT die ID 0x4654 hat. Wenn ich das dann so richtig verstanden habe, sind die IDs IDs von ATI Karten. Das würde heißen, dass andere Hersteller, die den gleichen Chip benutzen, aber andere IDs haben oder liege ich da falsch?

PCI-Karten haben eine Vendor-ID und eine Device-ID. Was du hast, scheint die Device-ID zu sein, d.h. eine andere Karte eines anderen Herstellers könnte dieselbe ID haben. Erst wenn du noch die Vendor-ID von ATI dazunimmst, wird die Sache eindeutig.

Die Vendor-ID von ATI ist 0x1002. Dann wäre das geklärt.
 

*EDIT*
Wie sieht es mit dem VBE/AF Standard aus?
Wäre es eventuell nicht besser Treiber nach diesem Standard zu schreiben?

Welchen Vorteil hätte man davon?

Nun die Treiber wären zum einen nach dem festgelegten Standard und zum anderen kann man eben diese Treiber dann auch flexibler einsetzen (Windows, Linux), wenn ich mich jetzt nicht irre. 
Zumindest meine ich, dass das so sinngemäß richtig übersetzt ist

This document defines the interface for a new operating system portable, loadable device driver architecture that will provide access to accelerated graphics hardware.

[bluecode]

Nun die Treiber wären zum einen nach dem festgelegten Standard und zum anderen kann man eben diese Treiber dann auch flexibler einsetzen (Windows, Linux), wenn ich mich jetzt nicht irre. 
Zumindest meine ich, dass das so sinngemäß richtig übersetzt ist

This document defines the interface for a new operating system portable, loadable device driver architecture that will provide access to accelerated graphics hardware.

Vergiss am besten den VBE/AF Standard Hast ja selbst im anderen Thread festgestellt, dass das ein wenig veraltet ist... Baut lieber in mit/innerhalb von CDI was sinnvolles eigenes. VBE/AF ist mit ziemlicher Sicherheit auch ein ABI-Standard und das macht es imho schonmal total unbrauchbar.

[ChristianF]

Nun die Treiber wären zum einen nach dem festgelegten Standard und zum anderen kann man eben diese Treiber dann auch flexibler einsetzen (Windows, Linux), wenn ich mich jetzt nicht irre. 
Zumindest meine ich, dass das so sinngemäß richtig übersetzt ist

This document defines the interface for a new operating system portable, loadable device driver architecture that will provide access to accelerated graphics hardware.

Vergiss am besten den VBE/AF Standard Hast ja selbst im anderen Thread festgestellt, dass das ein wenig veraltet ist... Baut lieber in mit/innerhalb von CDI was sinnvolles eigenes. VBE/AF ist mit ziemlicher Sicherheit auch ein ABI-Standard und das macht es imho schonmal total unbrauchbar.

Ich werde mich beugen. 
Allerdings werde ich den Standard etwas genauer unter die Lupe nehmen, da er ja nur einen gewissen Funktionsumfang definiert.

[bluecode]

Ich werde mich beugen. 

Ich habe keine normative Macht, va. nicht bei LOST und va. letzteres ist natürlich auch gut so