KolibriOS, komplettes OS inkl Gui auf einer Diskette

Peter Pander schrieb:
> Hat jemand Erfahrungen mit KolibriOS?

Was genau möchtest Du den wissen? Jetzt schreib bitte nicht: Alles. 
Schließlich gibt's genug Infos im Web, die man nicht alle noch mal 
wiederholen muß.

> Das ist ein komplettes Betriebsystem mit GUI etc auf einer Diskette,
> lauffähig ab 386er

Ja, eben. Und genau deshalb läßt sich das in ein paar Minuten in einer 
VM installieren und selbst ausprobieren.

> Es gibt wohl nach wie vor regelmäßige Nighty builds, obwohl die
> eigentlich Version bei 2009 steht

Das glaube ich erst, wenn dazu ein passendes Changelog sehe.

MfG

Peter Pander schrieb:
> Hat jemand Erfahrungen mit KolibriOS?

Ich kenne es lediglich und habe es mal in einer VM ausprobiert.
Es ist ein Fork von MenuetOS, letzteres gibt's auch in 64 Bit und ist 
AFAIK nur noch proprietär.


> Das ist ein komplettes Betriebsystem mit GUI etc auf einer Diskette,
> lauffähig ab 386er

Ein Pentium Prozessor ist das Minimum.
http://wiki.kolibrios.org/wiki/SystemRequirements

Und damit geht leider schon der größte Vorteil flöten.
Für 386er und 486er hätte es ein interessantes OS als Ersatz zu DOS sein 
können, das gleichzeitig TCP/IP fähig ist, standardmäßig eine GUI bietet 
und präemptive Multitasking kann. Aber für Pentium Prozessoren kann man 
dann auch gleich Windows NT/2k/XP, Linux oder irgendein BSD 
Betriebssystem nehmen und dadurch gleichzeitig von der größeren 
Programmauswahl, POSIX Kompatibilität und von von Compilern optimiertem 
Code und in Hochsprachen geschriebenen Programmen profitieren.

Grundsätzlich können Hochsprachen den Programmierer beim Coden 
unterstützen, so dass sich weniger Fehler einschleichen und die Wartung 
des Codes einfacher wird. Außerdem ist solcher Code portabel und kann 
auch schneller neue CPU Features nutzen (z.b. AVX2), diese muss 
schließlich ja nur der Compiler unterstützen und dann genügt ein 
Neukompilieren mit den entsprechenden Parametern und schon macht das 
Programm von den neuen Features Gebrauch.
Bei Assemblercode fallen diese Vorteile weg, außerdem verliert man auch 
den Vorteil der Optimierungsmöglichkeit durch den Compiler, der meist 
deutlich besser optimieren kann, als durchschnittliche 
Assemblerprogrammierer.

Vorteile hat es allenfalls noch, wenn man selber Assembler programmieren 
lernen möchte, aber das geht auch ohne dieses OS und ist somit nicht 
zwingend. Aber eventuell ist die Motivation dann höher und der Einstieg 
in diese einfacher.

Würde es auf 386er und 486er mit nur 4 MB RAM laufen, dann wäre das 
super, weil man dann ein OS mit präemtivem Multitasking und einem TCP/IP 
Stack für den einfachen Datenaustausch über das LAN haben könnte, aber 
das kann Kolibri oder MenuetOS halt leider nicht.
Ab dem Pentium gibt es bewährtere Betriebssysteme mit einer größeren 
Verbreitung.

Die Bootzeit ist heutzutage mit SSDs und Bootabläufen, die auf eine 
kurze Bootzeit optimiert sind, bei den großen Betriebssystemen kein 
ernsthaftes Thema mehr.
Und Pentium Rechner haben alle PCI Slots und lassen sich mit USB fähigen 
PCI Karten nachrüsten, wenn das Mainboard noch keine USB Slots haben 
sollte. Damit kann man bei denen auch von USB Medien Booten, die 
Diskette ist also auch kein Vorteil mehr.

Mehrbenutzerfähig ist es leider nicht.
Zugriffsrechte kennt es auch nicht.
Daher ist es leider auch aus sicherheitstechnischen Gründen nicht 
besonders attraktiv.

