Thema: L4-ähnlicher Kernel

[bluecode]

In der Zeit die man dafür länger benötigt als der Hochsprachen-Programmierer haben sich die Computer bereits so sehr weiterentwickelt das der theoretische Vorsprung des handoptimierten Assembler-Codes obsolete ist!

Bis dahin ist auch die Prozessorgeneration für die die Optimierung gedacht war längst obsolet.

[FlashBurn]

Wo hab ich das getan? Beweise!

Um mal alles auf die Goldwaage zu legen, indem du schon forderst das ein Hochsprachen-Programmierer gut sein muss und der Compiler aktuell sein muss, stellst du doch schon Nebenbedingungen. Genauso wie ich

Das einzigste was ich fordere ist das Dein Vergleich fair sein soll, also wenn Du auf die eine Seite einen guten menschlichen Assembler-Programmierer stellst dann muss auf der anderen Seite auch ein guter Compiler (zusammen mit einen fähigen Hochsprachen-Programmierer) stehen. Mehr nicht!

Naja, also spielt die Zeit die jemand in Assembler dazu brauchen würde keine Rolle. Das Problem des Hochsprachen-Programmierers ist halt das er auch an die Fähigkeiten des Compilers gebunden ist (ansonsten ist der Vergleich wieder hinfällig, weil wenn er den Compiler verbessert, ist es ja wieder das selbe als wenn er gleich Assemblercode geschrieben hätte), sprich er wüsste zwar wie man den Code noch schneller machen kann, aber die Sprache lässt es nicht zu.

Das ist eine sehr praxistaugliche Annahme.

D.h. du kannst also sagen das ein Auto welches mit Strom fährt grundsätzlich weniger Energie verbraucht als ein Auto was mit Benzin/Diesel fährt? Da es dir egal ist wo der Strom herkommt, kann das ja auch ein absolut altes schlechtes (vom Wirkungsgrad her) Kraftwerk sein.
Am besten finde ich diese Aussage immer wenn es um neue Kraftwerke geht, der Strom soll billig sein und niemand will ein Kraftwerk in seiner Nähe haben (gilt so auch für Windräder). Wie soll dann der Strom aus der Steckdose kommen? Von den anderen Ländern, die dann wieder die bösen bösen Atomkraftwerke dafür nutzen?

In der Zeit die man dafür länger benötigt als der Hochsprachen-Programmierer haben sich die Computer bereits so sehr weiterentwickelt das der theoretische Vorsprung des handoptimierten Assembler-Codes obsolete ist!

Das kann durchaus sein, aber für den "alten" Computer wird es dann wohl noch richtig sein

Zumal jeder Praxistauglich anders definiert. Ich meine der eine möchte in 2 Jahren ein bestimmtes Ergebnis sehen und der andere will einfach nur Spaß haben und was dabei lernen. Praxistauglich kann auch heißen das es einfach nur möglich ist.

Für ein hinreichend großes N schaffst du es nie eine N-Bit Verschlüsslung zu brute-forcen. Und um das zu sagen brauch dich nicht mal zu kennen.

Aber würdest du nicht schon ewig brauchen um es dann zu verschlüsseln? Irgendwann wird es bestimmt mal möglich sein (selbst wenn das in unendlich vielen Jahren der Fall sein sollte ).

[MNemo]

Wo hab ich das getan? Beweise!

Um mal alles auf die Goldwaage zu legen, indem du schon forderst das ein Hochsprachen-Programmierer gut sein muss und der Compiler aktuell sein muss, stellst du doch schon Nebenbedingungen. Genauso wie ich

Das sind lediglich Bedingungen für einen fairen Vergleich, und hat mit Realität zurecht biegen nichts zu tun.

Das einzigste was ich fordere ist das Dein Vergleich fair sein soll, also wenn Du auf die eine Seite einen guten menschlichen Assembler-Programmierer stellst dann muss auf der anderen Seite auch ein guter Compiler (zusammen mit einen fähigen Hochsprachen-Programmierer) stehen. Mehr nicht!

Naja, also spielt die Zeit die jemand in Assembler dazu brauchen würde keine Rolle. Das Problem des Hochsprachen-Programmierers ist halt das er auch an die Fähigkeiten des Compilers gebunden ist (ansonsten ist der Vergleich wieder hinfällig, weil wenn er den Compiler verbessert, ist es ja wieder das selbe als wenn er gleich Assemblercode geschrieben hätte), sprich er wüsste zwar wie man den Code noch schneller machen kann, aber die Sprache lässt es nicht zu.

