atari-home.de - Foren
Software => Coding => Thema gestartet von: Mado am Mo 13.06.2022, 07:31:12
-
Ich habe den Castaway Atari ST Emulator, an dem ich vor ca. 20 Jahren aufgehört hatte zu programmieren, jetzt wieder mal ein bisschen upgedatet.
- Lauffähig machen auf 64-Bit Systemen
- Verwendung von <stdint.h> Datentypen, Eliminieren von "unsigned long" etc.
- Nutzung von durch den Preprozessor bereitgestellte Endianess-Erkennung (je nach Ziel-Prozessor)
- Fixen von Compilerfehlern und Warnungen
- Allgemeines Code-Aufräumen
Ich weiß nicht, ob ich in der Lage bin, wesentliche Atari-ST-Funktionalitäten zu ergänzen. Es fehlt ne Menge. Ich möchte auch gerne die ganzen Native Features einbringen. Momentan crash TOS 1.04 und EmuTOS läuft, aber Sysinfo crasht z.B.
Im Großen und Ganzen ist der m68k-Kern recht flott, wenn auch ohne Jit. Momentan wird nur der 68000er unterstützt. Ich finde es aber trotzdem gut, einen weiterne Prozessor-Emulator zu haben.
Jetzt überlege ich, den Emulator auf ein Git zu bringen. Damals auf Sourceforge war das CVS. Gibt es von euch eine Empfehlung für etwas besseres als Github? Ich möchte den Code noch etwas cleaner machen, bevor ich ihn hochlade.
Link
http://castaway.sourceforge.net/
-
...Damals auf Sourceforge war das CVS. Gibt es von euch eine Empfehlung für etwas besseres als Github? ...
Github ist mit Sicherheit die größte und prominenteste Plattform. Allerdings gehört die eben Microsoft.
Wer sich daran stört, kann auf gitlab ausweichen (sollte aber nicht glauben, dass das - nur weil's nicht Microsoft gehört - ein weniger gewinnorientiertes Unternehmen wäre).
Ansonsten ist git (im Gegensatz zu den meisten anderen VCS-Systemen) so gestaltet, dass zwischen "Server" und "Client" kein Unterschied besteht, d.h. ein git-Repository sieht auf dem Server genauso aus wie auf deinem Rechner zuhause. Man kann deshalb ein git-Repository mit Bordmitteln problemlos überall dort hinlegen, wo ein Zugang über die unterstützten Protokolle besteht (muss dann allerdings die Benutzerverwaltung selbst organisieren und auf die GUI-Unterstützung von git{hub|lab} verzichten).
-
GitLab ist OpenSource und kann auch selbst gehosted werden. Da hat man dann auch eine GUI. Wenn jemand seine Software für die Nachwelt erhalten möchte ist ein gehosteter Service höchstwahrscheinlich sinnvoller.
P.S.: Wer weiss, ob der VzEkC e.V. einen Gitlab-Host betreibt? Das wäre doch ein guter Ort.
-
P.S.: Wer weiss, ob der VzEkC e.V. einen Gitlab-Host betreibt? Das wäre doch ein guter Ort.
Bisher nicht… aber die Idee hat einen gewissen Reiz.
-
Ja, sowas fänd ich toll. Weil zu alten Rechnern ja auch die Software gehört. Ich kann ohne Probleme Github verwenden, aber viel schöner fänd ich es, wenn es eine von einem Verein betriebene Git-Plattform gäbe. Also explizit nicht eine von einer einzelnen Person betriebene. Dann kann ich es auch selber machen.
Ich bin selber auch vereinsvorstand und könnte sowas auch aufsetzen, allerdings ist in meinem Verein momentan wenig Bewegung. Es wäre besser, wenn sowas mit dem Fokus auf Retrocomputing geschehen würde.
-
Lediglich einen Git Server aufzusetzen dürfte vermutlich nicht so schwierig sein. Das interessante an Github ist aber die Integration mit CI Services (Travis etc, oder auch einfach Github Actions). Sowas selber zu managen dürfte nicht unerhebliche Arbeit sein.
-
GitLab ist OpenSource und kann auch selbst gehosted werden. Da hat man dann auch eine GUI. Wenn jemand seine Software für die Nachwelt erhalten möchte ist ein gehosteter Service höchstwahrscheinlich sinnvoller.
P.S.: Wer weiss, ob der VzEkC e.V. einen Gitlab-Host betreibt? Das wäre doch ein guter Ort.
Wer nicht ganz so hohe Ansprüche an eine GUI hat: Gitea (https://gitea.io/en-us/).
-
Wenn man sich etwas umschaut, gibt es noch einige nicht-kommerzielle Alternativen zu Github:
- https://www.tuxfamily.org/en/about
- https://gitlab.freedesktop.org
- https://salsa.debian.org/
- http://savannah.nongnu.org/
-
Gogs ist auch gut als minimale Alternative mit GitHub ähnlicher UI :-)
https://gogs.io/
-
Ich habe in meiner - ziemlich langen - Atari-Zeit mehrfach erlebt, dass man sich auf "Atari-spezialisierte" Webangebote - auch wenn sie jahrelang wie Fels in Brandung jeweils eine Institution waren (s. Atariforge, freemint.de, ...) - leider nicht dauerhaft verlassen kann.
Ich würde meinen Quellcode lieber nicht auf Dauer solchen - auch mit viel Enthusiasmus - privat gehosteten Services anvertrauen. Das Leben verläuft halt oft doch nicht so, wie man sich das denkt.
-
Das sieht bei kommerziellen Angeboten (siehe Travis und bintray) aber auch nicht besser aus. Man muss halt damit rechnen, daß man sich alle paar Jahre nach Alternativen umschauen muss.
-
Ja, wahrscheinlich ist es so ...
-
Wer sich daran stört, kann auf gitlab ausweichen (sollte aber nicht glauben, dass das - nur weil's nicht Microsoft gehört - ein weniger gewinnorientiertes Unternehmen wäre).
Weil es so gut passt:
GitLab plans to automatically delete projects if they've been inactive for a year and are owned by users of its free tier.
The Register has learned that such projects account for up to a quarter of GitLab's hosting costs, and that the auto-deletion of projects could save the cloudy coding collaboration service up to $1 million a year. The policy has therefore been suggested to help GitLab's finances remain sustainable.
=> Für Langzeitablage ungeeignet. Betrifft Projekte auf gitlab.com und natürlich nicht, wenn man GitLabs Software auf seinem eigenen Server laufen lässt.
-
Hm. Müsste man glatt mal schauen obs bei github nicht sowas ähnliches gibt. Fragt sich natürlich auch was genau die unter "inaktiv" verstehen.
BTW, das dürfte ua. auch die MagicMac Sourcen betreffen.
-
Hm. Müsste man glatt mal schauen obs bei github nicht sowas ähnliches gibt.
Zur Zeit nicht. Auch wenn es die Free-Software-Freunde stört: Es hat auch Vorteile, dass GitHub zu Microsoft gehört. GitLab muss mit GitLab als Software (egal ob bei ihnen gehostet oder an andere lizenziert) ordentlich Geld verdienen, sonst sind die Aktionäre unglücklich und irgendwann ginge die Firma pleite. Microsoft ist viel breiter aufgestellt und kann aus GitHub entsprechend auch Vorteile ziehen, die nicht direkt aus Geld bestehen.
BTW, das dürfte ua. auch die MagicMac Sourcen betreffen.
Ein großer Vorteil eines verteilten Versionskontrolllsystems wie git ist, dass es genügt, wenn es eine Person gibt, die ein git clone gemacht hat, um die komplette Git-Historie eines Projekts zu erhalten; selbst wenn es von der Hostingseite gelöscht wird. Okay, Dinge wie Issues, Wiki, PRs sind dann natürlich weg (weshalb man wichtige Informationen zu einem Commit auch immer in die Commit-Beschreibung schreibt und nicht nur in den PR).
-
Na, das ging ja schnell. Gitlab hat wohl den Gegenwind unterschätzt. https://www.theregister.com/2022/08/05/gitlab_reverses_deletion_policy/
-
Vermutlich hätten sie sich damit auch selber ins Knie geschossen, wenn die user dann zu anderen Plattformen abgewandert wären.