amiga-news ENGLISH VERSION
.
Links| Forum| Kommentare| News melden
.
Chat| Umfragen| Newsticker| Archiv
.

amiga-news.de Forum > Programmierung > Sharing von PPC-Amigas übers Web [ - Suche - Neue Beiträge - Registrieren - Login - ]

-1- [ - Beitrag schreiben - ]

05.01.2008, 18:22 Uhr

dandy
Posts: 2552
Nutzer
Beim Lesen der News stieß ich auf die Nachricht, daß da jemand einen Flash-Player für den Amiga ins Aminet gestellt hat.

Neugierig wie ich nunmal bin, bin ich dem Link gefolgt und habe mir das ReadMe durchgelesen.

Dort schrieb der Author, daß er mangels PPC-Hardware keine OS4-Version erstellen konnte.

Beim Lesen dieser Zeilen kam mir die Idee, solchen Entwicklern irgendwie zu helfen.

Ich habe hier z.B. einen voll aufgemotzten Amiga 4000 mit CyberstormPPC, Mediator, Voodoo4, 10/100mBit NIC, Terratec 512i digital, Spider2 USB 2.0 highspeed, DVD-RW, Tape Streamer usw. rumzustehen.

Leider habe ich aus berufliche und privaten Gründen keine Zeit, für den Amiga zu programmieren.

Wie bringt man nun willige Entwickler ohne PPC Hardware mit Leuten zusammen, die - wie ich - zwar PPC Hardware haben, aber aus welchen Gründen auch immer keine Amiga Entwickler sind?

Das sollte doch über das Internet problemlos möglich sein - oder?

Wenn nun ein Amiga Entwickler diesen Gedanken aufgreift und eine Software schafft, die es Entwicklern über das Web ermöglicht,
sich auf einem irgendwo auf der Welt stehenden PPC-Amiga einzuloggen und dann auf diesem "online" für OS4 zu entwickeln.

Quasi etwas ähnliches wie "Remote Desktop" für den Amiga.

Ich meine - die Hardware steht hier unnütz rum wenn ich im Bett liege und schlafe oder auf der Arbeit bin - eigentlich könnte sie da auch von Entwicklern zur OS4 - Softwareentwicklung genutzt werden.

Nur ist mir keine Amiga Soft bekannt, mit der sich sowas realisieren ließe - müßte also erstmal geschrieben werden. Möglicherweise lässt sich da ja auch was aus vorhandener PD "zusammenstoppeln".

Die Soft sollte natürlich so funktionieren, daß der Entwickler seinen Code bei sich auf seinem Rechner abspeichert und ihn dann via Web auf dem zur Verfügung gestellten PPC-Amiga ausführt.

Was haltet ihr davon - wäre das eine Maßnahme, angesichts der gegenwärtigen Hardwarelage willigen Amiga Entwicklern AmigaPPC-HW zugänglich zu machen??

--
Ciao,

Dandy

Wenn es jemandem Spaß macht, zu Marschmusik in Reih' und Glied zu marschieren, so verachte ich ihn schon.
Er hat sein Großhirn nur aus Versehen bekommen - bei ihm hätte auch schon das Rückenmark gereicht!
(Albert Einstein)

Edit:

Ah - ich vergaß:
Ein frohes, gesundes und erfolgreiches Jahr 2008 wünsche ich Euch allen!

[ Dieser Beitrag wurde von dandy am 05.01.2008 um 18:35 Uhr geändert. ]

[ - Antworten - Zitieren - Direktlink - ]

05.01.2008, 18:56 Uhr

ChrisP
Posts: 983
Nutzer
Gibt es fuer den Amiga einen Telnet-Server? Oder einen SSH-Server? Damit sollte das gehen.
--

Suche Amiga 2500UX

[ - Antworten - Zitieren - Direktlink - ]

05.01.2008, 19:48 Uhr