Insofern, es ist ein Nischenbetriebssystem ohne große Relevanz.
Die geringe Anzahl an verschiedenster Software für verschiedenste Zwecke 
ist dabei noch ein Punkt, den ich hier nicht weiter vertiefen möchte.
Ein nacktes OS ohne Programme nützt einem Endwender nicht viel, da 
müsste man dann schon bereit sein alles selber zu programmieren.

Mein Tipp, schau dir abseits vom Mainstream lieber Haiku oder ReactOS 
an, die sind vielversprechender.
https://www.haiku-os.org/
https://reactos.org/

Und für 386 und 486er fährt man mit FreeDOS und einem entsprechenden 
TCP/IP fähigem DOS Programm zwecks Datenaustausch besser.

Nano schrieb:
> Ich kenne es lediglich und habe es mal in einer VM ausprobiert.

Nachtrag
Das "kennen" könnte man auf verschiedenste Weise interpretieren, daher 
möchte ich das noch einmal präzisieren.
Kennen heißt hier, dass ich weiß, dass es das gibt und das ich es mal 
ausprobiert habe. Ich habe es aber weder viele Jahre benutzt noch ist es 
irgendwo auf meinen Rechnern als OS dauerhaft im Einsatz.

> Mein Tipp, schau dir abseits vom Mainstream lieber Haiku oder ReactOS
> an, die sind vielversprechender.
> https://www.haiku-os.org/
> https://reactos.org/

Eines habe ich noch vergessen:
Redox OS.
https://en.wikipedia.org/wiki/Redox_(operating_system)
https://www.redox-os.org/

so, ich hatte es gestern mal von einer Diskette gebootet.
Der hammer , bootzeit unter eine Minute, VON EINER DISKETTE!! und der 
Desktop ist dann sofort ohne weitere Verzögerungen da auch alles andere 
ist blitzschnell.
Norton Commander clon diverse Spieler, Rechner etc pp..ist bereits alles 
vorinstalliert..alles auf 1,44MB!!

Ich behaupte ja nicht, das jedes System in Assembler programmiert werden 
muss, aber man sieht an solchen System wo wier stehen könnten wenn die 
Systeme nicht so aufgeblasen wären wie Xp, Win7 etc.
Dann braucht die Entwicklng halt länger, aber ich will auch nicht alle 5 
jahre einen komplett neuen "verbesserten" Desktop

Nano schrieb:
> Ein Pentium Prozessor ist das Minimum.
> http://wiki.kolibrios.org/wiki/SystemRequirements
>
> Und damit geht leider schon der größte Vorteil flöten.

Das wird aber nicht das eigentliche Problem sein. Ich habe gerade mal in 
deren Forum geschaut. Das strotzt nur so von Postings in russisch. Damit 
zeigen die ja schon, dass sie kein großes Interesse haben es für ALLE 
lesbar zu halten. Da bin ich mit meinen Sprachkenntnissen außen vor.

Für MenuetOS hat man zumindest noch
https://board.flatassembler.net/forum.php?f=12

Vergleichen könnte man noch mit: 
http://asm.sourceforge.net/asmutils/a-linux-0.17.tar.gz
Also a-Linux, das hat aber eher Proof of Concept - Charakter.
Tatsächlich arbeiten müsste man dann außerhalb.

Das besondere daran ist aber, dass das "Linux" auf Diskette geht. Andere 
Linuxe bräuchten mehrere Disketten. (so 5 - 20)
Aber Disketten..da ist heute die Kunst, noch welche zu finden, die 
fehlerfrei sind, oder sich fehlerfrei formatieren lassen.
Das Problem gibt es bei DVDs oder CDs seit einiger Zeit auch öfter.
Die Zips ( https://de.wikipedia.org/wiki/Iomega_Zip ) hatten sich als 
Diskettenersatz bewährt, sind aber leider untergegangen.
Die 120 MB-Diskettenlaufwerke sind reihenweise kaputtgegangen.
SD-Karten sind auch nicht so schlecht, aber viele fallen schon 
auseinander, wenn man sie nur anhustet.

Flip B. schrieb:
> Ich fände so einen schmalen ansatz super-interessant für das smartphone.
> Mit momentaner Hardware könnte man sicher wieder wochen an akkulaufzeit
> hinbekommen.  Das bisschen text und bildverarbeitung was handys
> tatsächlich machen ist nun einfach zu aufgeblasen.

Ein großteil wird wohl das Display verbrauchen. Das solltest du dann 
abschalten um eine lange Laufzeit zu erreichen ;-)

