HIVE-Project

yeti hat geschrieben:

PIC18F2550 hat geschrieben:Wie währe es mit einer einlagerung im WIKI?
Hier währe auch platz für erläuterungen und Beispielen.

Erstmal 'n eigenen Thread für diese Diskussion...

OK yeti Hab ich soeben gemacht.
https://hive-project.de/wiki/sd-karte:sd_karte_01

Das WIKI ist so ziemlich zugeparkt mit verschiedenen dingen die auch schon auf der HIVE seite present sind.
Aber ein einfaches umräumen über das webinterface ist auch nicht so einfach.

PIC18F2550 hat geschrieben:Das WIKI ist so ziemlich zugeparkt mit verschiedenen dingen die auch schon auf der HIVE seite present sind.
Aber ein einfaches umräumen über das webinterface ist auch nicht so einfach.

Ich halte es für unadministrierbar, jedenfalls mit unseren Rechten und darüberhinaus ist unschmuck und veraltet.
Ich kann z.B. nicheinmal eigene Dateien löschen oder weiß nur nicht wie.
Unsere Hive-Weltnetschaukasten-Betreiber scheinen eh andersweitig im Dauerstreß und schauen nicht ins Wiki: Irgendwo ließ ich da vor langer Zeit schon die Frage fallen, wie man denn Uploads wieder gelöscht bekommt... muß Jaaahre her sein... Antwort? Nie!

Lieber wäre mir aber eine verteilte Lösung, denn sonst reicht ein einziger Kollaps und alle Arbeit ist verschwindet im digitalen schwarzen Loch...

Das erfordert meiner Meinung nach eine verteilte Lösung.

Andererseits bin ich vom verrotteten internationalen Propellerwiki, dem versandeten Anlauf Propellerdokumentation zu sammeln und bereitzustellen und einem vergleichbar erfolgslosen Anlauf dasselbe mit Software zu tun schon hinreichend vorgeschädigt und eigentlich durch und duch desillusioniert und frustriert.

Ich behaupte mal: Sowas funktioniert einfach nicht, schon gar nicht im Propeller-Universum!

***tief-lufthol...***

Hat jemand Ahnung von Fossil?
Kann man es komplett zu anderen Mitarbeitern clonen?
Samt seinem Wiki und File-Uploads?

Welch Softwarealternativen haben wir noch?

Git(Lab)? Rsync? SFTP? FTPS?

——————————

Ich hab mehrere Wikis und Versuche, Propellersoftware und -dokumentation zu archivieren und zu katalogisieren sterben sehen. Meistens schon in der Phase in denen sie diskutiert wurden...

...und das TransPONDerforum verliert bekanntlich ja auch ab und zu Inhalte und die Betreiber scheint's nicht zu scheren.

Da ist er wieder: Der galaktische Propeller-Blues.

Vielleicht wachen ja mal ein paar unserer Nachbarn auf und bringen ein paar gute Ideen mit?

Nu direkt kann mann nicht im wiki löschen, dazu verwende ich noch einen FTP Zugang.
Der Grund für das fehlen ist das alle alten Versionen bis zum nimmerleinstag aufgehoben werden sollen.
Das macht aus dem Server nur noch eine Schlaftablette.

Klonen kann man das WIKI ohne Probleme auf jeden anderen Server das einzige was kompliziert er ist, sind die Rechte zum bearbeiten.

Hast Du einen GitLab-Login?

Alle Sachen archivieren indem sie einfach je in ein eigenes Directory gesteckt werden und dazu kommt ein Textschnipsel in HTML oder BBCode?

Das wär von Zuhause aus per Git und durch den Browser per GitLabs WebIDE managebar und für jedes andere Backend könnten die Textschnipsel neben den Dateien auch umkonvertiert werden.
Das kommt mir recht flexibel vor und wenn GitLab es dann GitHub nachmacht und mit den Falschen knuddelt, sind unsere lokal gespeicherten Clones dieses Datenbestandes nahezu 100% vollständig. Issues brauchen wir ja nicht unbedingt für einen Dateienbunker und wie man Snippets lokal retten kann weiß ich auch noch nicht. Aber wie man GitHub-Repos und zugehörige Wikis clonen kann (die sind auch nur Repos mit ".wiki.git" am Ende) ist oft genug erpröbt. Nur diese beiden Komponenten benutzend wären unsere Daten also perfekt clonebar und somit jeder Attacke gewachsen.

<von-der-Leyen-Stimme> Reusability in anderem Kontext ist mir ganz ganz wichtich! </von-der-Leyen-Stimme>

...uuuuund wir würden uns mit Git beschäftigen, was bei reinen Code-Projekten auch äußerst nützlich ist.

...Fossil ist mit VCS, Wiki, Webserver, Issue-Tracker, Filebunker, ... ein kleiner aber nahezu vollständiger GitLab-Ersatz. Das Archiv damit bauen wäre machbar, aber die Welt "spricht" Git und sich mit Git beschäftigen halte ich für wichtiger und für besser anderswo recycelbares Wissen.