Der Punkt ist, dass der Compiler von zisch Experten Entwickelt wird, die sich mit nichts anderem Beschäftigen. Und das du vor Intel/AMD weißt wie man ihre Prozessoren Optimal ausnutzt ist ja wohl absurd.

Zumal jeder Praxistauglich anders definiert. Ich meine der eine möchte in 2 Jahren ein bestimmtes Ergebnis sehen und der andere will einfach nur Spaß haben und was dabei lernen. Praxistauglich kann auch heißen das es einfach nur möglich ist.

Wer Spaß haben will und nicht an Resultaten interessiert ist, führt nicht Optimierung als Argument an.

Für ein hinreichend großes N schaffst du es nie eine N-Bit Verschlüsslung zu brute-forcen. Und um das zu sagen brauch dich nicht mal zu kennen.

Aber würdest du nicht schon ewig brauchen um es dann zu verschlüsseln? Irgendwann wird es bestimmt mal möglich sein (selbst wenn das in unendlich vielen Jahren der Fall sein sollte ).

Nein mein Aufwand ist Konstant N, deiner 2^N. Und ja, theoretisch ist es möglich das in endlicher Zeit zu lösen, nur -- und da sind wir wieder beim Punkt -- du hast nicht genug Zeit.

[bluecode]

Nein mein Aufwand ist Konstant N, deiner 2^N. Und ja, theoretisch ist es möglich das in endlicher Zeit zu lösen, nur -- und da sind wir wieder beim Punkt -- du hast nicht genug Zeit.

Um mal noch mehr Offtopic zu werden: Beweise mir, dass sein Aufwand 2^N ist!

[Svenska]

Boah seid ihr alle toll. Da bin ich mal nicht da und schon werden meine Worte durch den Fleischwolf gedreht.

Wie ich an anderen Stellen schon mehrfach erwähnt habe, kann ein C-Compiler wesentlich besser optimieren als du es je könntest.
Außerdem kennen gute C-Compiler deine CPU besser als du es je könntest.

Diese Aussagen enthalten implizit Randbedingungen, die hier oft genug erwähnt wurden:
(a) Unser aller Lebenszeit ist begrenzt. Ich glaube, daran zweifelt keiner. Das heißt, dass theoretisch konvergierende Beweise für Zeiten von, sagen wir mal, irgendwas größer 80 Jahren praktisch nicht als konvergent angenehmen werden dürfen.
Ja, es ist theoretisch möglich. Dauert es theoretisch länger als ~80 Jahre, kann es mir egal sein, weil dann bin ich tot.

(b.1) Ich gehe stillschweigend davon aus, dass Leute, die Compiler entwickeln, die Architektur des Pentium IV besser kennen als tev. Das gilt damit auch für den Compiler.
(b.2) Ich gehe ferner stillschweigend davon aus, dass tev nicht die Zeit investieren wird, um die Architektur annähernd genausogut zu kennenzulernen.
Daraus folgt:
(b) Der Compiler kennt die Architektur besser als tev es je könnte.

Sicherlich kann er die Zeit investieren. Sicherlich kann er sich die Arbeit machen. Ich bin davon überzeugt, er wird es nicht tun.
Und der Name spielt in den Aussagen überhaupt keine Rolle. Es gibt nur ganz, ganz, ganz wenige Leute, denen ich so eine Arbeit zutrauen würde. Und das sind sicherlich nicht die Leute, die Fragen, ob Assembler sinnvoll ist...

(c) Wenn ich mir Projekte wie SymbOS anschaue, dann staune ich immer wieder über die Ergebnisse, die man mit Assembler so produzieren kann. Gebe ich zu.
Aber: Warum gab es sowas nicht, als die Systeme neu waren? Weil die Programmiertechniken noch nicht existierten.

@FlashBurn: Das heißt umgekehrt, dass du heutige Compiler gegen heutige Assemblerprogrammierer antreten lassen musst und alte Compiler gegen Assemblerprogrammierer aus der damaligen Zeit.

(d) Ist ein Pentium IV ungleich komplexer als ein ganzes, auf dem Z80 basierendes System.

(e) Ist Wissen nicht dasselbe wie Intelligenz. Und wie auch schon gezeigt wurde, ist ein Gehirn auch nur ein Computer. Streng genommen ist er sogar deterministisch. Und wenn man sich neuronale Netze und ähnliche selbstlernende Algorithmen anschaut, stellt sich die Frage, ob Computer nun prinzipiell nicht lernen könnten oder sie es einfach mit heutigen Programmiertechniken nicht tun.
Definiere 'Intelligenz' und 'Lernen'. Vergleiche dies bitte mit dem Aufbau des menschlichen Gehirns.

