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
Angehängte Dateien:
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
Diskette? Was ist das? Kann man sich das umhängen?
>:-)=) SCNR
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.
Beitrag #6243025 wurde von einem Moderator gelöscht.
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.
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.
c-hater schrieb: > Das würde ich ganz sicher nicht für jede Funktion und für jede > Bibliothek unterschreiben wollen. Der Lösung wird wohl, wie so oft, der goldene aber langweilige Mittelweg sein. Weder ist es sinnvoll wenn jeder alles immer händisch von der Pike auf selbst programmiert, genauso wenig sollte man sein Programm mit zuvielen unnützen Abhängigkeiten überfrachten. Pauschal gegen alle Bibliotheken und Frameworks zu schimpfen ist doof, jedes aktuelle fancy Framework in sein Projekt zu integrieren noch doofer. Für das konkrete Problem ist es Aufgabe des Entwicklers, die passende Lösung zu finden. Das gelingt manchmal gut, manchmal eben weniger.
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.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.