Kotzt mich einfach an wie bei MS "Programmen" Abhaengigkeiten existieren 
wie silberlicht und andere. D.h. die Programme sind nicht stand alone 
lauffähig.

windows ist für mich so etwas wie der Turmbau zu Babel. Das ging auch 
nicht gut.

Nano schrieb:
> Ein Pentium Prozessor ist das Minimum.

Zumindest vor ein paar Jahren lief Menuet32 noch auf 486. Da sich an dem 
OS ja nix mehr geändert hat, sollte das immer noch so sein.

S,es,es und es schrieb:
> Kotzt mich einfach an wie bei MS "Programmen" Abhaengigkeiten existieren
> wie silberlicht und andere. D.h. die Programme sind nicht stand alone
> lauffähig.

Gemeinsam genutzte Komponenten sparen Platz. Ist schon sinnvoll so.

Nano schrieb:
> Und für 386 und 486er fährt man mit FreeDOS und einem entsprechenden
> TCP/IP fähigem DOS Programm zwecks Datenaustausch besser.

Und als GUI mit C64 Feeling dazu noch GEOS, das würde dann sogar noch 
auf einem XT laufen.
https://github.com/bluewaysw/pcgeos

"Gemeinsam genutzte Komponenten sparen Platz. Ist schon sinnvoll so."
LOL, genau, darauf legen MS und Linux einen riesen Wert drauf..*hust*#

ICh glaube umgekehrt würde ein Schuh draus. Mittlereile würden die 
Vorteile eigenständiger Software erheblich überwiegen als auf die paar 
letzten 100Mb zu achten.
Natürlich macht es vereinzelt Sinn, wenn wirklich große umfangreiche 
Pakete genutz werden.
Was dabei auffält..#
Viele PRogramme von Pascal/Delphi programmierern haben keinerlei oder 
nur wenige Abhängigkeiten, die in C++ geschriebenen Programme haben 
Abhängigkeiten ohne Ende.

Offenbar ist es auch eine Philosophie Frage der Programmierer, denn mit 
C++ ginge es ja auch nur das nutzt diese Möglichkeit keiner oder will 
sie nicht nutzen.
Da unter linux irre viel in PAscal geschrieben wird, sieht man es hier 
sehr gut, aber auch unter Win, wie den Totalcommander oder damals skype, 
bis es auf cüü umgeschrieben wurde:-(

sogar ntfs etc. läuft unter Kolibrios out of the Box:-)

rbx schrieb:
> Das Problem gibt es bei DVDs oder CDs seit einiger Zeit auch öfter.

Das liegt aber eher an den neueren optischen Laufwerken, für 25 € kann 
man da nichts erwarten.
Oder wenn man cdrkit nutzt, da geht dann auch ziemlich viel unnötig 
kaputt.

Das beste ist wohl ein Diskettenemulator an dem man vorne einen USB 
Stick reinschieben kann.
Keine Ahnung ob es so etwas für den PC gibt, aber es sollte einer sein, 
der sich als 3,5" Laufwerk für den Floppycontroller ausgibt, damit man 
davon booten kann.
Für den Amiga gibt es ja so etwas, dan werden dann Floppy Images vom USB 
Stick oder der SD Karte geladen.

M.M.M schrieb:
> Nano schrieb:
>> Ein Pentium Prozessor ist das Minimum.
>
> Zumindest vor ein paar Jahren lief Menuet32 noch auf 486. Da sich an dem
> OS ja nix mehr geändert hat, sollte das immer noch so sein.

Nun, du könntest es mit QEMU und dem Parameter -cpu 486 testen.

Im schlimmsten Fall haben die Entwickler Befehle verwendet, die es erst 
ab dem Pentium gibt:
https://en.wikipedia.org/wiki/X86_instruction_listings#Added_with_Pentium

Guckt man sich die dazu gekommenen Befehle und deren Nutzen an, dann 
stehen die Chancen zwar gut, dass es noch auf dem 486er läuft, aber das 
widerspricht dann der Aussage in der Wiki, in der explizit erwähnt wird, 
dass es auf dem 386er und 486er nicht laufen wird. Es wird schon seinen 
Grund haben, warum es diese Explizite Erwähnung gibt.
Ich schätze mal, dass man zumindest den CPUID und RSM Befehl eingebaut 
hat, mit etwas Glück besitzt man aber einen der älteren 486er, bei dem 
diese Befehle nachgerüstet wurden, womit es ein "kann laufen, muss aber 
nicht" wäre.