*seufz*

[tev]

Da ist man ein Tag nicht zu Hause, schon muss man wieder ein haufen Zeug lesen

Aber zur Zeit, die aufgewendet werden muss,um zu optimieren, es müssen nur einige Codestellen (die halt im laufenden Betrieb des Kernels sehr oft genutzt werden) gut optimiert werden. Wenn ich irgendwelche Debugmeldungen(die einmal ausgeführt werden)ausgegeben werden und die schlechter optimiert sind als es ein Compiler macht, dann ist mir das egal.

Und der wichtigere Grund für mich warum ich meinen Kernel in Assembler schreib ist, dass ich lieber in Assembler programmiere als in C.
Wenn ich in C Code schreibe, dann ist mein Code bestimmt weniger effektiv als wenn taljeth oder sonst jemand ihn schreibt, weil es eben viele Sachen gibt mit denen ich mich nicht anfreunden kann, wie beispielsweise die schon beschriebenen Castings, die ich recht nervig finde. So etwas entfällt in Assembler vollkommen und da fühle ich mich wohl  .



Und noch einmal zum Kernel selber. Im Endeffekt reicht es wenn der Kernel nach außen hin Funktionen für das IPC (natürlich gut implementiert , wobei das wahrscheinlich bei mir nicht beim ersten Anlauf so sein wird) bereit stellt, weil der Rest kann im Userspace erledigt werden und wenn weniger der Kernel aufgerufen wird, dann gibt es weniger, Performance kostende Ringwechsel.

gruß tev

[MNemo]

wenn weniger der Kernel aufgerufen wird, dann gibt es weniger, Performance kostende Ringwechsel.

1. Syscall/sysenter reduzieren die kosten in dem Punkt sehr stark.
2. Ich kenne den L4 jetzt nicht, aber ein Klassischer Mikro-Kernel hat den Nachteil von noch viel teureren Kontext wechseln, wegen der vielen Server.

Um mal noch mehr Offtopic zu werden: Beweise mir, dass sein Aufwand 2^N ist!

Ne, also da hättest du in der Schule besser aufpassen sollen. xD

[tev]

MNemo ich verwende ja Sysenter, aber daran hab ich gar nicht gedacht als ich meinen letzten Post geschrieben habe. Und zu 2. L4 versucht so wenig Kontextwechsel wie möglich zu erreichen und das bei möglichst wenig Kontext.

[FlashBurn]

Nur noch eine Sache, dann lassen wir die Sache hier ruhen

und alte Compiler gegen Assemblerprogrammierer aus der damaligen Zeit.

Ganz ehrlich, das würde ich als einen eher unfairen Vergleich für die Compiler sehen. Ich denke mal damals waren die Assemblerprogrammierer fähiger (ich will niemandem etwas unterstellen) und vorallem zahlreicher und die Compiler waren bei weitem noch nicht so gut wie heute.

back2topic

Gerade der L4 hängt stark von der IPC Performance ab, da er eigentlich sogar verdammt viele Kontextwechsel haben müsste. Da wird sogar um eine Page zu mappen IPC genutzt.

[erik.vikinger]

Hallo,

Das ist eine sehr praxistaugliche Annahme.

D.h. du kannst also sagen das ein Auto welches mit Strom fährt grundsätzlich weniger Energie verbraucht als ein Auto was mit Benzin/Diesel fährt? Da es dir egal ist wo der Strom herkommt, kann das ja auch ein absolut altes schlechtes (vom Wirkungsgrad her) Kraftwerk sein.
Am besten finde ich diese Aussage immer wenn es um neue Kraftwerke geht, der Strom soll billig sein und niemand will ein Kraftwerk in seiner Nähe haben (gilt so auch für Windräder). Wie soll dann der Strom aus der Steckdose kommen? Von den anderen Ländern, die dann wieder die bösen bösen Atomkraftwerke dafür nutzen?

