Inplementierung in den kommenden Kernel
Inplementierung in den kommenden Kernel
Hallo Leute,
mir ist eben ein recht mackabrer Gedanke in den Kopf gekommen, der sich jedoch vielleicht als geschwindigkeitsfördernd erweisen könnte.
Vorab möchte ich sagen, dass ich kein Superprogrammierer bin und nicht den totalen Durchblick habe, was die Struktur des Kernels angeht.
Direkte Kernelinplementationen bringen auf gewissen Ebenen durchaus spürbare Geschindigkeitserhöhungen. Beispielsweise ist die Graphikbeschleunigung in den Darwin-Kern von MacOSX integriert. Das bring zusätzlich noch Performance.
Modulare Inplementation wäre bei einigen Anwendungsbereichen durchaus denkbar.
Die ganzen GUI-Libs (QT,GTK, WxWidgets ..) könnte man in den Kernel integrieren ODER als Daemon/Module vielleicht in eine Art "Read-Only-Ram-Area" packen, wo die Applikationen drauf zugreifen können, um die Lib-Daten auszulesen. Es ist ja so, dass jeder Speicherbereich geschützt ist und die Applikationen auf diesen nicht zugreifen können - es sei denn, man ist so doof und verwendet <Windows Me. Da sich diese Daten des RORA immer im Speicher befinden würden, also nicht in SWAP geschrieben werden würden, würde das sehr wohl einen Geschwindigkeitsvorteil mit sich bringen. Ob es mit QT so leicht machbar wäre, ist allerdings fraglich. Ich denke nicht, dass man die Libs einfach so mit reinkompilieren könnte. Man müsste sich schon was ausdenken.
Die andere interessante Sache wäre die Optimierung der Applikationen: Das Benutzen von externen Libs (egal ob mit GUI oder ohne) ist Realität. Es gibt jedoch immernoch Programmierer, die div. Libs in ihre Programme mitreinkompilieren - was recht schwachsinnig ist. Aber naja. Jedenfalls um modifizierte Libs auch zuzulassen, könnte man die Read-Only-Memory-Area dynamisch gestalten, d.h. die Größe wäre skalierbar.
Klar ist das Lesen von auch grösseren Datenmengen für moderene Festplatten kein Problem. Aber wenn ein Teil der Daten bereits im RAM liegt und nur das wesentliche von der Festplatte geladen wird, ergeben sich dadurch Vorteile, da zum einen die Festplatte nicht Libs und Programm laden muss, und da zum anderen der Weg zwischen Prozessor und RAM kürzer ist, als der von Festplatte zum Prozessor - was wiederum bedeuten würde, dass zwei verschiedene Komponenten den Prozessor mit Daten füttern würden und die bearbeitung schneller erfolgt, da die Festplatte nicht doppelt gebremmst wird. (Man vergleiche die Bootzeit oder Ladezeit von OpenOffice oder was auch immer für Ladezeiten bei einem Pentium D mit (2x) 3,06GHz 1024MB DDR Ram mit einer alten 1,8GB-Festplatte und demselben System einem Hardware-Raid10 aus modernen Sata2-Platten. => Effekt ist klar. Festplatte rattert, CPU idlelt.)
Heutzutage ist viel Ram ja erwerblich. Die - vielleicht - 128MB Ram, die die Libs an Platz wegnehmen würden, sind ein Witz. Man müsste sich dann also nicht mehr um neue Prozessoren kümmern oder neue Festplatten kaufen, die schneller sind, sondern müsste mehr Ram reinhauen, um die Applikationsinitialisierung zu beschleunigen.
Klar gibt es SWAP - aber würden die Bibliotheken sofort beim Kernelboot in Read-Only-Memory-Area (kurz RORA) geladen werden, so könnte ich mir durchaus vorstellen, dass es schon was bringen würde, denn eins ist KLAR:
Die Speicherbandbreite zwischen Prozessor und Ram ist wesentlich höher als zwischen Prozessor (Bus) und Festplatte!
Außerdem: Userbezogene Applikationen (also Apps mit GUI) sterben nicht so schnell aus!
Was meint Ihr dazu?
mir ist eben ein recht mackabrer Gedanke in den Kopf gekommen, der sich jedoch vielleicht als geschwindigkeitsfördernd erweisen könnte.
Vorab möchte ich sagen, dass ich kein Superprogrammierer bin und nicht den totalen Durchblick habe, was die Struktur des Kernels angeht.
Direkte Kernelinplementationen bringen auf gewissen Ebenen durchaus spürbare Geschindigkeitserhöhungen. Beispielsweise ist die Graphikbeschleunigung in den Darwin-Kern von MacOSX integriert. Das bring zusätzlich noch Performance.
Modulare Inplementation wäre bei einigen Anwendungsbereichen durchaus denkbar.
Die ganzen GUI-Libs (QT,GTK, WxWidgets ..) könnte man in den Kernel integrieren ODER als Daemon/Module vielleicht in eine Art "Read-Only-Ram-Area" packen, wo die Applikationen drauf zugreifen können, um die Lib-Daten auszulesen. Es ist ja so, dass jeder Speicherbereich geschützt ist und die Applikationen auf diesen nicht zugreifen können - es sei denn, man ist so doof und verwendet <Windows Me. Da sich diese Daten des RORA immer im Speicher befinden würden, also nicht in SWAP geschrieben werden würden, würde das sehr wohl einen Geschwindigkeitsvorteil mit sich bringen. Ob es mit QT so leicht machbar wäre, ist allerdings fraglich. Ich denke nicht, dass man die Libs einfach so mit reinkompilieren könnte. Man müsste sich schon was ausdenken.
Die andere interessante Sache wäre die Optimierung der Applikationen: Das Benutzen von externen Libs (egal ob mit GUI oder ohne) ist Realität. Es gibt jedoch immernoch Programmierer, die div. Libs in ihre Programme mitreinkompilieren - was recht schwachsinnig ist. Aber naja. Jedenfalls um modifizierte Libs auch zuzulassen, könnte man die Read-Only-Memory-Area dynamisch gestalten, d.h. die Größe wäre skalierbar.
Klar ist das Lesen von auch grösseren Datenmengen für moderene Festplatten kein Problem. Aber wenn ein Teil der Daten bereits im RAM liegt und nur das wesentliche von der Festplatte geladen wird, ergeben sich dadurch Vorteile, da zum einen die Festplatte nicht Libs und Programm laden muss, und da zum anderen der Weg zwischen Prozessor und RAM kürzer ist, als der von Festplatte zum Prozessor - was wiederum bedeuten würde, dass zwei verschiedene Komponenten den Prozessor mit Daten füttern würden und die bearbeitung schneller erfolgt, da die Festplatte nicht doppelt gebremmst wird. (Man vergleiche die Bootzeit oder Ladezeit von OpenOffice oder was auch immer für Ladezeiten bei einem Pentium D mit (2x) 3,06GHz 1024MB DDR Ram mit einer alten 1,8GB-Festplatte und demselben System einem Hardware-Raid10 aus modernen Sata2-Platten. => Effekt ist klar. Festplatte rattert, CPU idlelt.)
Heutzutage ist viel Ram ja erwerblich. Die - vielleicht - 128MB Ram, die die Libs an Platz wegnehmen würden, sind ein Witz. Man müsste sich dann also nicht mehr um neue Prozessoren kümmern oder neue Festplatten kaufen, die schneller sind, sondern müsste mehr Ram reinhauen, um die Applikationsinitialisierung zu beschleunigen.
Klar gibt es SWAP - aber würden die Bibliotheken sofort beim Kernelboot in Read-Only-Memory-Area (kurz RORA) geladen werden, so könnte ich mir durchaus vorstellen, dass es schon was bringen würde, denn eins ist KLAR:
Die Speicherbandbreite zwischen Prozessor und Ram ist wesentlich höher als zwischen Prozessor (Bus) und Festplatte!
Außerdem: Userbezogene Applikationen (also Apps mit GUI) sterben nicht so schnell aus!
Was meint Ihr dazu?
Viele Grüße
za0
Nieder mit der Pauschal-Abzocke der GEZ!
- king-crash
- Beiträge: 742
- Registriert: 08.08.2006 12:07:56
- Lizenz eigener Beiträge: MIT Lizenz
die "read only" Segmente einer Shared Library (.text sections) können (und werden auch) jetzt schon geshared. Ein Daemon wird dazu nicht benötigt.za0 hat geschrieben: Die ganzen GUI-Libs (QT,GTK, WxWidgets ..) könnte man in den Kernel integrieren ODER als Daemon/Module vielleicht in eine Art "Read-Only-Ram-Area" packen, wo die Applikationen drauf zugreifen können, um die Lib-Daten auszulesen.
bringt auf alle Fälle längere Bootzeiten und viel unnützen Müll in "deiner RORA"za0 hat geschrieben: aber würden die Bibliotheken sofort beim Kernelboot in Read-Only-Memory-Area (kurz RORA) geladen werden, so könnte ich mir durchaus vorstellen, dass es schon was bringen würde
Was es nicht alles so gibtza0 hat geschrieben: Es gibt jedoch immernoch Programmierer, die div. Libs in ihre Programme mitreinkompilieren - was recht schwachsinnig ist. Aber naja.
Es gibt auch immer noch Personen, die leichtfertig generalisierte Urteile fällen
Gruß
gms
- dopehouse
- Beiträge: 452
- Registriert: 01.09.2005 12:02:16
- Lizenz eigener Beiträge: GNU General Public License
- Wohnort: Hildesheim (Niedersachsen)
-
Kontaktdaten:
Also manchmal macht es auch sinn, wenn Programmierer die Libs statisch linken, da man dann nicht dafür sorgen muss, dass man die gleichen Libs in seiner Distro hat. Ist bei kommerziellen Spielen ganz angenehm.
Aber wenn ich dann bedenke, dass ich einen 200MB großen Kernel habe, und bei jedem Library Update den Kernel neu kompilieren muss, wird mir jetzt schon ganz schlecht. Und wenn ich dann noch mein kommerzielles Spiel nur mit einer hoffnungslos veralteten Kernelversion spielen kann, hört bei mir der Spaß auf.
Ich denke mal, dass das derzeitige Konzept mit Shared-Libraries doch ne sehr gute Idee war und sich auch noch einige Jahre so fortführen wird. Wenn ich den Rechner der Enterprise habe, können wir ja nochmal drüber reden.
Bis dahin lasse ich lieber meine ganzen Gnome-Anwendungen auf gynamisch gelinkte Bibliotheken zugreifen und wenns mal nötig ist, darf dann auch mal eine Anwendung ein paar QT und/oder KDE Bibliotheken laden.
Aber wenn ich dann bedenke, dass ich einen 200MB großen Kernel habe, und bei jedem Library Update den Kernel neu kompilieren muss, wird mir jetzt schon ganz schlecht. Und wenn ich dann noch mein kommerzielles Spiel nur mit einer hoffnungslos veralteten Kernelversion spielen kann, hört bei mir der Spaß auf.
Ich denke mal, dass das derzeitige Konzept mit Shared-Libraries doch ne sehr gute Idee war und sich auch noch einige Jahre so fortführen wird. Wenn ich den Rechner der Enterprise habe, können wir ja nochmal drüber reden.
Bis dahin lasse ich lieber meine ganzen Gnome-Anwendungen auf gynamisch gelinkte Bibliotheken zugreifen und wenns mal nötig ist, darf dann auch mal eine Anwendung ein paar QT und/oder KDE Bibliotheken laden.
Desktop: Lenny
Notebook: Lenny
Server: auch schon Lenny (mit Pinning von util-vserver auf die vorletzte Version)
Notebook: Lenny
Server: auch schon Lenny (mit Pinning von util-vserver auf die vorletzte Version)
Ok, dann lassen wir den Kernel als Grundstein außen vor.
Beziehen wir uns auf die Idee, dass im Kernel folgendes integriert wird:
RORA-Management := Kernel darf als einziges diesen Bereich beschreiben, das bedeutet aber nicht, dass man nach jedem Hinzufügen oder rausnehmen eines Lib-Packets den Rechner neubooten muss; + dynamische Größenregelung des RORA (beim booten kostet das Laden der Libs eben 3-5 Sekunden mehr, aber dafür wird jede Anwendung, die GTK, QT oder Ä. verwendet zwischen 1 und 2 Sekunden geladen - das ist doch ein Performance-Deal - oder nicht?).
Die Libs werden direkt in den Ram geladen - so ala Ramdisk. Vielleicht müsste man da auch nicht viel entwickeln. Man nehme FreiserFS, ramdisk machen, /lib verlinken mit /ramdsk/libs, die libs vielleicht packen und ein Bootscritp schreiben, dass die Dateien auf die Ramdisk entpackt.
Beziehen wir uns auf die Idee, dass im Kernel folgendes integriert wird:
RORA-Management := Kernel darf als einziges diesen Bereich beschreiben, das bedeutet aber nicht, dass man nach jedem Hinzufügen oder rausnehmen eines Lib-Packets den Rechner neubooten muss; + dynamische Größenregelung des RORA (beim booten kostet das Laden der Libs eben 3-5 Sekunden mehr, aber dafür wird jede Anwendung, die GTK, QT oder Ä. verwendet zwischen 1 und 2 Sekunden geladen - das ist doch ein Performance-Deal - oder nicht?).
Die Libs werden direkt in den Ram geladen - so ala Ramdisk. Vielleicht müsste man da auch nicht viel entwickeln. Man nehme FreiserFS, ramdisk machen, /lib verlinken mit /ramdsk/libs, die libs vielleicht packen und ein Bootscritp schreiben, dass die Dateien auf die Ramdisk entpackt.
Viele Grüße
za0
Nieder mit der Pauschal-Abzocke der GEZ!
-
- Beiträge: 3472
- Registriert: 30.11.2005 10:32:22
- Lizenz eigener Beiträge: MIT Lizenz
- Wohnort: Wald
Damn Small Linux kann sowas:
Quelle: http://www.pro-linux.de/news/2006/9261.html
Code: Alles auswählen
Auf Rechnern mit mindestens 128 MB kann Damn Small Linux vollständig im RAM laufen, ohne auf eine Festplatte zuzugreifen. Dies soll ein enorm schnelles Starten von Programmen ermöglichen.
ja, bringt aber nicht sonderlich viel speed, da die sachen nicht schon anfangs im speicher liegen! ausserdem soll der daemon dazu dienen, in rora schreiben zu können, falls spezielle libs geladen werden sollen.gms hat geschrieben: die "read only" Segmente einer Shared Library (.text sections) können (und werden auch) jetzt schon geshared. Ein Daemon wird dazu nicht benötigt.
Benutzt du windows oder linux? wie oft bootest du deinen rechner am tag? notfalls benutzt man standby - zieht kaum strom! "unnützen Müll"? - da sollen nur die Libs rein, mehr nicht. ich weiss nicht, was du dir da vorgestellt hast.gms hat geschrieben: bringt auf alle Fälle längere Bootzeiten und viel unnützen Müll in "deiner RORA"
Hehe. Ich merke wie gut gnome Programmiert ist - jedes Mal wenn ich meinen Laptop boote und sehe, wie langsam die einzelnen Teile der Taskleiste geladen werden - da bekomme ich das Kotzen!!! Aber jedes Mal!gms hat geschrieben: Was es nicht alles so gibt
Es gibt auch immer noch Personen, die leichtfertig generalisierte Urteile fällen
Gnome is cool - kein Zweifel, aber ich will nicht wissen, warum der Mist sooooo langsam ist. Ich habe mich bisher nicht getraut den Source der Libs anzusehen. Ich habe eine recht flotte Platte drin (durchs. 25mb/s, 1,6 GHz, 512MB Ram und der driss (sry, ich kann es nicht mehr anders sagen) macht einen auf Rudolf Scharping: LAAAAAAAAAAAAAAAAAANGSAAAAAAAAAAAAAM!
Wenn man eine Idee im Kopf hat und diese mal eben notieren will, und da stift und blatt fehlen, muss notebook hinhalten - ehe gedit gestartet ist, ist die idee weg
Ich habe das schonmal erlebt
ABER MOMENT: bevor man gedit überhaupt startet, sollte man doch lieber in den textmodus switschen und seine notizen im loginprompt niederlegen - das geht schneller ....
achso ,ja, habe ich auch schonmal erwähnt, dass mich das gnome menü nervt? nach dem ersten book klickt man drauf und ich habe einen total recall - als würde ich an einem 233mhz-pentium 1 mit 32mb ram und windows nt 4 sitzen: klick - wart - klick - wart ... wart ... wart - menü springt kurz auf - man versucht zu reagieren - menü verschwindet wieder (wegen zweiten klick) SAUBER!
Klar zwingt mich keiner Gnome zu benutzen, aber von den Möglichkeiten finde ich es echt super - nur die nahezu enthirnte art und weise der umsetzung schreckt ab und motiviert zu einem wechsel.
ein kumpel meinte mal, dass gnome jetzt auch eine art REGISTRY (wie windows) besitzt. langsam glaube ich das auch
Viele Grüße
za0
Nieder mit der Pauschal-Abzocke der GEZ!
ja geile sache - da kommen wir der sache doch schon näher ...Spasswolf hat geschrieben:Damn Small Linux kann sowas:Quelle: http://www.pro-linux.de/news/2006/9261.htmlCode: Alles auswählen
Auf Rechnern mit mindestens 128 MB kann Damn Small Linux vollständig im RAM laufen, ohne auf eine Festplatte zuzugreifen. Dies soll ein enorm schnelles Starten von Programmen ermöglichen.
aber ich bin mir sicher, dass man auch was grösseres basteln könnte, worauf jedes programm laufen kann, das man haben will.
=> (LOL) ganzes / (ausser /var /opt /dev /etc /tmp ) in den Ram entpacken
Wenn ich überlege, dass der Ram bei mir immer vollgemüllt ist, mit irgendwelchen gecachten daten, die TOTAL ÜBERFLÜSSIG sind - oh mann!
Thunderbird, Firefox, OpenOffice (ab und zu), Acrobatreader (ab und zu) und schon sind meine 512mb voll und swap (512mb) auch.
SUPA!
Viele Grüße
za0
Nieder mit der Pauschal-Abzocke der GEZ!
Joghurt - wenn ich alle Appz schliesse ist mein Ram zu 40% noch zugemüllt und swap minimiert sich um 5%.Joghurt hat geschrieben:Wie kamen die da bloß nur rein... Da die Daten ja total überflüssig sind, wirst du sie ja bestimmt nicht von der Platte geladen haben...za0 hat geschrieben:Wenn ich überlege, dass der Ram bei mir immer vollgemüllt ist, mit irgendwelchen gecachten daten, die TOTAL ÜBERFLÜSSIG sind - oh mann!!
Viele Grüße
za0
Nieder mit der Pauschal-Abzocke der GEZ!
Obwohl diese Daten zumindest einmal benötigt wurden, sprichst du hier von "vollgemüllt".za0 hat geschrieben:Wenn ich überlege, dass der Ram bei mir immer vollgemüllt ist, mit irgendwelchen gecachten daten
Auf der anderen Seite präsentierst du uns aber einen Vorschlag, der Libraries schon beim Bootvorgang cached, egal ob diese benötigt werden oder nicht
Ich würde da eher in deinem Fall von einer Müllhalde sprechen
Gruß
gms
Schlag mal das Wort "preventiv" im Duden nach.gms hat geschrieben:Obwohl diese Daten zumindest einmal benötigt wurden, sprichst du hier von "vollgemüllt".za0 hat geschrieben:Wenn ich überlege, dass der Ram bei mir immer vollgemüllt ist, mit irgendwelchen gecachten daten
Auf der anderen Seite präsentierst du uns aber einen Vorschlag, der Libraries schon beim Bootvorgang cached, egal ob diese benötigt werden oder nicht
Ich würde da eher in deinem Fall von einer Müllhalde sprechen
Gruß
gms
Wenn Du Libs für die Ausführung von Programmen im Speicher HÄLST, ist das wohl _ETWAS_ anderes, als wenn du eine 20MB-Bilddatei ÖFFNEST um sie zu BEARBEITEN, dies tuest, und sie wieder SCHLIESST - SIE ABER TROTZDEM gecached wird - obwohl sie definitiv NICHT mehr gebraucht wird. DAS IST FÜR MICH DATENMÜLL. KAPIERSTE?
Für Server braucht man keine Libs beim Booten zu laden, aber bei Desktopsystemen schon - weißt Du, wenn Du Gnome benutzt, kannst Du Dich mal mit einem Ticker hinsetzen und mal inkrementieren, wie oft Du GTK-Libs in 24 Std. verwendest (ohne Reboot). MANN!
Außerdem: Vergleiche mal folgendes:
Wenn Du bootest und der Bootvorgang dauert 10 Sekunden länger (bis zum gr. Login (GDM)) wegen den Libs, aber dadurch werden sofort nach dem Login die GnomePanel alle BLITZARTIG geladen. Und egal wie oft Du Dich ein oder ausloggst, die Geschwindigkeit des Ladevorgangs der Panel bleibt konstant.
Wäre das nicht besser als 10 Sekunden kürzer Booten und dann nach jedem Login "zusehen", wie der Rechner (halbwegs) in Zeitlupe die Panel aufbaut - UND DAS BEI JEDEM LOGIN (ohne Neustart) ?
ALSO nochmal für die nicht ganz hellen KÖPFE:
Beispielsweise GTK-Libs (oder QT oder WXWIDGETS) beim Booten laden bewirkt garantiert eine schnellere Applikationsinitialisierung.
UND da man mehr Programme öffnet als man die Kiste bootet, ist das wohl besser, die paar Sekunden Bootzeit zu investieren.
JETZT bleibt nur noch die Frage, wie man das am besten realisiert. Die Lösung mit der Ramdisk ist vielleicht nicht so ganz elegant, oder?
Viele Grüße
za0
Nieder mit der Pauschal-Abzocke der GEZ!
- deadeye
- Beiträge: 561
- Registriert: 14.04.2004 15:32:18
- Lizenz eigener Beiträge: MIT Lizenz
- Wohnort: Ukio, rechts hinterm Feld
-
Kontaktdaten:
Sag mal, meinst Du das Ganze wirklich ernst? Hab am Anfang noch gedacht, Du hast in Deinem ersten Posting nur einen Smiley vergessen, der das Ganze ironisch wirken lässt. Scheint wohl nich so zu sein.
Zu Deiner "revolutionären" Idee, die Libs in den RAM zu laden(von der Kernel-Geschichte möchte ich gar nich reden, da wird mir auch schlecht):
Du hast das Prinzip der shared libraries, die wir alle verwenden aber schon verstanden? Das ist nämlich genau das, man lädt einmal eine Bibliothek(sagen wir GTK als Ganzes) und dann wird die Kopie davon im RAM für alle anderen GTK-Apps mit benutzt. D.h., Dein tolles RORA existiert bereits und funktioniert bestens. Nur eben, dass die Libs nich beim Booten sondern beim ersten Bedarf geladen werden. IMO die sauberste Lösung.
Und zu Deinen Gnome-Sorgen: Du sagst zwanzig mal, das Gnome Dir zu langsam is, dass es Dir zu nicht gefällt, weil Du nich damit klar kommst und so weiter. Vielleicht solltest Du doch mal über nen Wechsel nachdenken, es gibt noch Xfce, das rockt und dann wäre da noch e17, fvwm, windowmaker, ...
Just my two cents,
deadeye
Zu Deiner "revolutionären" Idee, die Libs in den RAM zu laden(von der Kernel-Geschichte möchte ich gar nich reden, da wird mir auch schlecht):
Du hast das Prinzip der shared libraries, die wir alle verwenden aber schon verstanden? Das ist nämlich genau das, man lädt einmal eine Bibliothek(sagen wir GTK als Ganzes) und dann wird die Kopie davon im RAM für alle anderen GTK-Apps mit benutzt. D.h., Dein tolles RORA existiert bereits und funktioniert bestens. Nur eben, dass die Libs nich beim Booten sondern beim ersten Bedarf geladen werden. IMO die sauberste Lösung.
Und zu Deinen Gnome-Sorgen: Du sagst zwanzig mal, das Gnome Dir zu langsam is, dass es Dir zu nicht gefällt, weil Du nich damit klar kommst und so weiter. Vielleicht solltest Du doch mal über nen Wechsel nachdenken, es gibt noch Xfce, das rockt und dann wäre da noch e17, fvwm, windowmaker, ...
Just my two cents,
deadeye
Wenn euch schlecht "dabei" wird, dann lest nicht weiter! Zwingt Euch jemand dazu?
Du, gms, hast Du in den letzten Tagen irgendwie schlecht geschlafen oder so? Du mußt nicht immer das, was Du gerade denkst, auch formulieren - findest Du nicht? - Oh ... ach ja. Das tust Du ja nicht. Hier ist ja nur eine Kleinigkeit durchgesickert - wie?
Falls Du Dich angesprochen gefühlt hast, tut es mir echt leid für Dich! Hätte ich Dich gemeint, dann hätte ich Deinen Namen dahin geschrieben. Also brauchst Du hier nix mit Deinen einfallsreichen Kommentaren zu belegen. Ich bin mir ziemlich sicher, dass Du was von sachlicher Kritik verstehst.
Außerdem: Tagebücherschreiben ist Zeitverschwendung. Das mag zwar ein tolles Hobby sein und verhilft vielleicht bei der Selbstanalyse von "Problemchen" - aber wer es machen will, der tue es - ich brauche sowas nicht. Danke für Deinen Hinweis!
gms hat geschrieben:Du könntest es dir auch ins Tagebuch schreibenza0 hat geschrieben: ALSO nochmal für die nicht ganz hellen KÖPFE:
Du, gms, hast Du in den letzten Tagen irgendwie schlecht geschlafen oder so? Du mußt nicht immer das, was Du gerade denkst, auch formulieren - findest Du nicht? - Oh ... ach ja. Das tust Du ja nicht. Hier ist ja nur eine Kleinigkeit durchgesickert - wie?
Falls Du Dich angesprochen gefühlt hast, tut es mir echt leid für Dich! Hätte ich Dich gemeint, dann hätte ich Deinen Namen dahin geschrieben. Also brauchst Du hier nix mit Deinen einfallsreichen Kommentaren zu belegen. Ich bin mir ziemlich sicher, dass Du was von sachlicher Kritik verstehst.
Außerdem: Tagebücherschreiben ist Zeitverschwendung. Das mag zwar ein tolles Hobby sein und verhilft vielleicht bei der Selbstanalyse von "Problemchen" - aber wer es machen will, der tue es - ich brauche sowas nicht. Danke für Deinen Hinweis!
Viele Grüße
za0
Nieder mit der Pauschal-Abzocke der GEZ!
wen du hier ansprechen wolltest, ist nicht relevant. Niemand hat dir einen Grund für diesen ausfälligen Tonfall gegeben.za0 hat geschrieben:Falls Du Dich angesprochen gefühlt hast, tut es mir echt leid für Dich! Hätte ich Dich gemeint, dann hätte ich Deinen Namen dahin geschrieben.
Auch Joghurt, Spasswolf, dopehouse, uljanow oder king-crash haben dir keinen Anlaß gegebenza0 hat geschrieben:Hätte ich Dich gemeint, dann hätte ich Deinen Namen dahin geschrieben.
wenn du sachlich bleibst, könnten wir weiter diskutierenza0 hat geschrieben:Also brauchst Du hier nix mit Deinen einfallsreichen Kommentaren zu belegen. Ich bin mir ziemlich sicher, dass Du was von sachlicher Kritik verstehst.
Gruß
gms