Die screenshots sehen echt gut aus! Werde es auf jedenfall mal testen, nur schade das es mit GNU/Linux filesystemen nicht zurecht kommt :( Ich bin bei solchen Sachen immer wieder begeistert was alles auf eine Diskette passt! Es wird immer vom Tod der Diskette, bei dem heutigen Datenaufkommen, gesprochen. Solche Beispiele zeigen aber, daß man schon noch einiges auf eine Diskette bekommt, wenn man nur gut genug mit seinem vorhanden Speicher umgeht!
Von Reiner Schischke am Di, 13. Mai 2003 um 23:22 #
Salut cc, hattest du das todo gesehen? Dort steht, dass der fd/hd support noch verbessert werden muss usw.
To do: * improved fd/hd support * boost for gui (amd write-combine mtrr) * .. and other things you see missing * to-do -list
Mit nur ca. 12 Leuten haben die schon 'ne Menge bewegt (besser garnicht mal 'ne Menge, eher ganz wenig, ca 1.44 MB) Dass da noch einiges an Arbeit lauert, ist wohl klar.
Mmh, komplett in Assembler... Ich meine selbst OSes für eingebettete Systeme werden nicht mehr komplett in Assembler geschrieben. Da fällt mir ein, was ist eigentlich aus Atheos geworden? Gibts es das OS noch?
Wie soll sich das lohnen? Drei Jahre Arbeit, und das System verfügt weder über ein sollvolles Dateisystem, noch Treiber, noch Applikationen, weil es weder Windows- noch Linux-Apps ausführen kann. Und benötigt trotzdem 32 MB Speicher.
Es wäre viel sinnvoller, eine Distribution mit einem aktuellen Linux-System zu machen, die in 8 MB läuft. Vor Jahren war es möglich, Linux mit Kernel 1.2 und TinyX in 2-4 MB laufen zu lassen, aber es gibt nichts Aktuelles mehr. (Oder doch? Irgenwo habe ich was gelesen von einem System, das jetzt auf dietlibc beruht.) Rechner, die mit 8 MB RAM ausgestattet sind und nicht weiter aufgerüstet werden können, gibt es bestimmt noch etliche. Daher wäre ein solches Projekt, vielleicht auf Basis von Gentoo oder einem ähnlichen, genial.
Mir fällt zwar spontan kein Name ein, ich bin mir aber ziemlich sicher dass es 1-2 (halbwegs) aktuelle Distributionen die mit 8 MB Ram zufrieden sind gibt. Ich muss mal nachschauen.
hi, auf busybox-basis laesst sich ein linux-system (2.2.x) mit einer 1.4mb diskette auf einem 386er mit 2mb ram betreiben.. (inklsuive ftp-/telnet-server)...
das hatte ich schon vermutet, daß es mit Slackware geht. Aber meine Idee ging mehr dahin, eine auf Speicherbedarf optimierte Disti zu machen. Und X11 müßte auch mit dabei sein. Zumindest mit fvwm oder icewm als Window-Manager. OK, Applikationen wie OpenOffice oder Mozilla wird man nicht hinbekommen, daß sie in 8 MB laufen, da müßte man Alternativen suchen (Abiword und Netscape 3 oder so...)
Tja, das ist zweifellos eine starke Leistung! Solche Dinge zeigen mir immer wieder, dass eben Assembler nicht nur für MCUs zu gebrauchen ist. In C wäre den entwicklern sicher nicht die Performance sondern die Bequemlichkeit im Wege gestanden (es gibt mittlerweile sehr schnelle Compiler, die leider meistens kommerziell sind)... Wie schnell ist doch eine integer Variable definiert, wo auch eine unsigned short int gereicht hätte...
> Wie schnell ist doch eine integer Variable definiert, wo auch eine unsigned short int gereicht hätte...
Nach meiner Erfahrung passiert das nicht. Es sind eher die "Unarten" eines Compilers, die ihn letztlich als Zweiten durchs Ziel kommen lassen. Etwa, wenn er Parameter bei Calls unbedingt über den Stack übergeben will. Das kostet manchmal "Unmengen" von Code. Da habe ich vor Projektstart des öfteren einige Zeit investiert, um ihm sowas abzugewöhnen.
Auf der anderen Seite hat ein Compiler den Vorteil, dass er Zufälle ausnutzen kann. Hat er einen Offset eines Wertes in einer Datenstruktur in einem Register und braucht eine Konstante für eine Parameterübergabe, die zufällig den selben Wert hat, so kann er einfach den Registerinhalt weiterverwenden. Bei Inline Funktionen macht er das ganz gern mal. Mit Macros in Assembler bin ich da aufgeschmissen. Überhaupt kann er Inline Code auch mal anders übersetzen, wenn er meint, irgendeinen Registerinhalt kann er noch brauchen. Ein Compiler schreibt das Programm bei jedem Übersetzungslauf neu. Bei Assembler geht das nicht.
Insgesamt habe ich festgestellt, dass ein Gemisch aus Assembler und Compilerprogrammen praktisch die gleiche Programmgröße ergibt, wie reiner Assembler.
Assembler nur da wo es signifikante Geschwindigkeitsvorteile gibt (z.B. Interrupthandler für serielle Schnittstelle, Speicher kopieren, o.ä.) und der Rest muß übersichtlich und strukturiert sein, sonst verliert man bei größeren Projekten schnell den Überblick. Es lonht sich kaum eine Textausgabe in Assembler zu schreiben, da das sehr unübersichtlich ist. Ich programmiere in Pascal und wo es auf Geschwindigkeit ankommt wird direkt in Assembler programmiert. Außerdem hat das den Vorteil der Portierbarkeit!
> ...der Rest muß übersichtlich und strukturiert sein
Erwischt ;)
Das Assemblerzeugs muss genauso strukturiert und übersichtlich sein. Da es von der Menge meist größer ist, habe ich meist eine Strukturebene mehr. Wenn's irgendwie unübersichtlich wird, find ich nix mehr. Das ist dann der Tod jedes Zeitplans.
> Außerdem hat das den Vorteil der Portierbarkeit!
Das war der Punkt, an dem ich beim Lesen des Artikels zuckte.Mein Hang zu Assembler rächt sich immer bitterlich beim Wechsel der CPU.
Ich gebe zu: Tolle Leistung. Tolle Optik. Aber damit hat es sich leider schon. Wenn die Jungs das machen, um Assembler zu lernen und um etwas tolles zu zeigen: Sehr schön. Haben wir vor 16 Jahren auch auf dem C64 gemacht, Demos programmiert, jedes Bit umgedreht, den SID und GEOS beackert. Alles gut und schön. Und -damit man mich nicht falsch versteht- ich habe echt Achtung vor ihren Fähigkeiten und der programmiererischen Leistung.
Aber: Wenn die Jungs glauben, dass wir so etwas tatsächlich brauchen, muss ich hier mal deutlich Fehlanzeige diagnostizieren... - Die Binsenweisheit, dass Assembler die schnellste Programmiersprache ist, ist ja rund 20 Jahre alt oder älter. - Dass C-Compiler einen gewissen Overhead produzieren, haben vielleicht Ken Thompson und Dennis Ritchie auch schon bemerkt.
Ich frage mich, ob wir in der Zwischenzeit nicht ein paar Neuerungen an der Hardware-Front hatten: - Die Zip-Disk ist mit 100 MB schon fast wieder out, da es USB-Sticks mit 128 MB gibt. - CF-Medien werden immer Voluminöser, IBMs 1GB-CF-II-Card ist auch nicht wirklich klein.
@ASM > Hoffentlich lohnen sich diese Projekte. Die Projekte lohnen sich eben nicht, weil sie "niemand" mehr braucht. Wir leben in der "Basar-Gesellschaft", in der ein derartiges Tempo herrscht, dass alte Ware sofort verworfen wird. Der Basar ist tatsächlich das ideale Bild für den Markt, an dem alle Produkte, Software, sonstige Projekte miteinander zu konkurrieren haben und da sind die Jungs aus ihrer Assembler-Kathedrale eben fehl am Platz.
Ich betone es noch mal: - Nix gegen Assembler - Nix gegen fähige Assembler-Programmierer - Nix gegen Lernprojekte, an denen man seine Fähigkeiten testet.
Aber Software, die die Welt nicht braucht, ist eben mehr als flüssig. Vielleicht kann man mich ja überzeugen, indem man konkrete Nutzbeispiele für ein derartiges MenuettOS anführt: - Webserver? - Embedded-Bereich? - Hardware? Steuerung, Regelung? - Echtzeitfähigkeit? - Wie implementiert? - Wie funktioniert der Scheduler? - Können andere Kernelprogrammierer etwas daraus lernen? - Sind die verwendeten Mechanismen abstrahierbar und damit für andere Projekte nutzbar?
Vielleicht klingt das alles zu hart, stimmt mich um mit guten Gegenargumenten...
hi, tja... das projekt ist echt KRASS... hut ab vor diesen programmieren !
nun zu deinen aufuehrungen... du hast im 'prinzip' recht... der effektive nutzen ist zz fuer einen user nicht wirklich gegeben. aber auch linux und mircosoft haben mal klein begonnen. wenn die entwickler nochmal solange daran arbeiten wiesiehs jetzt schon getan haben wird man dieses os sicherlich schon fuer einige einsatzgebiete sinnvoll nutzen koennen.
klar, wirklich noetig ist das in zeiten von 100gb-platten und mehr sicherlich nicht mehr. aber gerade so ein projekt zeigt den irrsinn der derzeitigen software/hardware-entwicklung. immer leistungsfaehigere betriebssteme, die wiederum die gesamt leistungsfaehichkeit der hardware verbrauchen. und alles nur weil die leute in java/visualbasic usw programmieren. unter linux ist die entwicklung der glibc und des gcc's aus meiner sicht auchnicht wirklich optimal. ein einfaches statisch kompiliertes 'hello world' belegt umdie 400kb... da waerdie diskette gleichschon zu nem drittel gefuellt - egal wir haben ja noch 2 drittel (und ne menge neue disktetten im schrank) :-)
da sind neue projekte wie dieses hier sicherlich ein guter ansatz....
naja, dass Assember veraltet oder nicht mehr genutzt wird, stimmt so nicht! (falls du das versucht hast auszudrücken)
Jedoch auf PCs nicht mehr sinnvoll. Es gibt jedoch Chipkarten, wo immernoch in ASM Programmiert wird, aus guten Grund. Dort wird auf jedes Byte und Register geachtet.
Ich selber habe sowas mal Programmiert. Da bekommt man nicht viel zur verfügung gestellt, wo das Program laufen kann.
Bei PCs ASM zu verwenden hat bereits den grossen Nachtel, dass man damit nur an ein CPU Optimieren wird, oder vieleicht noch ein zweiten. Ab da wird der Aufwand zu gross. Damit ist das OS später für neuere CPUs nicht mehr preformant und ein 'dummes' C-Programm mit Overhead ist dann schneller.
Esseiden, die Jungs haben modular genug programmiert und können sowas anpassen, was wiederrum das Code verlangsamt.
Naja sie werden schon wissen, warum sie sowas Programmieren. Vieleicht auch nur um gute Arbeitstellen zu bekommen
> Aber: Wenn die Jungs glauben, dass wir so etwas tatsächlich brauchen, muss ich hier mal deutlich Fehlanzeige diagnostizieren.. > Aber Software, die die Welt nicht braucht, ist eben mehr als flüssig.
Mich verblüfft diese reine Zweckgerichtetheit immer wieder. Die Leute hinter diesem Projekt haben Spass an der Sache - braucht es auch nur einen einzigen Grund mehr? Ausserdem sind sie auch noch freundlich und geben den Sourcecode für alle zum Basteln, Spielen, Erweitern, Lernen und Einsetzen frei.
Fragst Du auch bei nethack, Tuxracer (OpenRacer), PySol, FrozenBubble usw. immer sofort nach einem Sinn bei der Sache? Keiner - ausser das es Spass macht. Einerseits den Entwicklern und andererseits den Usern/Spielern. Und so kannst Du MenuetOS auch betrachten (ohne MenuetOS deswegen abwerten zu wollen!). Die Programmierer haben ihren Spass daran und laden andere ein, ihn zu teilen.
Da du nun offensichtlich nicht zur Zielgruppe gehörst: Warum musst Du nun ein egoistisches "Aber was nützt es (mir)?" einwerfen? Am Kiosk gibt es auch 100e von Spezialzeitschriften, die (was mich persönlich betrifft) Papierverschwendung sind. Deswegen komme ich aber doch nicht auf die Idee, dem Kioskbesitzer zu sagen, er soll die mal alle schön wegtun. Oder einem Verleger vorzuwerfen, er solle gefälligst seine Redakteure an einem Konkurrenz-Magazin mitarbeiten lassen, weil das sowieso schon die höhere Auflagenzahl erreicht?
Ich hatte ja versucht, zu differenzieren zwischen Nutzen für alle und individuellem Nutzen für die Jungs, die die Software schreiben. Und ich hatte auch gehofft, dass Zweck durchaus auch Selbstzweck im Sinne von "Lerneffekte", "Programmierspass" etc. bestehen kann. Und -um das noch klarer zu stellen- vielleicht stellen wir uns mal gemeinsam vor, was wirklich zwecklos wäre: Programmieren, das keinen Spass macht an einem Projekt, das niemand haben will in einer Firma, die miserables Betriebsklima und besch* bis gar keine Bezahlung und keine Chance auf spätere Vermarktung bietet. Wenn du meinst, dass Zweckgerichtetheit nicht sinnvoll sein sollte, dann würde mich interessieren, was am o.g. Extrembeispiel sinnvoll sein soll. Ich hatte -glaube ich- durchaus betont, dass ich Hochachtung vor den Jungs und vor allem vor ihrer Einstellung habe (gut, das ist nicht so rüber gekommen).
Du hast ja Recht mit der Frage nach der egoistischen Haltung. Allerdings hatte ich beim Nutzen viel weniger an mich selbst, sondern eher an die Community als Ganzes gedacht, die ja bekanntermassen viel Arbeit hat, aber bei der viel weniger als möglich sich in konkrete Projekte einordnen und Jobs übernehmen. Und die Frage nach Tuxracer und Konsorten trifft -finde ich- den Nagel nicht auf den Kopf: Da handelt es sich um ein "Spaßprodukt", das seinen Sinn im Spass als solchem hat. Aber bei MenuetOS hätte ich eher den Eindruck, dass es um Anwendungen und Basistechnologien geht. Und: BeOS ist gescheitert und die Quellen sind verloren. Hier -hast du ja wieder Recht- machen die Menuet-Jungs ja nicht den Fehler, sondern stellen ihre Quellen gleich unter die GPL, so dass die Community mehr davon hat.
Aber ich frage mich eben, ob nicht z.B. das HURD-Projekt (der Mach-gestützte Micro-Kernel der GNU-Leute) viel Unterstützung nötig hätte, bei dem qualifizierte Assemblerprogrammierer wahrscheinlich auch willkommen sind und und und. Und ähnliche Projekte gibt es wohl zu Hauf...
also Assembler ist keinesfalls out. Anwendungen sind denkbar im embedded-Bereich (Echtzeitanwendungen, Regelsysteme, digitale Modulationsverfahren (auch wenn da meistens DSPs verwendet werden)).
Da hast du ein paar spannende Fragen gestellt. Allerdings denke ich nicht, daß die Entwickler ein PLATZPROBLEM lösen wollen und man kann sagen was man will: MIR SIND PC's IMMER NOCH ZU LANGSAM ( ...und Computer auch :-)....) !! Es besteht nach meiner Meinung immer Bedarf die Performance eines Systems zu Optimieren.Klein ist zwar nicht immer schnell sondern simpel ist schnell aber ich denke dieses Projekt wird noch sehr spannend. Die Antworten auf Deine Fragen würden mich aber auch brennend interessieren.
Der Nutzen dürfte aktuell ein Proof of Concept sein. Wenn man in der Lage ist mit so wenig Resourcen ein GUI inkl. Webserver zu entwickeln gibt es sicherlich auch Anwendungszwecke dafür. Vielleicht benutzt man das ja mal als Visualisierungs GUI in einem Bereich wo Aufgrund äusserer Witterungsverhältnisse keine modernen Prozessoren zum Einsatz kommen können wie z.B. in der Raumfahrt.
Das muß ich mir später mal ziehen und schauen obs hier läuft. Die grafische Oberfläche gefällt mir schon mal von den Screenshots her aber genaueres kann man wohl erst nach dem Selbsttest sagen *g*
Auf jeden Fall muß es ein gewaltiges Stück Arbeit gewesen sein das alles in Assembler zu schreiben!
Das ist was für mich :-). Ich mag alles was schnell ist, und trotzdem viel zu bieten hat. Naja es wird bestimmt noch nichts drauf laufen und kaum was funktionieren. Ich kanns noch nicht testen, weil ich nur kaputte Disketten hier hab.
Mit CP funktioniert es nicht, du mußt dd verwenden, die Anleitung auf deren Seite ist dazu etwas verwirrend: Wer sich das Image-File direkt herlädt, muß es mit dd if=menuetos.img of=/dev/fd0 bs=1024 auf die Floppy schreiben. Für Linux-Benutzer ist das EXE-File wohl unnötig.
Höhö, das ist aber doof! Ich habe gar kein Floppylaufwerk mehr und auf einer 700MB CD-RW sieht das doch verlassen aus :)
Ansonsten: nettes Projekt, sicherlich ein guter Grundstock für ein embedded OS. Aber für den Desktop-User oder als Notfallsystem ist das sicherlich nicht gedacht. Zudem, mit zunehmender Komplexität bringt Assembler nicht wirklich viel. Ob eine Funktion vielleicht 2 Schritte schneller ausgeführt wird, ist auf heutigen Systemen die eh zum grössten Teil Idle sind nicht mehr relevant.
µnOS von miray ist auch einen download wert. Gibt's auf http://www.miray.de/de/home/index.html, wo auch noch verschiedene interessante Tools zu finden sind. Ist allerdings kein Open-Source Projekt.
Ist zwar nett, das es auf eine Diskette passt, aber es frißt doch im Maßstab recht viel Ram. Also mit ich klopp die Diskette mal in einen alten Rechner rein ist dann eher nichts.
Ich kann, erlich gesagt auch keinen Sinn in einen OS mit GUI auf einer Diskette finden. Ausserdem mit assembler geschrieben = Masohismus. Aber vielleicht hat das alles einen Sinn, optisch gelungen und funktional.
Denkste, 500Mhz, da laufen 80186 Prozessoren, in den Zügen der DB jedenfalls. warum? reichen erstens völlig aus und sind zweitens die so ziemlich einzigen (wenn nicht die einzigen) fehlerfreien Prozessoren überhaupt.
in der Regelungstechnik finden leicht 80386-Typen oder ähnliche Industriemodelle ihren Einsatz. In der SPS von Siemens z.B.
schon mal ausprobiert eine 4Mhz schnelle CPU mit Assembler platt zu machen? (vorausgesetzt man versteht was von Algorithmik und sinnvoller Speichernutzung) Viel Erfolg beim üben!
da mag schon sein. aber eine gute siemens- oder alstomanlage zur komplexen steuerung von antrieben nutzt heute etwas mehr rechenleistung. S/ und Logidyn nutzen diese prozessoren. die ganze welt nutzt diese beiden firmen. ausnahmen best. die regel....
Ich bin bei solchen Sachen immer wieder begeistert was alles auf eine Diskette passt! Es wird immer vom Tod der Diskette, bei dem heutigen Datenaufkommen, gesprochen. Solche Beispiele zeigen aber, daß man schon noch einiges auf eine Diskette bekommt, wenn man nur gut genug mit seinem vorhanden Speicher umgeht!
hattest du das todo gesehen? Dort steht, dass der fd/hd support noch verbessert werden muss usw.
To do:
* improved fd/hd support
* boost for gui (amd write-combine mtrr)
* .. and other things you see missing
* to-do -list
Mit nur ca. 12 Leuten haben die schon 'ne Menge bewegt (besser garnicht mal 'ne Menge, eher ganz wenig, ca 1.44 MB)
Dass da noch einiges an Arbeit lauert, ist wohl klar.
HAND, Reiner
Da fällt mir ein, was ist eigentlich aus Atheos geworden? Gibts es das OS noch?
Es wird jetzt aber in einem anderen Projekt names Syllable weiterentwickelt:
http://syllable.sourceforge.net/
mfg
MrF
Ein anderes Projekt läst sich in den Nachrichten schon lange nicht mehr blieken. Ebenfalls ein ASM OS
http://v2os.v2.nl/
Hoffentlich lohnen sich diese Projekte.
Es wäre viel sinnvoller, eine Distribution mit einem aktuellen Linux-System zu machen, die in 8 MB läuft. Vor Jahren war es möglich, Linux mit Kernel 1.2 und TinyX in 2-4 MB laufen zu lassen, aber es gibt nichts Aktuelles mehr. (Oder doch? Irgenwo habe ich was gelesen von einem System, das jetzt auf dietlibc beruht.) Rechner, die mit 8 MB RAM ausgestattet sind und nicht weiter aufgerüstet werden können, gibt es bestimmt noch etliche. Daher wäre ein solches Projekt, vielleicht auf Basis von Gentoo oder einem ähnlichen, genial.
ob du es glaubst oder nicht, so etwas gibt es:
Small Linux: http://www.superant.com/smalllinux/
Und sogar Slackware 8.1 lässt sich auf einem 386er mit 4MB RAM installieren:
http://hetteh.iq.pl/bl/slack81.html
Viele Grüsse, Jascha
auf busybox-basis laesst sich ein linux-system (2.2.x) mit einer 1.4mb diskette auf einem 386er mit 2mb ram betreiben.. (inklsuive ftp-/telnet-server)...
gruss,
andre
das hatte ich schon vermutet, daß es mit Slackware geht. Aber meine Idee ging mehr dahin, eine auf Speicherbedarf optimierte Disti zu machen. Und X11 müßte auch mit dabei sein. Zumindest mit fvwm oder icewm als Window-Manager. OK, Applikationen wie OpenOffice oder Mozilla wird man nicht hinbekommen, daß sie in 8 MB laufen, da müßte man Alternativen suchen (Abiword und Netscape 3 oder so...)
Gruß,
hjb
m@u
-------
eat, drink, drum
Nach meiner Erfahrung passiert das nicht. Es sind eher die "Unarten" eines Compilers, die ihn letztlich als Zweiten durchs Ziel kommen lassen. Etwa, wenn er Parameter bei Calls unbedingt über den Stack übergeben will. Das kostet manchmal "Unmengen" von Code. Da habe ich vor Projektstart des öfteren einige Zeit investiert, um ihm sowas abzugewöhnen.
Auf der anderen Seite hat ein Compiler den Vorteil, dass er Zufälle ausnutzen kann. Hat er einen Offset eines Wertes in einer Datenstruktur in einem Register und braucht eine Konstante für eine Parameterübergabe, die zufällig den selben Wert hat, so kann er einfach den Registerinhalt weiterverwenden. Bei Inline Funktionen macht er das ganz gern mal. Mit Macros in Assembler bin ich da aufgeschmissen. Überhaupt kann er Inline Code auch mal anders übersetzen, wenn er meint, irgendeinen Registerinhalt kann er noch brauchen. Ein Compiler schreibt das Programm bei jedem Übersetzungslauf neu. Bei Assembler geht das nicht.
Insgesamt habe ich festgestellt, dass ein Gemisch aus Assembler und Compilerprogrammen praktisch die gleiche Programmgröße ergibt, wie reiner Assembler.
Grüße
Wolle
mfg
Erwischt ;)
Das Assemblerzeugs muss genauso strukturiert und übersichtlich sein. Da es von der Menge meist größer ist, habe ich meist eine Strukturebene mehr. Wenn's irgendwie unübersichtlich wird, find ich nix mehr. Das ist dann der Tod jedes Zeitplans.
> Außerdem hat das den Vorteil der Portierbarkeit!
Das war der Punkt, an dem ich beim Lesen des Artikels zuckte.Mein Hang zu Assembler rächt sich immer bitterlich beim Wechsel der CPU.
Gruß, Wolle
Aber damit hat es sich leider schon. Wenn die Jungs das machen, um Assembler zu lernen und um etwas tolles zu zeigen: Sehr schön. Haben wir vor 16 Jahren auch auf dem C64 gemacht, Demos programmiert, jedes Bit umgedreht, den SID und GEOS beackert. Alles gut und schön. Und -damit man mich nicht falsch versteht- ich habe echt Achtung vor ihren Fähigkeiten und der programmiererischen Leistung.
Aber: Wenn die Jungs glauben, dass wir so etwas tatsächlich brauchen, muss ich hier mal deutlich Fehlanzeige diagnostizieren...
- Die Binsenweisheit, dass Assembler die schnellste Programmiersprache ist, ist ja rund 20 Jahre alt oder älter.
- Dass C-Compiler einen gewissen Overhead produzieren, haben vielleicht Ken Thompson und Dennis Ritchie auch schon bemerkt.
Ich frage mich, ob wir in der Zwischenzeit nicht ein paar Neuerungen an der Hardware-Front hatten:
- Die Zip-Disk ist mit 100 MB schon fast wieder out, da es USB-Sticks mit 128 MB gibt.
- CF-Medien werden immer Voluminöser, IBMs 1GB-CF-II-Card ist auch nicht wirklich klein.
@ASM
> Hoffentlich lohnen sich diese Projekte.
Die Projekte lohnen sich eben nicht, weil sie "niemand" mehr braucht. Wir leben in der "Basar-Gesellschaft", in der ein derartiges Tempo herrscht, dass alte Ware sofort verworfen wird. Der Basar ist tatsächlich das ideale Bild für den Markt, an dem alle Produkte, Software, sonstige Projekte miteinander zu konkurrieren haben und da sind die Jungs aus ihrer Assembler-Kathedrale eben fehl am Platz.
Ich betone es noch mal:
- Nix gegen Assembler
- Nix gegen fähige Assembler-Programmierer
- Nix gegen Lernprojekte, an denen man seine Fähigkeiten testet.
Aber Software, die die Welt nicht braucht, ist eben mehr als flüssig.
Vielleicht kann man mich ja überzeugen, indem man konkrete Nutzbeispiele für ein derartiges MenuettOS anführt:
- Webserver?
- Embedded-Bereich?
- Hardware? Steuerung, Regelung?
- Echtzeitfähigkeit?
- Wie implementiert?
- Wie funktioniert der Scheduler?
- Können andere Kernelprogrammierer etwas daraus lernen?
- Sind die verwendeten Mechanismen abstrahierbar und damit für andere Projekte nutzbar?
Vielleicht klingt das alles zu hart, stimmt mich um mit guten Gegenargumenten...
MfG, KH
tja... das projekt ist echt KRASS... hut ab vor diesen programmieren !
nun zu deinen aufuehrungen... du hast im 'prinzip' recht... der effektive nutzen ist zz fuer einen user nicht wirklich gegeben. aber auch linux und mircosoft haben mal klein begonnen. wenn die entwickler nochmal solange daran arbeiten wiesiehs jetzt schon getan haben wird man dieses os sicherlich schon fuer einige einsatzgebiete sinnvoll nutzen koennen.
klar, wirklich noetig ist das in zeiten von 100gb-platten und mehr sicherlich nicht mehr. aber gerade so ein projekt zeigt den irrsinn der derzeitigen software/hardware-entwicklung. immer leistungsfaehigere betriebssteme, die wiederum die gesamt leistungsfaehichkeit der hardware verbrauchen. und alles nur weil die leute in java/visualbasic usw programmieren. unter linux ist die entwicklung der glibc und des gcc's aus meiner sicht auchnicht wirklich optimal. ein einfaches statisch kompiliertes 'hello world' belegt umdie 400kb... da waerdie diskette gleichschon zu nem drittel gefuellt - egal wir haben ja noch 2 drittel (und ne menge neue disktetten im schrank) :-)
da sind neue projekte wie dieses hier sicherlich ein guter ansatz....
gruss,
andre
Jedoch auf PCs nicht mehr sinnvoll.
Es gibt jedoch Chipkarten, wo immernoch in ASM Programmiert wird, aus guten Grund.
Dort wird auf jedes Byte und Register geachtet.
Ich selber habe sowas mal Programmiert. Da bekommt man nicht viel zur verfügung gestellt, wo das Program laufen kann.
Bei PCs ASM zu verwenden hat bereits den grossen Nachtel, dass man damit nur an ein CPU Optimieren wird, oder vieleicht noch ein zweiten.
Ab da wird der Aufwand zu gross. Damit ist das OS später für neuere CPUs nicht mehr preformant und ein 'dummes' C-Programm mit Overhead ist dann schneller.
Esseiden, die Jungs haben modular genug programmiert und können sowas anpassen, was wiederrum das Code verlangsamt.
Naja sie werden schon wissen, warum sie sowas Programmieren. Vieleicht auch nur um gute Arbeitstellen zu bekommen
> Aber Software, die die Welt nicht braucht, ist eben mehr als flüssig.
Mich verblüfft diese reine Zweckgerichtetheit immer wieder. Die Leute hinter diesem Projekt haben Spass an der Sache - braucht es auch nur einen einzigen Grund mehr? Ausserdem sind sie auch noch freundlich und geben den Sourcecode für alle zum Basteln, Spielen, Erweitern, Lernen und Einsetzen frei.
Fragst Du auch bei nethack, Tuxracer (OpenRacer), PySol, FrozenBubble usw. immer sofort nach einem Sinn bei der Sache? Keiner - ausser das es Spass macht. Einerseits den Entwicklern und andererseits den Usern/Spielern. Und so kannst Du MenuetOS auch betrachten (ohne MenuetOS deswegen abwerten zu wollen!). Die Programmierer haben ihren Spass daran und laden andere ein, ihn zu teilen.
Da du nun offensichtlich nicht zur Zielgruppe gehörst: Warum musst Du nun ein egoistisches "Aber was nützt es (mir)?" einwerfen? Am Kiosk gibt es auch 100e von Spezialzeitschriften, die (was mich persönlich betrifft) Papierverschwendung sind. Deswegen komme ich aber doch nicht auf die Idee, dem Kioskbesitzer zu sagen, er soll die mal alle schön wegtun. Oder einem Verleger vorzuwerfen, er solle gefälligst seine Redakteure an einem Konkurrenz-Magazin mitarbeiten lassen, weil das sowieso schon die höhere Auflagenzahl erreicht?
Kopfschüttelnd,
Jochen
Ausserdem wurde hier niemandem etwas vorgeschrieben.
Jochen
Ich hatte ja versucht, zu differenzieren zwischen Nutzen für alle und individuellem Nutzen für die Jungs, die die Software schreiben. Und ich hatte auch gehofft, dass Zweck durchaus auch Selbstzweck im Sinne von "Lerneffekte", "Programmierspass" etc. bestehen kann.
Und -um das noch klarer zu stellen- vielleicht stellen wir uns mal gemeinsam vor, was wirklich zwecklos wäre:
Programmieren, das keinen Spass macht an einem Projekt, das niemand haben will in einer Firma, die miserables Betriebsklima und besch* bis gar keine Bezahlung und keine Chance auf spätere Vermarktung bietet.
Wenn du meinst, dass Zweckgerichtetheit nicht sinnvoll sein sollte, dann würde mich interessieren, was am o.g. Extrembeispiel sinnvoll sein soll. Ich hatte -glaube ich- durchaus betont, dass ich Hochachtung vor den Jungs und vor allem vor ihrer Einstellung habe (gut, das ist nicht so rüber gekommen).
Du hast ja Recht mit der Frage nach der egoistischen Haltung. Allerdings hatte ich beim Nutzen viel weniger an mich selbst, sondern eher an die Community als Ganzes gedacht, die ja bekanntermassen viel Arbeit hat, aber bei der viel weniger als möglich sich in konkrete Projekte einordnen und Jobs übernehmen.
Und die Frage nach Tuxracer und Konsorten trifft -finde ich- den Nagel nicht auf den Kopf: Da handelt es sich um ein "Spaßprodukt", das seinen Sinn im Spass als solchem hat. Aber bei MenuetOS hätte ich eher den Eindruck, dass es um Anwendungen und Basistechnologien geht.
Und: BeOS ist gescheitert und die Quellen sind verloren. Hier -hast du ja wieder Recht- machen die Menuet-Jungs ja nicht den Fehler, sondern stellen ihre Quellen gleich unter die GPL, so dass die Community mehr davon hat.
Aber ich frage mich eben, ob nicht z.B. das HURD-Projekt (der Mach-gestützte Micro-Kernel der GNU-Leute) viel Unterstützung nötig hätte, bei dem qualifizierte Assemblerprogrammierer wahrscheinlich auch willkommen sind und und und.
Und ähnliche Projekte gibt es wohl zu Hauf...
Oder? MfG, KH
also Assembler ist keinesfalls out.
Anwendungen sind denkbar im embedded-Bereich (Echtzeitanwendungen, Regelsysteme, digitale Modulationsverfahren (auch wenn da meistens DSPs verwendet werden)).
Gruss =TB=
Reicht das nicht schon als praktische Anwendung ?
Noch eine Linux-Emulationsschicht (oder gleich BSD) & einen X-Server portieren und ab in den Wettbewerb!
Linux hat auch mal so ähnlich angefangen.
pippi
Auf jeden Fall muß es ein gewaltiges Stück Arbeit gewesen sein das alles in Assembler zu schreiben!
Grüße
Sturmkind
Ich mag alles was schnell ist, und trotzdem viel zu bieten hat.
Naja es wird bestimmt noch nichts drauf laufen und kaum was funktionieren.
Ich kanns noch nicht testen, weil ich nur kaputte Disketten hier hab.
ich bekomme immer nur ein connection refused, wenn ich auf http://www.menuetos.org/ will
kann mir jemand das floppy-image mailen oder irgendwo hochladen, oder soll ich mich gedulden, bis der server wieder geht?
1440+0 Records ein
1440+0 Records aus
Oder das Disketten-Image auf eine Diskette ziehen (nicht den Dos-Installer
Unix-users: dd if=MSETUP.EXE of=mfloppy.img bs=1024 skip=20
$ cp menuetos.img /media/floppy/
$ cp: writing `/media/floppy/menuetos.img': No space left on device
dd if=menuetos.img of=/dev/fd0 bs=1024
auf die Floppy schreiben. Für Linux-Benutzer ist das EXE-File wohl unnötig.
Ansonsten: nettes Projekt, sicherlich ein guter Grundstock für ein embedded OS. Aber für den Desktop-User oder als Notfallsystem ist das sicherlich nicht gedacht. Zudem, mit zunehmender Komplexität bringt Assembler nicht wirklich viel. Ob eine Funktion vielleicht 2 Schritte schneller ausgeführt wird, ist auf heutigen Systemen die eh zum grössten Teil Idle sind nicht mehr relevant.
mfg
ansonsten ist in einer zeit, in der ein normales telefon mehr speicher hat sinnlos.
ich sage euch, dass wird in max. 2 jahren tot sein....
die schnelligkeit??? ich bitte euch. eine steuerungssystem, für antriebe nutzt heute schon einen 500 MHz- Rechner....
Ausserdem mit assembler geschrieben = Masohismus.
Aber vielleicht hat das alles einen Sinn, optisch gelungen und funktional.
500Mhz,
da laufen 80186 Prozessoren,
in den Zügen der DB jedenfalls.
warum? reichen erstens völlig aus und sind zweitens die so ziemlich einzigen (wenn nicht die einzigen) fehlerfreien Prozessoren überhaupt.
in der Regelungstechnik finden leicht 80386-Typen oder ähnliche Industriemodelle ihren Einsatz. In der SPS von Siemens z.B.
schon mal ausprobiert eine 4Mhz schnelle CPU mit Assembler platt zu machen? (vorausgesetzt man versteht was von Algorithmik und sinnvoller Speichernutzung) Viel Erfolg beim üben!
quak