Peter Pander schrieb:
> "Gemeinsam genutzte Komponenten sparen Platz. Ist schon sinnvoll so."
> LOL, genau, darauf legen MS und Linux einen riesen Wert drauf..*hust*#
>
> ICh glaube umgekehrt würde ein Schuh draus. Mittlereile würden die
> Vorteile eigenständiger Software erheblich überwiegen als auf die paar
> letzten 100Mb zu achten.

Das denke ich nicht.
Bibliotheksfunktionen sind nämlich über die Jahre gereift und bezüglich 
ihrer Performance auch noch optimiert.
Es macht keinen Sinn, einen etwas komplexeren Algorithmus selber zu 
implementieren, wenn es dafür Bibliotheken gibt, in denen der gleiche 
Algorithmus hoch optimiert wurde.


> Offenbar ist es auch eine Philosophie Frage der Programmierer, denn mit
> C++ ginge es ja auch nur das nutzt diese Möglichkeit keiner oder will
> sie nicht nutzen.

Es macht keinen Sinn.
Siehe oben.
Außerdem ist es schlechter Stil, wenn man das Rad jedesmal neu 
implementiert.
Bestehende Funktionen in Form von guten Bibliotheken wiederzuverwenden 
spart zu dem Entwicklungsaufwand und ist weniger fehleranfällig, was zu 
stabileren Programmen führt.

Nano schrieb:

> Bibliotheksfunktionen sind nämlich über die Jahre gereift

Das würde ich ganz sicher nicht für jede Funktion und für jede 
Bibliothek unterschreiben wollen.

Das ist nur das schöne Ideal, was aber in der Praxis IMMER mehr oder 
weniger weit verfehlt wird.

> Es macht keinen Sinn, einen etwas komplexeren Algorithmus selber zu
> implementieren, wenn es dafür Bibliotheken gibt, in denen der gleiche
> Algorithmus hoch optimiert wurde.

Doch , da macht spätestens dann Sinn, wenn er fehlerhaft implementiert 
wurde. Dazu muß mann allerdings zumindest die Kompetenz haben, das 
überhaupt erkennen zu können.

Und genau daran hapert's gewöhnlich bei diesen reinen 
C&P-"Programmierern"...

> Außerdem ist es schlechter Stil, wenn man das Rad jedesmal neu
> implementiert.

Und an diesem Spruch erkennt man sie...

Peter Pander schrieb:
> Hat jemand Erfahrungen mit KolibriOS?
> Das ist ein komplettes Betriebsystem mit GUI etc auf einer Diskette,
> lauffähig ab 386er
> https://kolibrios.org/de/screen
>
> Es gibt wohl nach wie vor regelmäßige Nighty builds, obwohl die
> eigentlich Version bei 2009 steht

Wie bekommt man das auf eine Diskette? Ich musste einen DVD nehmen;)

c-hater schrieb:
> Nano schrieb:
>
>> Bibliotheksfunktionen sind nämlich über die Jahre gereift
>
> Das würde ich ganz sicher nicht für jede Funktion und für jede
> Bibliothek unterschreiben wollen.

Das habe ich nicht behauptet, aber bei den bekannten Bibliotheken wie 
bspw. die stdlib kannst du davon ausgehen.

>> Es macht keinen Sinn, einen etwas komplexeren Algorithmus selber zu
>> implementieren, wenn es dafür Bibliotheken gibt, in denen der gleiche
>> Algorithmus hoch optimiert wurde.
>
> Doch , da macht spätestens dann Sinn, wenn er fehlerhaft implementiert
> wurde.

Eine sehr dumme Argumentation. Denn natürlich nimmt man nichts kaputtes.
Genauso könntest du sagen, man soll auch nicht Autofahren, Spätestens 
dann nicht, wenn beim Auto die Bremsen kaputt sind.


> Und genau daran hapert's gewöhnlich bei diesen reinen
> C&P-"Programmierern"...

Bibliotheken richtig zu verwenden hat nichts mit Copy & Paste zu tun.
So viel sollte man eigentlich wissen.

>> Außerdem ist es schlechter Stil, wenn man das Rad jedesmal neu
>> implementiert.
>
> Und an diesem Spruch erkennt man sie...