p-OS
Posts: 131
Nutzer
Entwickeln läßt sich auch auf nem 68K-Rechner (Cross-Compiler). Bloß zum Testen müßte das ausführbare Programm auf den PPC-Rechner. Dafür müßte lediglich ein Austauschverzeichnis freigegeben sein (SAMBA) oder dein PPC-Rechner einen ftp-Server installiert haben.
Zum Testen (auch grafischer) Anwendungen kann man dann ja über VNC zugreifen. Geschwindigkeit ist dann zwar nicht berauschend, wenn man bedenkt, daß auch breitbandige Internetzugägne nur in eine Richtung schnell sind.
Problematisch ist eher die Frage einer ordentlichen Absicherung des Zugriffs. Soll ja nicht jeder ungefragt das System zerschießen dürfen. Insbesondere, wenn der Rechner nicht einfach nur über ist, sondern auch von dir aktiv zum Erstellen von Dokumenten, Mails etc genutzt wird. Von der Frage des Schutzes deiner Privatsphäre mal abgesehn. AmigaOS ist halt nicht auf Multi-User-Betrieb ausgelegt. Und einfach zwei komplett getrennte Umgebungen (->Virtualisierung) ist mangels geeihneter Software auch nicht möglich. Evtl. zwei Platten vorhalten, die wechselweise am Rechner hängen ?
Für andere Systeme gibt's ja so nen Service wie den von techonline.com, über den man Remote auf einer Vielzahl verschiedener Rechnerarchitekturen entwickeln/testen kann.

[ - Antworten - Zitieren - Direktlink - ]

05.01.2008, 20:39 Uhr

akl
Posts: 265
Nutzer
@p-OS:
Auf Crosscompiler würde ich mich nicht unbedingt verlassen wollen (z.B. MOS SDK).

[ - Antworten - Zitieren - Direktlink - ]

07.01.2008, 10:26 Uhr

gni
Posts: 1106
Nutzer
Zitat:
akl:
@p-OS:
Auf Crosscompiler würde ich mich nicht unbedingt verlassen wollen (z.B. MOS SDK).

Könntest Du das bitte etwas konkreter ausführen?

[ - Antworten - Zitieren - Direktlink - ]

07.01.2008, 10:55 Uhr

Holger
Posts: 8090
Nutzer
Da derjenige, der den Amiga zur Verfügung stellt, sowieso prinzipiell alles sehen kann, was der Entwickler macht, könnte man auch einfach ein Projektarchiv mit Sourcecode und Makefile rüberschicken, welches der User dann durchlaufen lässt. So etwas lässt sich natürlich via CVS/SVN optimieren.

Der Haken liegt allerdings beim ersten Durchlauf, der meist aufgrund der Schwierigkeiten beim Einrichten der Umgebung und den vielen kleinen Feinheiten, wenn das Projekt noch nicht angepasst ist. Andernfalls würden viel mehr User einfach Open-Source-Projekte von den jeweiligen Repositories auschecken und eine AOS4-Version erzeugen.

Ich glaube aber auch nicht, dass sich das so einfach via Remote-Verbindung auf dem AOS4-Rechner einrichten ließe. Da müsste wenigsten am Anfang der erfahrene Entwickler mal davor sitzen.

Allerdings könnte natürlich Hyperion solche AOS4- Compile-Service Rechner ins Netz stellen. Die wüssten auch am ehesten, wie man verhindert, dass ein eingeloggter User sich die ganze AOS4-Installation saugt.

mfg

--
Good coders do not comment. What was hard to write should be hard to read too.

[ - Antworten - Zitieren - Direktlink - ]

08.01.2008, 07:04 Uhr

dandy
Posts: 2552
Nutzer
Zitat:
Original von Holger:

...
Allerdings könnte natürlich Hyperion solche AOS4- Compile-Service Rechner ins Netz stellen. Die wüssten auch am ehesten, wie man verhindert, dass ein eingeloggter User sich die ganze AOS4-Installation saugt.
...


Hmmmm - also - wenn ihr meint, daß diese Idee grudsätzlich gut ist und weiterverfolgt werden sollte, dann habe ich auch kein Problem damit, Hans-Jörg Frieden mal in diesen Thread einzuladen...


--
Ciao,

Dandy

Wenn es jemandem Spaß macht, zu Marschmusik in Reih' und Glied zu marschieren, so verachte ich ihn schon.
Er hat sein Großhirn nur aus Versehen bekommen - bei ihm hätte auch schon das Rückenmark gereicht!
(Albert Einstein)

[ - Antworten - Zitieren - Direktlink - ]

08.01.2008, 10:06 Uhr

R-TEAM
Posts: 1030
Nutzer
Hi,

Zitat:
Original von dandy:
...., dann habe ich auch kein Problem damit, Hans-Jörg Frieden mal in diesen Thread einzuladen...