Hey was soll das, Du legst mir da Worte/Aussagen in den Mund die niemals von mir kommen würden. Das ist absolut unterstes Niveau! Ich bin hier wohl der einzigste der tatsächlich Verantwortung für die nächste Generation trägt und da brauche ich mir von niemanden erklären zu lassen wie wir unseren Planeten behandeln sollten. Über die Art wie der Strom, der bei mir ganz einfach aus der Steckdose kommt, erzeugt werden soll habe ich gut nachgedacht als ich mein Kreuzchen auf dem Wahlzettel positioniert habe. Viel mehr kann ich kaum machen oder soll ich jetzt zum Demonstrationstourismusbüro gehen und mir eine Teilname bei der nächsten Castor-Demo buchen und mich dort an die Gleise ketten (und mein Kleiner kann sich dann seine Erziehung im Knast abholen)?
Ich bin ziemlich enttäuscht, FlashBurn.

Praxistauglich kann auch heißen das es einfach nur möglich ist.

Nein, praxistauglich ist nur das was auch in der realen Praxis tatsächlich funktioniert. Wenn ich für die Lösung einer Aufgabe >100 Jahre benötige dann ist das einfach nicht praxistauglich egal ob ich prinzipiell fähig bin oder nicht.

.... lassen wir die Sache hier ruhen

Das wäre sehr zu Deinem Vorteil!

Da ist man ein Tag nicht zu Hause, schon muss man wieder ein haufen Zeug lesen

So ist das eben wenn man einen lustigen Flame-War (unbeabsichtigt) lostritt.

So etwas entfällt in Assembler vollkommen und da fühle ich mich wohl  .

So habe ich auch mal gedacht als ich noch jung war, bis ich dann die Vorzüge strenger Typisierung (und da ist C noch ziemlich relaxt, da gibt es ganz andere Programmiersprachen die das deutlich korrekter nehmen) und gut lesbarer + ausdrucksstarker Syntax kennen gelernt habe. Heute nehme ich Assembler nur noch wenn ich muss oder wenn ich mir einfach mal den Spaß meiner Jugend noch mal gönnen möchte.

Und noch einmal zum Kernel selber. Im Endeffekt reicht es wenn der Kernel nach außen hin Funktionen für das IPC (natürlich gut implementiert , wobei das wahrscheinlich bei mir nicht beim ersten Anlauf so sein wird) bereit stellt, weil der Rest kann im Userspace erledigt werden und wenn weniger der Kernel aufgerufen wird, dann gibt es weniger, Performance kostende Ringwechsel.

Desto weniger Funktionalität im Kernel selber ist desto mehr benötigen die User-Mode-Prozesse das IPC und entsprechend häufiger kommen dann die Kontext-Wechsel. Das ist ja der Grund warum nahezu alle erfolgreichen Microkernel-OSe schon längst keine echten Microkernel mehr sind (Mac OS X und Windows sind da nur die prominentesten Vertreter) und das nur weil sie es eben nicht geschafft haben den IPC-Overhead auf ein akzeptables Maß zu reduzieren. Überlege Dir lieber wie das IPC-Konzept möglichst effizient werden kann, also auf algorithmischer Ebene (hier ist nämlich die menschliche Kreativität tatsächlich erforderlich und hier lassen sich auch die viel größeren Performancesteigerungen erzielen), und überlasse das umsetzen in Maschinen-Code dem Compiler. Betrachte den Compiler als Teil Deines Teams, Du machst den algorithmischen/kreativen Part und der Compiler macht die Drecksarbeit, so kann tatsächlich ein wirklich gutes Ergebnis bei raus kommen. Und ganz wichtig, Performance ist nicht alles, auch die Absturzhäufigkeit ist ein wichtiges Kriterium für/gegen ein OS. Was nützt mir ein OS das zwar theoretisch o,5% schneller ist aber bereits abstürzt bevor ich mein Tageswerk erledigt habe. Assembler-Code nicht nur hochperformant sondern auch übersichtlich und wartbar zu gestalten ist schon eine ziemlich hohe Kunst (was nicht heißen soll dass das unmöglich ist) die umso schwieriger wird desto mehr Code Du hast.


Grüße
Erik

[FlashBurn]

Hey was soll das, Du legst mir da Worte/Aussagen in den Mund die niemals von mir kommen würden. Das ist absolut unterstes Niveau!

Ich habe nur aus deinem gesagten etwas anderes geschlossen! Wenn du sagst das es durchaus gängige Praxis ist, das man sich nicht darum kümmert wo der Strom herkommt, dann kann ich davon ausgehen, dass das auch deine Meinung ist! Wenn dem nicht so ist, musst du das schon sagen.

[rizor]

Hey was soll das, Du legst mir da Worte/Aussagen in den Mund die niemals von mir kommen würden. Das ist absolut unterstes Niveau!