Blödsinn. Selbst im Info Studium wird man dir sagen, dass du bestehende 
Funktionen verwenden sollst und nicht alles selbst implementieren 
sollst, vor allem auch, wenn du professionell arbeiten willst.
Das Rad neu erfinden will nämlich niemand bezahlen, also mach es 
gefälligst richtig.

Es fördert auch die Wartungsfähigkeit des Codes, aber wahrscheinlich 
gehörst du zu den Programmierern, die Code möglichst kompliziert 
aussehen lassen wollen, weil sie sich etwas darauf einbilden und meinen 
nur so ihre Stelle behalten zu können.

Jens schrieb:
> S,es,es und es schrieb:
>> Kotzt mich einfach an wie bei MS "Programmen" Abhaengigkeiten existieren
>> wie silberlicht und andere. D.h. die Programme sind nicht stand alone
>> lauffähig.
>
> Gemeinsam genutzte Komponenten sparen Platz. Ist schon sinnvoll so.
Um den Platz gehts doch gar nicht. In der Praxis braucht naemlich jedes 
Programm seine eigene Version der Bibliothek. Und wenns auch nur eine 
Funktion ist, die daraus aufgerufen wird, muss die gesamte Bibliothek 
vorhanden sein. Beim statischen Linken wuerde nur der tatsaechlich 
benoetigte Code eingebunden werden. Die DLLerei hat eher 
lizenzrechtliche, d.h. kommerzielle Gruende.

Maxe schrieb:
> Jens schrieb:
>> S,es,es und es schrieb:
>>> Kotzt mich einfach an wie bei MS "Programmen" Abhaengigkeiten existieren
>>> wie silberlicht und andere. D.h. die Programme sind nicht stand alone
>>> lauffähig.
>>
>> Gemeinsam genutzte Komponenten sparen Platz. Ist schon sinnvoll so.
> Um den Platz gehts doch gar nicht. In der Praxis braucht naemlich jedes
> Programm seine eigene Version der Bibliothek. Und wenns auch nur eine
> Funktion ist, die daraus aufgerufen wird, muss die gesamte Bibliothek
> vorhanden sein. Beim statischen Linken wuerde nur der tatsaechlich
> benoetigte Code eingebunden werden. Die DLLerei hat eher
> lizenzrechtliche, d.h. kommerzielle Gruende.

System DLLs, in der Regel die im Windows Ordner, müssen nur einmal im 
RAM  vorhanden sein und werden unter Windows tatsächlich geteilt.
Das was du schreibst gilt nur für die DLLs in den Programmordnern, da 
Windows diese beim Laden priorisiert.
Würde man diese in den entsprechenden Windows Ordner verschieben und bei 
allen Programmen, die diese benötigen, die entsprechende Datei im 
Programmordner löschen, dann würde die auch nur einmal geladen werden.
Der Grund warum man das nicht macht, ist die typische DLL-Hell, weil es 
hin und wieder vorkommen kann, dass die Programme für verschiedene DLL 
Versionen programmiert wurden, sich die einzelnen DLL Versionen dann 
aber doch stärker geändert haben und dann nicht mehr richtig mit dem 
entsprechenden Programm funktionieren.


Bei einer Linux Distribution werden dagegen in der Regel alle Programme, 
die eine bestimmte Bibliothek verwenden, gegen die gleiche shared 
Library gelinkt und diese wird systemweit installiert, also in der Regel 
nach /usr/lib/ und wenn Programme diese benötigen, wird sie nur einmal 
ins RAM geladen.
Das gilt natürlich nicht mehr für Fatclients, die ihre Bibliotheken 
selber mitgeben.

Grundsätzlich sind geteilte dynamische Bibliotheken auf beiden Systemen 
möglich.

Le X. schrieb:

> Der Lösung wird wohl, wie so oft, der goldene aber langweilige Mittelweg
> sein.

Genau so ist es.

Nano schrieb:

> Das beste ist wohl ein Diskettenemulator an dem man vorne einen USB
> Stick reinschieben kann.
> Keine Ahnung ob es so etwas für den PC gibt, aber es sollte einer sein,
> der sich als 3,5" Laufwerk für den Floppycontroller ausgibt, damit man
> davon booten kann.

Gibt es: http://www.gotekemulator.com/