--
Ciao,

Dandy


Da wirst du kein glück haben.
Poste deine Idee lieber auf Amigans.net.
Dort liest UND postet er regelmäsig [und sein Bruder auch], wie die
ganze OS4 Devs manschaft.

Grüße
R-TEAM
--
My Hardware Config and GFX-Work on my HomePage.

Fax : (+49) 09191 702028
Long Live T H E [|D|A|R|K^><^E|M|P|I|R|E|]

[ - Antworten - Zitieren - Direktlink - ]

08.01.2008, 15:00 Uhr

Solar
Posts: 3674
Nutzer
Compilieren auf einem Remote-Rechner über SSH ist mal gar kein Problem, das mache ich jeden Tag beruflich. Alles, was es dafür braucht, ist eine Entwicklungsumgebung und ein SSH-Server auf der Zielmaschine und ein SSH-Client beim Entwickler. Siehe SourceForge Compiler-Farm.

Ob's einen AmigaOS-SSH-Server gibt, weiß ich nicht, dürfte aber doch kein so großes Problem darstellen, oder?

[ - Antworten - Zitieren - Direktlink - ]

08.01.2008, 15:21 Uhr

Robin
Posts: 1056
Nutzer
@Solar:

Mir ist bis jetzt kein Server bekannt.
Und auch die Remotedesktop-Programme liegen
nur als Clients vor soweit ich weiss ...
--
(Bild) http://my.morphosi.net/
morphos

[ - Antworten - Zitieren - Direktlink - ]

08.01.2008, 16:06 Uhr

akl
Posts: 265
Nutzer
@gni:

Die aktuelle Crosscompiler-Version ist AFAIR GCC 2.95.3-basiert (soweit ich weiss diese hier: http://www.zerohero.se/cross/mos.html). Mit GCC 2.95.3 erhält man unter MOS-native in einer Reihe von Fällen jedoch stellenweise kaputten Code (je größer -On mit n>=0, desto größer die Wahrscheinlichkeit). Mit dem inoffiziellen GCC 2.95.4 verschwindet das Problem teilweise (IIRC diese hier: http://www.tbs-software.com/morgoth/projects.html). In mindestens einem Fall lag es jedoch unmittelbar an der Größe einer .c-Datei (in zwei Files gesplittet und Problem verschwunden), was ich doch recht seltsam finde. Weiterhin stehen auch noch mehrere libnix-Varianten mit unterschiedlichen Bugs zur Auswahl, von denen zumindest die neueste(?) offensichtlich nicht mehr kompatibel zu den vorherigen ist. Ixemul will ich gar nicht thematisieren.

Wer garantiert mir also, dass - wenn ich später denselben Source nochmal unter MOS-native compiliere - alles noch läuft, insbesondere wenn der MOS-native GCC vermutlich mit sich selbst compiliert worden ist und noch mutmassliche Ixemul-Bugs mitschleift? Oder umgekehrt, wenn es nicht läuft, compiliere ich dann alles nochmal lokal um zu sehen ob es dann geht?

Wenn's nicht so schwer wäre, ein aufgehangenes MOS per VNC wieder neu zu starten und VNC per se nicht so imperformant(*) wäre, würde ich eher jenen Weg empfehlen... allerdings sehe ich den Use-Case von reinem Remote-Cross-Compiling ohne Testmöglichkeit auf dem Target sowieso nicht ganz, und hier braucht es entweder lokalen Zugang oder VNC oder eine Mischung verschiedener Zugänge.

Vielleicht bin ich altmodisch, aber für Entwicklung "zuhause" möchte ich gerne ein SDK was auf dem Target out-of-the-box fehlerfrei läuft mit einer stabilen und abwärtskompatiblen C-Library, die bei Bedarf (notfalls externe Semaphore und nur selektive Verwendung von Funktionen) auch in einer Library läuft. Am Besten ein aktueller GCC (4er-Serie) mit AltiVec-Support (nicht nur im Compiler sondern auch in der ABI bzw. im Exec). Wenn das stabil verfügbar ist, denke ich nochmal über Crosscompiling nach, vielleicht sogar für ein EFIKA oder dessen Nachfolger. (**)

Außerdem ist ein 1 GHz Pegasos ausreichend schnell für GCC. Mag auf dem EFIKA anders aussehen - aber damit sind wir wieder bei dem Punkt, dass MOS 2.0 und MOS/EFIKA bzw. das EFIKA selbst gar (noch) nicht (mehr) offiziell verfügbar sind. Macht auch nicht wirklich Spass, für Anwender um ein MOS 1.4.5 herum zu debuggen, was eingeweihte Entwickler ohnehin nicht mehr verwenden - macht es auch nicht einfacher, mit MOS-Entwicklern Bugs zu thematisieren. Weder die des OS noch die des Compilers oder des JIT.

(*) ok, und die Amiga-Tasten & Co. hat man ebenfalls nicht - da vergeht einem spätestens nach 15min der Spass, besonders beim Editieren oder Testen

[ - Antworten - Zitieren - Direktlink - ]

08.01.2008, 16:10 Uhr

Holger
Posts: 8090
Nutzer
Zitat:
Original von Solar:
Compilieren auf einem Remote-Rechner über SSH ist mal gar kein Problem, das mache ich jeden Tag beruflich. Alles, was es dafür braucht, ist eine Entwicklungsumgebung und ein SSH-Server auf der Zielmaschine und ein SSH-Client beim Entwickler. Siehe SourceForge Compiler-Farm.

Ob's einen AmigaOS-SSH-Server gibt, weiß ich nicht, dürfte aber doch kein so großes Problem darstellen, oder?

Für einen erfahrenen Anwender dürfte das kein Problem darstellen. Aber wie man hier im Forum beobachten kann, haben die meisten User schon Schwierigkeiten, eine funktionierende Compiler-Umgebung einzurichten. Und ob man das via ssh installieren kann, ohne funktionierender graphischer Schnittstelle und mit Programmen, die gewohnt sind, dass der Amiga immer ein GUI hat...

Und dann wäre noch die Frage, wie man wirksam ein Saugen des AOS4 über den gerade eingerichteten Zugang verhindern kann. Das AmigaOS besitzt da nicht ganz so wirksame Mechanismen, wie z.B. Linux.

mfg

--
Good coders do not comment. What was hard to write should be hard to read too.

[ - Antworten - Zitieren - Direktlink - ]

08.01.2008, 16:23 Uhr

Solar
Posts: 3674
Nutzer
Zitat:
Original von Holger:

Und dann wäre noch die Frage, wie man wirksam ein Saugen des AOS4 über den gerade eingerichteten Zugang verhindern kann.


Ieks.... ich sehe, ich war zu lange in Linux-Land. Daran hatte ich nicht gedacht.

8o I-)