Ich habe nur aus deinem gesagten etwas anderes geschlossen! Wenn du sagst das es durchaus gängige Praxis ist, das man sich nicht darum kümmert wo der Strom herkommt, dann kann ich davon ausgehen, dass das auch deine Meinung ist! Wenn dem nicht so ist, musst du das schon sagen.

Dein Schluss aus Eriks Meinung ist aber auch nicht korrekt .
Eriks These mag stimmen, das bedeutet aber nicht, dass er auch der Meinung ist. Du ziehst falsche Rückschlüsse, denn bloß weil man sich nicht von einer Aussage/Meinung distanziert, bedeutet das nicht, dass man sie unterstützt.

[tev]

Und noch einmal zum Kernel selber. Im Endeffekt reicht es wenn der Kernel nach außen hin Funktionen für das IPC (natürlich gut implementiert , wobei das wahrscheinlich bei mir nicht beim ersten Anlauf so sein wird) bereit stellt, weil der Rest kann im Userspace erledigt werden und wenn weniger der Kernel aufgerufen wird, dann gibt es weniger, Performance kostende Ringwechsel.

Desto weniger Funktionalität im Kernel selber ist desto mehr benötigen die User-Mode-Prozesse das IPC und entsprechend häufiger kommen dann die Kontext-Wechsel. Das ist ja der Grund warum nahezu alle erfolgreichen Microkernel-OSe schon längst keine echten Microkernel mehr sind (Mac OS X und Windows sind da nur die prominentesten Vertreter) und das nur weil sie es eben nicht geschafft haben den IPC-Overhead auf ein akzeptables Maß zu reduzieren. Überlege Dir lieber wie das IPC-Konzept möglichst effizient werden kann, also auf algorithmischer Ebene (hier ist nämlich die menschliche Kreativität tatsächlich erforderlich und hier lassen sich auch die viel größeren Performancesteigerungen erzielen), und überlasse das umsetzen in Maschinen-Code dem Compiler. Betrachte den Compiler als Teil Deines Teams, Du machst den algorithmischen/kreativen Part und der Compiler macht die Drecksarbeit, so kann tatsächlich ein wirklich gutes Ergebnis bei raus kommen. Und ganz wichtig, Performance ist nicht alles, auch die Absturzhäufigkeit ist ein wichtiges Kriterium für/gegen ein OS. Was nützt mir ein OS das zwar theoretisch o,5% schneller ist aber bereits abstürzt bevor ich mein Tageswerk erledigt habe. Assembler-Code nicht nur hochperformant sondern auch übersichtlich und wartbar zu gestalten ist schon eine ziemlich hohe Kunst (was nicht heißen soll dass das unmöglich ist) die umso schwieriger wird desto mehr Code Du hast.

Genau bei der Geschwindigkeit setzt L4 ja an, deswegen kann man L4 auch als Mikrokernel der 2. Generation bezeichnen.Aber bevor ich hier einen endlosen Text schreib gibt es hier ein genaueres Konzept findet man hier http://www.lowlevel.eu/w/images/2/29/Die_L4-Mikrokernel-Familie.pdf.
Und zur Sprachenwahl; Das steht für mich außer Diskussion, das ist mein Entschluss mit dem ich leben muss . Das heißt aber nicht, dass es objektiv die beste Wahl ist; Lediglich subjektiv.

[erik.vikinger]

Hallo,

Wenn du sagst das es durchaus gängige Praxis ist, das man sich nicht darum kümmert wo der Strom herkommt

Also:

Das ist die typische Aussage "der Strom kommt ja aus der Steckdose".

Das ist eine sehr praxistaugliche Annahme.

Mit "sehr praxistaugliche Annahme" habe ich den Inhalt Deiner These nicht bewertet, ich habe nur zum Ausdruck bringen wollen das es in der Praxis (also jedes mal wenn man ein elektrisches Gerät einschaltet) sehr tauglich ist wenn man den Strom aus der Steckdose so akzeptiert wie er ist. Es bringt absolut nichts jedes mal darüber zu philosophieren wo den nun der Strom am besten her kommen sollte, da käme man (hier im technisierten Mitteleuropa) ja nicht mehr zum eigentlichen Leben. Ich hoffe das jeder hier die Möglichkeiten die sich real bieten auf unseren Strom Einfluss zu nehmen auch nutzt, also bei Wahlen und auch mal bei friedlichen (wohnortnahen) Demonstrationen. Aber wenn ich einen Stecker in den Steckdose stecken muss weil ich den Staubsauger benutzen will dann bringt es eben absolut nichts sich über den Strom überhaupt Gedanken zu machen. Genau das meine ich mit "praxistauglich". Damit will ich keinesfalls zum Ausdruck bringen das man sich gar nicht darum kümmern sollte wo der Strom her kommt.