<Willi-Brandt-Stimme> Es wirrrd Zeit, mehrrr Git zu waaagen! </Willi-Brandt-Stimme>

Ein eigenes QuasiGitHub zuhause rennen lassen und öffentlich sichtbar halten mag ich wegen des Umfanges der Software nicht. Das kommt nicht ohne PHP und andere zuverlässig den Sicherheitsalptraum darstellende Komponenten aus. Für diesen öffentlichen Zuhause-Einsatz traue ich dann doch eher Fossil.

Sö... und nun haut mich um mit überraschenden anderen Ideen, die ich dann vielleicht sogar noch besserer find!

Aber auf Dokuwiki hab ich definitiv null Bock.

yeti hat geschrieben:Hast Du einen GitLab-Login?

Neeee hab ich nicht.

Es sollen ja nur Projekte oder Treiber gespeichert werden um diese der Nachwelt zu erhalten und nicht Ihre ganze Entwicklungsgeschichte.

Für fertige Treiber denke ich da eher an einen SFTP-Server die sind relativ einfach zu handhaben und der HIVE könnte auf diese Datenbank zugreifen.

Zugegeben das WIKI ist nicht ganz ohne und nicht jeder will sich damit herumschlagen.

PIC18F2550 hat geschrieben:

yeti hat geschrieben:Hast Du einen GitLab-Login?

Neeee hab ich nicht.

Es sollen ja nur Projekte oder Treiber gespeichert werden um diese der Nachwelt zu erhalten und nicht Ihre ganze Entwicklungsgeschichte.

Den Verlauf der Entwicklung der begleitenden Textschnipsel in einem VCS haben mag Vorteile haben. Archiv- und Binärfiles haben nicht viel gewonnen durch Git, aber Git wird zunehmend auch als Filesystem gesehen und da mal eben Teile oder Alles clonen können und dennoch den Überblick behalten hat auch seien Reiz.

PIC18F2550 hat geschrieben:Für fertige Treiber denke ich da eher an einen SFTP-Server die sind relativ einfach zu handhaben und der HIVE könnte auf diese Datenbank zugreifen.

SFTP-Server zum Warten, damit nicht wie bei klassichem FTP die Passwords im Klartext durch's Netz gepustet werden und für nur den Abruf FTP und HTTP erlauben (echt nur lesezugriff darüber) kann dem Hive das Leben einfacher machen. Das "S" in SFTP würde zu teuer für den Hive.

PIC18F2550 hat geschrieben:Zugegeben das WIKI ist nicht ganz ohne und nicht jeder will sich damit herumschlagen.

Ich hab's probiert. Das Hive-Wiki hat nie richtig Fahrt aufgenommen und man ist so damit einfach voll allein gelassen. Jeder hat das nach seinem Stil rumgemacht, es gab keine Absprachen zu Stil und Struktur und auch ansonsten keinerlei Kooperation. Wiki geht anders! Aber mit dem Thema bin ich nu' durch. Es gibt genug andere Baustellen und ich langweile mich auch ohne dies Wiki wahrlich nicht.

Es sind nur das PDF und die letzte Version.
In der Zip ist nur eine ältere Version.
Die Namenserweiterung mache ich schon immer damit ich weis wozu die Datei gehört.

PIC18F2550 hat geschrieben:Es sind nur das PDF und die letzte Version.
In der Zip ist nur eine ältere Version.
Die Namenserweiterung mache ich schon immer damit ich weis wozu die Datei gehört.

...aber die alten Versionen passen vermutlich exakt zur Doku, während das bei der neueren Version nur noch zu ungefähr 87,2587662% der Fall sein wird.

https://www.youtube.com/watch?v=d_8X-wBKEUI

Ich bin in solchen Fällen k(r)ampfhafter Alles-Zusammenhalter und würde auch jede verfügbare alte Version einlagern. Hab wohl ein paar hyperaktive Bibliothekar-Gene im Stammbaum abbekommen.

Das ZIP hab ich eben nachgeliefert, aber Du kannst es ja wieder rauskicken.
Es ist Dein Wiki.
Ich halte mich in Zukunft wieder konsequent raus.

Nee werd ich nicht rauskicken.
Das ist auch nicht mein WIKI.
Binn für Verbesserungen immer zu haben.

(Die Daten sind auf dem OBEX Server leider nicht mehr vorhanden)

ÖÖÖööö... die neue Version ist in der OBEX vorhanden.

Das was ich mit "zeigt ins digitale Nirwana meinte" war der Link auf die AppNote-006, was durch PDF und ZIP nun komplett im Wiki neben der aktelleren OBEX-Version liegt:

Die heilige Kirche von Parallax hat geschrieben:Please vist http://www.parallaxsemiconductor.com/an006 for more info.

Parallax hat die Site "parallaxsemiconductor.com" aufgegeben und offensichtlich nicht mal schnell einen Suchbot über die Beschreibungen in der OBEX laufen lassen, wo denn da Links geradezubiegen sind. Fürsorglich wie immer... ...man kennt das ja von ihnen.