[ Dieser Beitrag wurde von Solar am 08.01.2008 um 16:24 Uhr geändert. ]

[ - Antworten - Zitieren - Direktlink - ]

08.01.2008, 16:55 Uhr

bruZard
Posts: 307
Nutzer
Ich sehe die Problematik nicht ... im PC Bereich habe ich oft das Problem dass ich meinen Source nicht für MacOS kompilieren kann. Da findet sich dann i.d.R. jemand der das für mich übernimmt > kompilieren, testen, Bericht basteln und kommentieren.

--
Methusalem Kino - Das Blog über Nichts und Alles.

[ - Antworten - Zitieren - Direktlink - ]

09.01.2008, 13:50 Uhr

gni
Posts: 1106
Nutzer
Zitat:
akl:
Die aktuelle Crosscompiler-Version ist AFAIR GCC 2.95.3-basiert (soweit ich weiss diese hier: http://www.zerohero.se/cross/mos.html).

Da auf der MOS Developer Site die diffs für den aktuellen MOS SDK GCC zu bekommen sind, kann man sich bei Bedarf selber einen Cross-Compiler erstellen. Derzeit wäre das sogar aktueller als alles Binär verfügbare.
Zitat:
Mit GCC 2.95.3 erhält man unter MOS-native in einer Reihe von Fällen jedoch stellenweise kaputten Code (je größer -On mit n>=0, desto größer die Wahrscheinlichkeit). Mit dem inoffiziellen GCC 2.95.4 verschwindet das Problem teilweise (IIRC diese hier: http://www.tbs-software.com/morgoth/projects.html).
AFAICT, zwischen 2.95.3 und 2.95.4 gibt es bei PPC keinen Unterschied was die Codegenerierung angeht. Zudem enthält der "offizielle" GCC für MOS mittlerweile fast alle relevanten Debian-Patches plus ein paar zusätzliche Korrekturen. Hast Du den aktuellen GCC (also die 2007-Release) von der MOS-Entwicklerseite mal getestet? IMHO ist diese Version sowohl dem 2.95.4 von Morgoth als auch den Cross-Compilern von Zerohero vorzuziehen. Hast Du außer -O<n> noch andere Flags verwendet? Wobei ich von n>2 immer abrate.
Zitat:
In mindestens einem Fall lag es jedoch unmittelbar an der Größe einer .c-Datei (in zwei Files gesplittet und Problem verschwunden), was ich doch recht seltsam finde.
Wie groß soll die denn gewesen sein? Wie hat sich der Fehler geäußert?
Zitat:
Weiterhin stehen auch noch mehrere libnix-Varianten mit unterschiedlichen Bugs zur Auswahl, von denen zumindest die neueste(?) offensichtlich nicht mehr kompatibel zu den vorherigen ist. Ixemul will ich gar nicht thematisieren.
Fehler in den Runtimes haben doch erstmal nicht direkt was mit dem GCC zu tun oder? libnix-Fehler haben auf den MOS-GCC auch keinen Einfluß, da dort (wie auch unter m68k) ixemul benutzt wird. Für libnix gab/gibt es doch immer mal wieder Updates. FWIW, was für Fehler sind denn im aktuellen MOS-libnix vorhanden?
Zitat:
Wer garantiert mir also, dass - wenn ich später denselben Source nochmal unter MOS-native compiliere - alles noch läuft, insbesondere wenn der MOS-native GCC vermutlich mit sich selbst compiliert worden ist und noch mutmassliche Ixemul-Bugs mitschleift?
AFAIK, Unterschiede in der Codegenerierung bei gleicher Compilerversion habe ich nur bei Floats gesehen und das war auf einer Alpha mit einem m68k-Crosscompiler. Ansonsten konnte ich nie einen Unterschied feststellen (und ich benutze häufig Crosscompiler). IMHO ist es eher unwahrscheinlich, das Fehler der Runtime Auswirkungen auf die Codegenerierung haben. Und nur zu Info: der MOS-native GCC auf der Entwicklerseite wurde nicht unter MOS erstellt. Die aktuellen Archive wurden alle unter FreeBSD per Cross-Compiler erstellt und anschließend kurz "getestet", dh. es wurde eine HelloWorld.c übersetzt und ausgeführt.
Zitat:
Oder umgekehrt, wenn es nicht läuft, compiliere ich dann alles nochmal lokal um zu sehen ob es dann geht?
Das sollte keinen Unterschied machen.
Zitat:
Vielleicht bin ich altmodisch, aber für Entwicklung "zuhause" möchte ich gerne ein SDK was auf dem Target out-of-the-box fehlerfrei läuft mit einer stabilen und abwärtskompatiblen C-Library, die bei Bedarf (notfalls externe Semaphore und nur selektive Verwendung von Funktionen) auch in einer Library läuft.
Ich hatte weder unter m68k noch unter MOS jemals Stabilitätsprobleme mit dem GCC und ich habe wirklich viele GCC-Versionen benutzt. Auch ixemul hat mir als GCC-Runtime nie Instabilitäten verursacht, aber eventuell habe ich es auch nur nie bemerkt? ;-) Was die Verwendung von Funktionen der C-Standardbibliothek in Amiga-Shared-Libraries angeht, bin ich allerdings anderer Ansicht. Nur sehr wenige Funktionen können wirklich problemlos in einen solchen Bibliothek verwendet werden. Und Semaphoren möchte ich da schon gar nicht sehen.
Zitat:
Am Besten ein aktueller GCC (4er-Serie) mit AltiVec-Support (nicht nur im Compiler sondern auch in der ABI bzw. im Exec).
Ich kann die Qualität des GCC nach 2.95.x nicht wirklich beurteilen. Ich kenne da nur die Aussagen des MOS-Teams. Dennoch habe auch mit GCC3 bzw GCC4 PowerUP-Programme erstellt und die haben dann auch funktioniert (zb. mpega_libmad oder xpkGZIP).

[ - Antworten - Zitieren - Direktlink - ]

11.01.2008, 18:19 Uhr

p-OS
Posts: 131
Nutzer
Nochmal ein paar Anmerkungen meinerseits:

@akl: Mit Cross-Compilern hab ich auch nicht unbedingt die besten Erfahrungen gemacht. Kann man schon nutzen, um auf dem lokalen Rechner zu Kompilieren. Das Binary sollte man dann aber am besten gleich auf dem freigegebenen Laufwerk des anderen Rechners speichern und auf jeden Fall dort ausführen. Die Tatsache, daß ein Compiler bestimmten Code für eine Zielplattform korrekt übersetzt bedeutet leider nicht zwangsläufig, daß die auch für andere Zielplattformen gilt.

Wenn jemand sowohl ein freigegebenes Laufwerk hat als auch Zugriff über eine Remote-Desktop-Lösung hat, läßt es sich auf keinem System verhindern, daß er zumindest einen Teil der Systemkomponenten kopiert. Ein teilweise Schutz sollte eigentlich auch unter AOS etc mittels MultiUserFileSystem möglich sein ?
Wenn jemand seinen Zugang mißbräuchlich zum Erstellen einer Raubkopie benutzt, so macht sich der Zugreifende eines Gesetzesverstoßes schuldig, nicht aber der Inhaber des Rechners, es sei denn, er duldet dies wissentlich. Darüber würde ich mir also nicht den Kopf zerbrechen.

Was das thema RemoteDektop-Lösungen angeht, so sieht es da auf "AMIGA" momentan so aus:
VNC: Client und Server vorhanden
RDP: nur Client vorhanden
CITRIX: weder Client noch Server vorhanden

VNC ist in der Tat die langsamste Lösung, aber schon benutzbar.

Das Problem bei grafischer Fernbedienung ist aber, daß große Datenmengen entstehen, die vom Rechner , auf dem der Server läuft, hochgeladen werden müssen. Die Internetanbieter offerieren zwar mittlerweile Downloadraten von bis zu 30 MBit/s, aber in die Gegenrichtung selten mehr als 2 MBit/s.
Man kann natürlich Auflösung und Farbtiefe reduzieren, um die Datenmenge zu reduzieren. Statt 1280 mal 1024 mal 32 nimmt man halt 800 x 600 x 16 bzw gar 8.

Letztens hatt ich mal die Möglichkeit, CITRIX über eine 64Kbit/s-Leitung zu testen. Trotz Auflösung von 1024 mal 768 mal 16 war das überraschend flott, zumindest solange man nicht bildschirmfüllende Fenster laufend durch die Gegend schiebt.


Wie man ein Remote einen abgestürzten Rechner wieder rebootet, was beim Entwicklen von Software eine nicht seltene Aktion ist, ist allerdings eine gute Frage. Die Guru Meditation des klassischen AmigaOS hatte den Vorteil, daß ein 10-Sekunden-Timeout eingebaut war, nach dem das System automatisch gebootet hat.


Daß VNC keine Amigatasten unterstützt, war mir bislang nicht bewußt. Muß ich heut gleich nochmal ausprobieren. Würde vermuten, daß AMiga- und Mactasten einfach als Windowstasten übermittelt werden. Aus dem Gedächtnis weiß ich's jetzt aber auch nicht.

[ - Antworten - Zitieren - Direktlink - ]

15.01.2008, 06:56 Uhr

dandy
Posts: 2552
Nutzer
Zitat:
Original von p-OS:
Nochmal ein paar Anmerkungen meinerseits:

...
Ein teilweise Schutz sollte eigentlich auch unter AOS etc mittels MultiUserFileSystem möglich sein ?
...


Also MUFS (Multiuser File System) hab ich für den Amiga - könnte ich also installieren...


--
Ciao,

Dandy

Wenn es jemandem Spaß macht, zu Marschmusik in Reih' und Glied zu marschieren, so verachte ich ihn schon.
Er hat sein Großhirn nur aus Versehen bekommen - bei ihm hätte auch schon das Rückenmark gereicht!
(Albert Einstein)

[ - Antworten - Zitieren - Direktlink - ]


-1- [ - Beitrag schreiben - ]


amiga-news.de Forum > Programmierung > Sharing von PPC-Amigas übers Web [ - Suche - Neue Beiträge - Registrieren - Login - ]


.
Impressum | Datenschutzerklärung | Netiquette | Werbung | Kontakt
Copyright © 1998-2022 by amiga-news.de - alle Rechte vorbehalten.
.