Das stimmt sicher schon. Aber viele Schwierigkeiten entstehen ja eben dadurch, dass das alles doch intern nicht so toll aufgebaut ist und vieles gammelt. Wäre das alles wirklich schlüssig aufgebaut, ist das _ein_ ganz tiefer und kleiner Layer, den man (automatisiert natürlich) testen müsste, ggf. etwas fixen müsste (hauptsächlich aber, sobald eine _neue_ Architektur aufkommt), und dann wär's das. Stattdessen stolpert jeder aber in höheren Schichten etwa durch C++ und muss aufpassen, welche Datentypen man benutzt, fummelt wildeste ifdefs zusammen, usw usf.
Klar, den Distributionen bleibt dann unter diesen Umständen ggf. nichts anderes übrig, als die Müllhalde übersichtlich zu halten. Denen würde ich den Vorwurf nicht machen.
Das ist ja eigentlich genau so, wie Compiler aufgebaut sind: Backends für die verschiedenen Architekturen, Frontends für die verschiedenen Programmiersprachen, und dazwischen eine interne Repräsentation. Theoretisch also alles schön abstrahiert.
Es kann nun aber im Laufe der Jahre passieren, dass so ein Compiler umgebaut wird, sich interne Schnittstellen ändern usw., und dann wird die Unterstützung einer exotischen Architektur (oder exotischen Programmiersprache) eingeschränkt oder komplett abgeschafft, weil sich niemand findet, der den Code portieren möchte.
Du hast aber auch Recht, dass vieles gammelt oder zumindest früher gegammelt hat. Bspw. das "long" je nach Architektur, Compiler und Betriebssystem unterschiedliche Länge hat. Es gibt zwar schon seit C99 int32_t, int64_t usw., aber das verwendet meist keiner. Das hätte man von Anfang an richtig designen müssen.
> Das hätte man von Anfang an richtig designen müssen.
Genau das.
Ansonsten hört man ja immer nur aus allen Gassen das stolze Getrommel, es wäre alles toll designt und Plattformunabhängigkeit wäre so eine große Stärke (von Unix/Linux Ökosystemen).
Plattformunabhängigkeit wäre so eine große Stärke (von Unix/Linux Ökosystemen).
Ist es doch auch, weil es frei ist und jeder es auf seine Plattform portieren kann.
Aber niemand hat behauptet, man bekäme diese Unterstützung diverser Plattformen völlig ohne Aufwand. Es muss sich eben jemand finden, der Linux auf einer (exotischen) Plattform benutzt und der willens ist, zu testen, beizutragen und zu pflegen. Vom Himmel fällt Plattformunabhängigkeit nicht.
> Ist es doch auch, weil es frei ist und jeder es auf seine Plattform portieren kann.
Das ist, als würden Unix-Enthusiasten gebetsmühlenartig behaupten, alles würde per Sprachsteuerung (oder Gedankensteuerung) funktionieren; und wenn man nachhakt, würden sie dir sagen "Naja, der Code ist offen, du kannst das da einbauen. Sag Bescheid, wenn du es hast!".
Das ist schon ein bisschen billig, oder?
Es geht ja nur darum, eine über lange Zeit verbreitete Plattform zu konservieren. Und wenn das alles so schwierig ist, nunja, etwas schade. Was ich sagen will: Dann soll man doch in seiner Außendarstellung ehrlicher sein, und nicht dauernd rumposaunen, wie toll schlüssig das ganze System aufgebaut wäre. Wäre es schlüssig aufgebaut, könnte man eine existierende Plattform ohne großen Aufwand weiter anbieten. Indem man _eine_ kleine tiefe Systemschicht weiter pflegt (naja - sie ist ja fertig, hauptsächlich testet man sie gelegentlich mal in einer VM). Und dass es eben nicht schlüssig aufgebaut ist, wissen wir ja im Prinzip alle. Schon die große Verbreitung von C macht das ja auch wirklich nicht leicht. Und für diese Verbreitung gibt es natürlich gute Gründe; auch historisch. Aber dann soll man halt als Community nicht immer große Versprechen abgeben, die man dann wieder einfangen muss, wenn es jemand wagt, das Versprechen zu belasten.
WER hat denn konkret WAS rumposaunt? Konkret bitte.
Und zum Rest: Aus der realen Software-Entwicklung und zwar aus der Perspektive des "Business Owners" und Testmanagers für Abnahmen kann ich Dir berichten, das in der Theorie immer alles einfach ist. Von den Programmierern und von den Infrastruktur-Leuten hören wir häufig "das müsste jetzt" und trotzdem tut es nicht und wir hören "das dürfte eigentlich nicht" und trotzdem ist es so.
Was ich damit sagen will: Egal, wie gut etwas designt ist, man muss es trotzdem immer wieder testen. Und wenn das mangels Interesse niemand tut (denn das ist immer ein riesen Aufwand), dann schleichen sich Fehler ein und die führen eben dazu, das eine Plattform auch mal aufgegeben wird. Es muss immer jemand dan Arsch hochbekommen und aktiv was tun. Auch bei gut designten Systemen und Techniken.
WER konkret WAS rumposaunt hat, kann ich dir jetzt selbstverständlich NICHT wiedergeben. Natürlich führe ich darüber kein Log. Und das weißt du auch genau, und genau deshalb fragst du es ja. Es ist immer ein schöner rhetorischer Kniff, bei allgemeinen Betrachtungen den Diskussionspartner auf Konkretes festzunageln.
Du hast sicher dabei Recht: In der Praxis ist vieles schwieriger als in theoretischen Erwägungen. Ich bin hobbymäßig und berufl. Softwareentwickler; ich weiß da schon ein bisschen, wovon du sprichst! Aber genau da sind wir ja an meinem Punkt. In der Praxis scheint das mit Plattformunabhängigkeit ein schwieriges Unterfangen zu sein. Nicht zuletzt sicher auch, weil sehr viel in C/C++ (o.ä.) geschrieben ist, und in den tausenden Paketen, die in gängige Distributionen einfließen, überall Fehler gemacht wurden (etwa ungünstige Wahl von Datentypen). Genau da rührt ja die Schwierigkeit her, oder? Es ist ja nicht so, dass gcc oder der Kernel die Unterstützung für 32-Bit x86 aufgegeben hätten!
Daraus leitet sich für mich zweierlei ab:
- Die derzeit benutzten Technologien sind nicht ideal. Es geht aber sicher besser. Damit sollte man sich befassen. Auch danach stimmt deine Annahme sicher: In der Praxis ist es schwieriger. Aber der Gap wird kleiner. Es wird dann weniger schwierig. Ich kann diesem ganz blöden "joa ist halt so, alles schwierig, müssen wir mit leben" wenig abgewinnen. Das mag der Ist-Zustand sein, ist aber wenig innovativ, und führt genau zu diesem Gebrösel, den wir in der Softwarelandschaft derzeit überall haben.
- Das Geplärre der Linux/Unix-Enthusiasten (in Foren; auch für Einsteiger, am Stammtisch, im Beruf, ...) ist unehrlich. Und doch: Das wird so rumposaunt. Es wäre alles toll aufgebaut, Plattformunabhängigkeit wäre sehr ausgeprägt; praktisch als Nebeneffekt des tollen Aufbaus. Btw: Auch bezüglich anderer Aspekte (etwa Sicherheit, Modularität, ...), hört man dauernd vollmundige Versprechen, die gut klingen, aber am Ende nicht belastbar sind.
> Es muss immer jemand dan Arsch hochbekommen und aktiv was tun. Auch bei gut designten Systemen und Techniken.
Nehme mal für einen Augenblick an, dass unsere Software in anderen Sprachen geschrieben wäre. Wasweißich, Java, Javascript, Rust, Python, ... . Ich will das nicht als Vorschlag mißverstanden wissen; nur als kurzes Gedankenexperiment. Dann hättest du mit Plattformunabhängigkeit weniger Probleme. Man hat irgendwo ein paar Schichten, die sich mit den Spezifika befassen. Und DIE müsste man pflegen, ja. Aber die wären auch eher vergleichsweise statisch. Und das ganze Zeug auf höheren Schichten "funktioniert einfach". Das ist ja Fakt. Es gibt ja heute Software auf dieser Basis - und die hat eher keine Probleme mit Plattformunabhängigkeit. Es geht also. Es ist kein Naturgesetz, dass das alles fuddelig ist!
Mein Hauptpunkt nochmal kurz: Die Community ist unehrlich, und lügt sich selbst was in die Tasche! Die Enthusiasten erzählen alle deine "das müsste jetzt"-Story, und verschweigen spendabel die ganzen "das dürfte eigentlich nicht"-Schwierigkeiten.
Und das weißt du auch genau, und genau deshalb fragst du es ja. Es ist immer ein schöner rhetorischer Kniff, bei allgemeinen Betrachtungen den Diskussionspartner auf Konkretes festzunageln.
Ich wollte keine vollständige Enzyklopädie zu diesem Thema haben, ein oder zwei Beispiele hätten schon genügt.
Und wenn hier jemand einen "rhetorischen Kniff" anwendet, dann bist das ja wohl Du: Du erfindest einen Missstand, der angeblich allgemein verbreitet sei und auch allen bekannt, um Dich dann daran abzuarbeiten. Wenn man einen Beleg haben möchte, das es diesen Missstand überhaupt gäbe, ist man ein unfairer Diskutant. Hmm ja, es wundert mich nicht, das Deine Beiträge nicht auf Begeisterung stoßen. Nein, das liegt nicht daran, das Du "die schmerzliche Wahrheit" verkündest, sondern wie Du diskutierst.
Mein Hauptpunkt nochmal kurz: Die Community ist unehrlich, und lügt sich selbst was in die Tasche! Die Enthusiasten erzählen alle deine "das müsste jetzt"-Story, und verschweigen spendabel die ganzen "das dürfte eigentlich nicht"-Schwierigkeiten.
Ich hätte immer noch gerne Beispiele für diese Behauptung.
Sonst bleibe ich bei meinem Punkt, der da heißt: Linus hat einen Kernel für einen 386er geschrieben und mit GNU kombiniert, nicht mehr und nicht weniger. Er hat damals nicht behauptet, das er eine tolle, superportable Sache geschaffen hätte - im Gegenteil, er hielt das ja für ein Hobbyprojekt. Das daraus ein Ökosystem entstanden ist, das auf sehr viel verschiedener Hardware läuft und das vom Embedded-Microcontroller bis zum Riesen-Supercomputer-Cluster liegt einfach daran, dass das Ökosystem unter einer freien Lizenz steht (vielleicht auch daran, das diese Copyleft hat) und das tausende Menschen harte Arbeit reingesteckt haben, diese System auf ihre Plattform zu portieren und für diese zu pflegen. Die Portabilität ist passiert, sie wurde nicht designt.
Es sind mündliche Äußerungen, Stammtisch, Install-Partys, Gespräche auf dem CCC-Congress, ... bzw. Beiträge in irgendwelchen Foren gewesen, oder auf irgendeiner quatschigen Webseite, über die man bei Recherchen zufällig stolpert - meinst du im Ernst, ich hätte mir das mit Autor und Datum notiert?? Ich besuche schon länger keine Foren mehr, um techn. Hilfestellung zu bekommen, weil das in aller Regel ein Schuss in den Ofen ist. Vielleicht hat sich da irgendwas in den letzten fünf bis zehn Jahre dramatisch verändert?! Wird da heutzutage nicht mehr sonstwas bezügl. Linux versprochen?
> Hmm ja, es wundert mich nicht, das Deine Beiträge nicht auf Begeisterung stoßen.
Das stört mich nicht sooo sehr. Ich bin diese Reaktion sehr gewohnt. Ich führe sie aber nicht sooo sehr auf mich zurück. Sie tut mir auch nicht weh, ehrlich! Wenn meine Mitmenschen irgendwas beherrschen, dann sind das Ausblendungsstrategien. Und Schönrederei des eigenen Ökosystems bzw. Schlechtrederei des Fremden. Wenn ich mit x-beliebigen Leuten spreche, stehen die Chancen bei 95%, dass ich nach dem dritten Satz schon keinen Bock mehr habe, weil da nur gequirlte Scheisse kommt.
> Linus hat einen Kernel für einen 386er geschrieben [...]
Linus ist wohl auch nicht so sehr der Diskussionsmittelpunkt. Wie gesagt: Der Kernel hat doch 386 die Unterstützung garnicht entzogen! Es sind die tausenden von Fuddelsprogrämmchen, die irgendwo im Userspace rumhängen, die dilletantisch zusammengeschustert sind (leider auch, weil der hoffnungslos veraltete Unterbau das so wahnsinnig einfach macht).
Ich würde es so sagen: Wenn du nicht der Meinung bist, dass die Community überall große leere Versprechen ausspricht, dann brauchen wir da tiefergehend garnicht drüber diskutieren. Dann fehlt uns dazu völlig die Grundlage. Ich werde dir keine Beispiele liefern.
Das stimmt sicher schon. Aber viele Schwierigkeiten entstehen ja eben dadurch, dass das alles doch intern nicht so toll aufgebaut ist und vieles gammelt. Wäre das alles wirklich schlüssig aufgebaut, ist das _ein_ ganz tiefer und kleiner Layer, den man (automatisiert natürlich) testen müsste, ggf. etwas fixen müsste (hauptsächlich aber, sobald eine _neue_ Architektur aufkommt), und dann wär's das. Stattdessen stolpert jeder aber in höheren Schichten etwa durch C++ und muss aufpassen, welche Datentypen man benutzt, fummelt wildeste ifdefs zusammen, usw usf.
Klar, den Distributionen bleibt dann unter diesen Umständen ggf. nichts anderes übrig, als die Müllhalde übersichtlich zu halten. Denen würde ich den Vorwurf nicht machen.
Das ist ja eigentlich genau so, wie Compiler aufgebaut sind: Backends für die verschiedenen Architekturen, Frontends für die verschiedenen Programmiersprachen, und dazwischen eine interne Repräsentation. Theoretisch also alles schön abstrahiert.
Es kann nun aber im Laufe der Jahre passieren, dass so ein Compiler umgebaut wird, sich interne Schnittstellen ändern usw., und dann wird die Unterstützung einer exotischen Architektur (oder exotischen Programmiersprache) eingeschränkt oder komplett abgeschafft, weil sich niemand findet, der den Code portieren möchte.
Du hast aber auch Recht, dass vieles gammelt oder zumindest früher gegammelt hat. Bspw. das "long" je nach Architektur, Compiler und Betriebssystem unterschiedliche Länge hat. Es gibt zwar schon seit C99 int32_t, int64_t usw., aber das verwendet meist keiner. Das hätte man von Anfang an richtig designen müssen.
> Das hätte man von Anfang an richtig designen müssen.
Genau das.
Ansonsten hört man ja immer nur aus allen Gassen das stolze Getrommel, es wäre alles toll designt und Plattformunabhängigkeit wäre so eine große Stärke (von Unix/Linux Ökosystemen).
Aber niemand hat behauptet, man bekäme diese Unterstützung diverser Plattformen völlig ohne Aufwand.
Es muss sich eben jemand finden, der Linux auf einer (exotischen) Plattform benutzt und der willens ist, zu testen, beizutragen und zu pflegen.
Vom Himmel fällt Plattformunabhängigkeit nicht.
> Ist es doch auch, weil es frei ist und jeder es auf seine Plattform portieren kann.
Das ist, als würden Unix-Enthusiasten gebetsmühlenartig behaupten, alles würde per Sprachsteuerung (oder Gedankensteuerung) funktionieren; und wenn man nachhakt, würden sie dir sagen "Naja, der Code ist offen, du kannst das da einbauen. Sag Bescheid, wenn du es hast!".
Das ist schon ein bisschen billig, oder?
Es geht ja nur darum, eine über lange Zeit verbreitete Plattform zu konservieren. Und wenn das alles so schwierig ist, nunja, etwas schade. Was ich sagen will: Dann soll man doch in seiner Außendarstellung ehrlicher sein, und nicht dauernd rumposaunen, wie toll schlüssig das ganze System aufgebaut wäre. Wäre es schlüssig aufgebaut, könnte man eine existierende Plattform ohne großen Aufwand weiter anbieten. Indem man _eine_ kleine tiefe Systemschicht weiter pflegt (naja - sie ist ja fertig, hauptsächlich testet man sie gelegentlich mal in einer VM). Und dass es eben nicht schlüssig aufgebaut ist, wissen wir ja im Prinzip alle. Schon die große Verbreitung von C macht das ja auch wirklich nicht leicht. Und für diese Verbreitung gibt es natürlich gute Gründe; auch historisch. Aber dann soll man halt als Community nicht immer große Versprechen abgeben, die man dann wieder einfangen muss, wenn es jemand wagt, das Versprechen zu belasten.
> _eine_ kleine tiefe Systemschicht
PS: ... und die Compiler natürlich.
Ach Josef,
WER hat denn konkret WAS rumposaunt? Konkret bitte.
Und zum Rest: Aus der realen Software-Entwicklung und zwar aus der Perspektive des "Business Owners" und Testmanagers für Abnahmen kann ich Dir berichten, das in der Theorie immer alles einfach ist. Von den Programmierern und von den Infrastruktur-Leuten hören wir häufig "das müsste jetzt" und trotzdem tut es nicht und wir hören "das dürfte eigentlich nicht" und trotzdem ist es so.
Was ich damit sagen will: Egal, wie gut etwas designt ist, man muss es trotzdem immer wieder testen.
Und wenn das mangels Interesse niemand tut (denn das ist immer ein riesen Aufwand), dann schleichen sich Fehler ein und die führen eben dazu, das eine Plattform auch mal aufgegeben wird.
Es muss immer jemand dan Arsch hochbekommen und aktiv was tun.
Auch bei gut designten Systemen und Techniken.
Ach "Nur ein Leser",
WER konkret WAS rumposaunt hat, kann ich dir jetzt selbstverständlich NICHT wiedergeben. Natürlich führe ich darüber kein Log. Und das weißt du auch genau, und genau deshalb fragst du es ja. Es ist immer ein schöner rhetorischer Kniff, bei allgemeinen Betrachtungen den Diskussionspartner auf Konkretes festzunageln.
Du hast sicher dabei Recht: In der Praxis ist vieles schwieriger als in theoretischen Erwägungen. Ich bin hobbymäßig und berufl. Softwareentwickler; ich weiß da schon ein bisschen, wovon du sprichst! Aber genau da sind wir ja an meinem Punkt. In der Praxis scheint das mit Plattformunabhängigkeit ein schwieriges Unterfangen zu sein. Nicht zuletzt sicher auch, weil sehr viel in C/C++ (o.ä.) geschrieben ist, und in den tausenden Paketen, die in gängige Distributionen einfließen, überall Fehler gemacht wurden (etwa ungünstige Wahl von Datentypen). Genau da rührt ja die Schwierigkeit her, oder? Es ist ja nicht so, dass gcc oder der Kernel die Unterstützung für 32-Bit x86 aufgegeben hätten!
Daraus leitet sich für mich zweierlei ab:
- Die derzeit benutzten Technologien sind nicht ideal. Es geht aber sicher besser. Damit sollte man sich befassen. Auch danach stimmt deine Annahme sicher: In der Praxis ist es schwieriger. Aber der Gap wird kleiner. Es wird dann weniger schwierig. Ich kann diesem ganz blöden "joa ist halt so, alles schwierig, müssen wir mit leben" wenig abgewinnen. Das mag der Ist-Zustand sein, ist aber wenig innovativ, und führt genau zu diesem Gebrösel, den wir in der Softwarelandschaft derzeit überall haben.
- Das Geplärre der Linux/Unix-Enthusiasten (in Foren; auch für Einsteiger, am Stammtisch, im Beruf, ...) ist unehrlich. Und doch: Das wird so rumposaunt. Es wäre alles toll aufgebaut, Plattformunabhängigkeit wäre sehr ausgeprägt; praktisch als Nebeneffekt des tollen Aufbaus. Btw: Auch bezüglich anderer Aspekte (etwa Sicherheit, Modularität, ...), hört man dauernd vollmundige Versprechen, die gut klingen, aber am Ende nicht belastbar sind.
> Es muss immer jemand dan Arsch hochbekommen und aktiv was tun. Auch bei gut designten Systemen und Techniken.
Nehme mal für einen Augenblick an, dass unsere Software in anderen Sprachen geschrieben wäre. Wasweißich, Java, Javascript, Rust, Python, ... . Ich will das nicht als Vorschlag mißverstanden wissen; nur als kurzes Gedankenexperiment. Dann hättest du mit Plattformunabhängigkeit weniger Probleme. Man hat irgendwo ein paar Schichten, die sich mit den Spezifika befassen. Und DIE müsste man pflegen, ja. Aber die wären auch eher vergleichsweise statisch. Und das ganze Zeug auf höheren Schichten "funktioniert einfach". Das ist ja Fakt. Es gibt ja heute Software auf dieser Basis - und die hat eher keine Probleme mit Plattformunabhängigkeit. Es geht also. Es ist kein Naturgesetz, dass das alles fuddelig ist!
Mein Hauptpunkt nochmal kurz: Die Community ist unehrlich, und lügt sich selbst was in die Tasche! Die Enthusiasten erzählen alle deine "das müsste jetzt"-Story, und verschweigen spendabel die ganzen "das dürfte eigentlich nicht"-Schwierigkeiten.
Und wenn hier jemand einen "rhetorischen Kniff" anwendet, dann bist das ja wohl Du: Du erfindest einen Missstand, der angeblich allgemein verbreitet sei und auch allen bekannt, um Dich dann daran abzuarbeiten.
Ich hätte immer noch gerne Beispiele für diese Behauptung.Wenn man einen Beleg haben möchte, das es diesen Missstand überhaupt gäbe, ist man ein unfairer Diskutant. Hmm ja, es wundert mich nicht, das Deine Beiträge nicht auf Begeisterung stoßen.
Nein, das liegt nicht daran, das Du "die schmerzliche Wahrheit" verkündest, sondern wie Du diskutierst.
Sonst bleibe ich bei meinem Punkt, der da heißt: Linus hat einen Kernel für einen 386er geschrieben und mit GNU kombiniert, nicht mehr und nicht weniger. Er hat damals nicht behauptet, das er eine tolle, superportable Sache geschaffen hätte - im Gegenteil, er hielt das ja für ein Hobbyprojekt.
Das daraus ein Ökosystem entstanden ist, das auf sehr viel verschiedener Hardware läuft und das vom Embedded-Microcontroller bis zum Riesen-Supercomputer-Cluster liegt einfach daran, dass das Ökosystem unter einer freien Lizenz steht (vielleicht auch daran, das diese Copyleft hat) und das tausende Menschen harte Arbeit reingesteckt haben, diese System auf ihre Plattform zu portieren und für diese zu pflegen.
Die Portabilität ist passiert, sie wurde nicht designt.
> ein oder zwei Beispiele hätten schon genügt.
Es sind mündliche Äußerungen, Stammtisch, Install-Partys, Gespräche auf dem CCC-Congress, ... bzw. Beiträge in irgendwelchen Foren gewesen, oder auf irgendeiner quatschigen Webseite, über die man bei Recherchen zufällig stolpert - meinst du im Ernst, ich hätte mir das mit Autor und Datum notiert?? Ich besuche schon länger keine Foren mehr, um techn. Hilfestellung zu bekommen, weil das in aller Regel ein Schuss in den Ofen ist. Vielleicht hat sich da irgendwas in den letzten fünf bis zehn Jahre dramatisch verändert?! Wird da heutzutage nicht mehr sonstwas bezügl. Linux versprochen?
> Hmm ja, es wundert mich nicht, das Deine Beiträge nicht auf Begeisterung stoßen.
Das stört mich nicht sooo sehr. Ich bin diese Reaktion sehr gewohnt. Ich führe sie aber nicht sooo sehr auf mich zurück. Sie tut mir auch nicht weh, ehrlich!
Wenn meine Mitmenschen irgendwas beherrschen, dann sind das Ausblendungsstrategien. Und Schönrederei des eigenen Ökosystems bzw. Schlechtrederei des Fremden. Wenn ich mit x-beliebigen Leuten spreche, stehen die Chancen bei 95%, dass ich nach dem dritten Satz schon keinen Bock mehr habe, weil da nur gequirlte Scheisse kommt.
> Linus hat einen Kernel für einen 386er geschrieben [...]
Linus ist wohl auch nicht so sehr der Diskussionsmittelpunkt. Wie gesagt: Der Kernel hat doch 386 die Unterstützung garnicht entzogen! Es sind die tausenden von Fuddelsprogrämmchen, die irgendwo im Userspace rumhängen, die dilletantisch zusammengeschustert sind (leider auch, weil der hoffnungslos veraltete Unterbau das so wahnsinnig einfach macht).
Ich würde es so sagen: Wenn du nicht der Meinung bist, dass die Community überall große leere Versprechen ausspricht, dann brauchen wir da tiefergehend garnicht drüber diskutieren. Dann fehlt uns dazu völlig die Grundlage. Ich werde dir keine Beispiele liefern.