In der Liste sind vorwiegend CNCs, Näh- und Stickmaschinen sowie 
Musikinstrumente aufgeführt, aber die "generische" 1.44 MB-Variante 
läuft auch in jedem gängigen PC.

c-hater schrieb:
> Le X. schrieb:
>
>> Der Lösung wird wohl, wie so oft, der goldene aber langweilige Mittelweg
>> sein.
>
> Genau so ist es.

Das hast du aber nicht gesagt.
Du willst alles selber implementieren.

Soul E. schrieb:
> Nano schrieb:
>
>> Das beste ist wohl ein Diskettenemulator an dem man vorne einen USB
>> Stick reinschieben kann.
>> Keine Ahnung ob es so etwas für den PC gibt, aber es sollte einer sein,
>> der sich als 3,5" Laufwerk für den Floppycontroller ausgibt, damit man
>> davon booten kann.
>
> Gibt es: http://www.gotekemulator.com/
>
> In der Liste sind vorwiegend CNCs, Näh- und Stickmaschinen sowie
> Musikinstrumente aufgeführt, aber die "generische" 1.44 MB-Variante
> läuft auch in jedem gängigen PC.

Danke für den Hinweis. Die Dinger sind erstaunlicherweise gar nicht so 
teuer wie ich dachte.

Nano schrieb:

> Das hast du aber nicht gesagt.

Naja, nicht explizit. Aber jeder, der was von der Sache versteht, 
erkennt die Intention.

> Du willst alles selber implementieren.

Das habe ich wo genau geschrieben?

Wenn du solche abstrusen Behauptungen aufstellst, dann solltest du sie 
auch beweisen können. Ansonsten bist du entweder ein notorischer Lügner 
oder ein Vollidiot. Such's dir aus...


Ich hatte vor allem darauf abgestellt, dass der Lib-Nutzer in der Lage 
sein sollte, die Qualität der Lib einschätzen zu können. Ja, das 
erfordert halt genau die Kompetenz, die nötig wäre, um die Lib auch 
selber schreiben zu können. Es ist trotzdem noch ein erheblicher 
Vorteil, eine gute Lib zu nutzen, auch wenn es Zeit kostet, sie erstmal 
zu bewerten.

c-hater schrieb:
> Nano schrieb:
>
>> Das hast du aber nicht gesagt.
>
> Naja, nicht explizit. Aber jeder, der was von der Sache versteht,
> erkennt die Intention.
>
>> Du willst alles selber implementieren.
>
> Das habe ich wo genau geschrieben?

Du hast doch an meinem Beitrag rumgenörgelt, in dem es heißt:

"Selbst im Info Studium wird man dir sagen, dass du bestehende
Funktionen verwenden sollst und nicht alles selbst implementieren
sollst, vor allem auch, wenn du professionell arbeiten willst."

Man beachte das "nicht alles".


> Wenn du solche abstrusen Behauptungen aufstellst, dann solltest du sie
> auch beweisen können. Ansonsten bist du entweder ein notorischer Lügner
> oder ein Vollidiot. Such's dir aus...

Das muss ich nicht. Ich habe dir bereits vor > 12 Monaten verboten mich 
zu beleidigen. Erinnere dich daran!


> Ich hatte vor allem darauf abgestellt, dass der Lib-Nutzer in der Lage
> sein sollte, die Qualität der Lib einschätzen zu können.

So hast du es aber nicht geschrieben.
Du hast Pauschal unterstellt, das Libs meist kaputt sind und Leute, die 
Libs nutzen, schlechte C&P Programmierer seien.

> Ja, das
> erfordert halt genau die Kompetenz, die nötig wäre, um die Lib auch
> selber schreiben zu können.

Es ging nie um die Frage, ob man eine Lib selber schreiben kann!!!
Dieses Können setze ich voraus, trotzdem nutzt man dann besser eine 
bestehende Lib.

Nano schrieb:

> Du hast Pauschal unterstellt, das Libs meist kaputt sind

Die tatsächliche Formulierung war (erwidernd auf die pauschale und 
völlig verlogene Aussage, alle Libs seien perfekt optimiert und 
obendrein umfassend getestet):

> Das ist nur das schöne Ideal, was aber in der Praxis IMMER mehr oder
> weniger weit verfehlt wird.

Das liest sich doch nun wirklich ganz anders als die mir von dir 
unterstellte Aussage. Du bist eindeutig ein notorischer Lügner.