dann kann ich davon ausgehen, dass das auch deine Meinung ist! Wenn dem nicht so ist, musst du das schon sagen.

Ich habe mir Deine These nirgends zu eigen gemacht noch habe ich diese inhaltlich bewertet, also kannst Du absolut gar nichts über meine persönliche Meinung spekulieren. Natürlich möchte ich das der Strom möglichst sauber erzeugt wird und ich dafür möglichst wenig Geld bezahlen muss aber diese Gedanken mache ich mir wenn es sich auch wirklich lohnt und das ist in der täglichen Lebens-Praxis (leider) nur sehr selten der Fall. Genau daraus ergibt sich die Schlussfolgerung das es recht praxistauglich ist den Strom aus der Steckdose einfach so zu akzeptieren wie er ist, nicht mehr und  nicht weniger.

Genau bei der Geschwindigkeit setzt L4 ja an, deswegen kann man L4 auch als Mikrokernel der 2. Generation bezeichnen.

Aber gerade die Mechanismen die vom L4 eingesetzt werden halte ich persönlich nur für bedingt geeignet dieses Ziel zu erreichen. Der L4 ist ganz sicher ein sehr guter Schritt in die richtige Richtung aber ein "gelungenes Endergebnis" stellt er in meinen Augen noch nicht dar. Nebst dessen das der extreme Minimalismus des L4 eben auch wieder einen sehr hohen IPC-Trafic erzeugt (viel Kleinvieh macht auch viel Mist).

Und zur Sprachenwahl; Das steht für mich außer Diskussion, das ist mein Entschluss mit dem ich leben muss . Das heißt aber nicht, dass es objektiv die beste Wahl ist; Lediglich subjektiv.

Gut, damit kann ich sehr gut leben. Das ist Deine freie Entscheidung und ich hoffe das Du damit so viel Spaß wie möglich hast und natürlich auch Erfolg.


Grüße
Erik

[FlashBurn]

Auch wenn es jetzt eigentlich nicht hierher gehört, aber ich bin eigentlich schon davon ausgegangen das wenn man sich von einer Meinung nicht distanziert, das man dann der Meinung ist. Bzw. in diesem Fall klang es für mich als wenn erik der Meinung zustimmt.

@tev

Lass dich von Assembler nicht abbringen. Man kann viel dabei lernen. Zumal ein L4 Kernel ja eigentlich nicht so groß werden dürfte, der macht ja kaum was

[tev]

Lass dich von Assembler nicht abbringen. Man kann viel dabei lernen. Zumal ein L4 Kernel ja eigentlich nicht so groß werden dürfte, der macht ja kaum was

Denk ich mir doch
Später will ich wahrscheinlich noch eine libc und so portieren, damit auch andere ihren Spaße haben können

[erik.vikinger]

Hallo,

aber ich bin eigentlich schon davon ausgegangen das wenn man sich von einer Meinung nicht distanziert, das man dann der Meinung ist.

Daran werde ich Dich bei Gelegenheit erinnern. Okay?

Bzw. in diesem Fall klang es für mich als wenn erik der Meinung zustimmt.

Wirklich? Ich habe doch erklärt warum ich Deine These für eine praxistaugliche Annahme halte, aber ohne diese zu bewerten (erst recht nicht positiv). Und auch danach hab ich ziemlich auf dem Wort "praxistauglich" rumgeritten. Ich bin davon ausgegangen das jeder versteht das es mir um die Praxistauglichkeit als solches geht und es zusätzlich (fälschlicherweise) implizit als logisch vorausgesetzt das es eben nicht praxistauglich ist sich ständig Gedanken über die Herkunft der elektrischen Energie zu machen die man aus der Steckdose konsumiert. Schließlich hat sich doch fast der ganze Thread um die Praxistauglichkeit von Thesen gedreht.

Ich würde es im übrigen auch als sehr praxistauglich erachten wenn wir uns alle in Zukunft nicht mehr ganz so arg (oder wenigsten mit etwas mehr praktiziertem Respekt) über Kleinigkeiten auslassen könnten.


praktische Grüße
Erik