So muss sich ein Neuling der sich etwas selbst schreibt und es weil es so gut funktioniert vielen anderen zur Verfügung stellen will auch noch mit Versionsverwaltungssystemen herumschlagen.
Die momentane Situation stellt ein Problem dar, die von viel zu vielen viel zu lange ignoriert worden ist - hier ist ein Lösungsvorschlag (und kein schlechter wie ich finde; eigentlich sollte man nur mit beglaubigten Zertifikaten signierte Beiträge akzeptieren (dann könnte ich Deinen Einwand jedoch etwas verstehen)). Was wäre denn Deiner Meinung nach eine bessere Lösung des Problems? Wer eine Erweiterung für ein Stück Software schreibt, wird es ja wohl gerade noch schaffen, sich mit einem Versionsverwaltungswerkzeug "auseinanderzusetzen", schließlich gibt es auch Webschnittstellen (Du musst ja keinen eigenen Server aufsetzen).
auch eine versionsverwaltung hilft da nichts und wer soll den berg arbeit übernehmen die vielen hobbyskripte zu sichten?
das problem hat man doch auch bei jeder distribution, sobald man etwas ausserhalb der offiziellen quellen braucht muss man in den sauren apfel beissen und fremde repos einbinden. sicher kann man auch verzichten, nur ist das nicht immer möglich.
das leben ist eben voller risiken, typischer ruf aus der vollkasko gesellschaft.
Von Aron Homberg am Sa, 19. Dezember 2009 um 15:08 #
Wie wär es mit heuristischen Erkennungsmustern für verschiedene Sprachen. Beim commit wird ein post-commit Hook aufgerufen welcher für die gegebene Sprache den Quellcode nach typisch kritischen funktions/methodenaufrufen scannt. Z.b "shell_exec". Nun wird auf Basis der heuristischen Treffer eine Gefahrengewichtung errechnet. Übersteigt die Gewichtung einen Grenzwert, wird der Maintainer per E-Mail bzw die Reviewer des Projekts informiert. Der commit wird zurückgehalten, bis ein Reviewer zustimmt. Der Autor wird darüber ebenfalls informiert.
Wer ein nützliches Script, Plugin, Programm oder Datensammlung verfasst wird auch direkt mit Dolphin oder Konqueror via SVN-Schnittstelle grafisch die Daten auf den zentralen Server ins SVN hochladen können (er müsste höchstens evtl. das KIO-Plugin für SVN installieren). Und wenn er es ganz dekadent möchte kann er das Ganze auch direkt vom Server in sagen wir mal Kate oder KDevelop editieren und einfach auf speichern klicken... KIO -seit KDE 2.0- sei dank. :-)
Nix Kommandozeile, nix neues Tool lernen. :-)
Diese doch sehr kleine Hürde ist auch vollkommen beabsichtigt, siehe Kretschmanns Punkt zu "Crapware".
Von Bernd 2010 am Di, 15. Dezember 2009 um 21:09 #
Sehe ich auch so. Der geringe zusätzliche Aufwand bringt meiner Meinung nach wesentlich mehr Vorteile als Nachteile mit sich. Das signieren könnte man ja als letzte Stufe noch oben draufsetzen. Das geht mir Secure Get Hot New Stuff sogar ganz transparent ohne viel Aufwand.
Von vicbrother am Mi, 16. Dezember 2009 um 15:08 #
Man könnte auch einen Incoming-Bereich aufmachen wo ungeprüfte Dateien landen die dann bes. gekennzeichnet werden bis einige Benutzer diese reviewt haben. Das würde die Versionsverwaltungsproblematik entspannen.
Schon mal mit ein Versionsverwaltungssystem gearbeitet? Der Mehraufwand ist in weniger als einer Stunde gegessen, und spart danach unter Umständen das x-fache an Zeit.
Von Hans W. urst am Mi, 16. Dezember 2009 um 14:23 #
Ja - aber das steht nur auf der verlinkten Seite, die ich zugegebener maßen erst nach meinem Post gelesen habe. Da Amarok selbst aber auf git aufsetzt liegt der Verdacht schon nahe, oder?
Aber meine Aussage war auch eher generell gemünzt. Git hab ich nur genannt, da amarok das eben verwendet (und ich es auch ein klein wenig kenne).
Mal qgit probiert? Und ansonsten stellt sich mir die Frage, was an "git checkout", "git commit", "git add" usw. anders sein soll als bei seinen Subversion-Pendants. Nur weil git mehr kann muss das nicht heissen, dass man damit zwingend auch komplexere Dinge tun muss.
Ich glaube eher, dass Du keine Ahnung hast, bzw. nicht in der Lage bist, Aussagen nachzuvollziehen. Aber schlüsseln wir es für Dich noch einmal auf:
"git checkout" und "svn checkout" checken jeweils einen Branch aus dem Repository aus
"git commit" und "svn commit" schieben lokale Änderungen in das Repository (mit dem Unterschied, dass man bei "git commit" ein explizites "-a" angeben muss, um den gesamten Working Tree zu berücksichtigen)
"git add" und "svn add" fügen lokale Files dem Index hinzu
Das Git und Subversion andere Ansätze bei der Verteilung von Repositories verfolgen ist klar, spielt für die Aussage, die ich treffen wollte, dass die "täglichen Befehle" für einfache Arbeitsabläufe, die sich in der Regel auf wenig mehr Befehle als die oben genannten beschränken, identisch sind, keinerlei Rolle.
Von Hans W. urst am Mi, 16. Dezember 2009 um 14:30 #
Ja, habe ich. Meist um die Änderungen bei einem bestimmten Projekt zu verfolgen.
Git ist fundamental anders als Subversion und die genannten Kommandos wirken auch auf eine komplett andere Weise. Wenn würde ich sagen, dass die Mercurial Kommandos noch am ehesten mit svn Kommandos gleichzusetzen sind.
> Git ist fundamental anders als Subversion Das bestreitet niemand.
> die genannten Kommandos wirken auch auf eine komplett andere Weise Wenn Du mit git lediglich einen SVN-Workflow nachbilden willst, dann machen sie bei git genau das, was sie bei SVN machen würden. Das von einem "git commit" kein Changeset auf einem externen Repository landet bestreitet ebenfalls niemand. Es landet eben im der Working Copy zugeordneten Repository, konsequenterweise also dem lokalen Clone.
Von vicbrother am Di, 15. Dezember 2009 um 21:44 #
Nein, das ist falsch. Du kannst auch weiterhin auf deiner Seite Skripte etc zur Verfügung stellen, nur der Download über das GHNS soll halt geprüft sein. Wer deiner Webseite also vertraut kann nach wie vor dein Skript einsetzen.
Was hat gute Software (in Form von es stellt eine stabile Funktion bereit unabhängig davon wie der Code aussieht) mit keine Ahnung (vermutlich bezogen auf ein Versionsverwaltungssystem) zu tun.
Unabhängig davon, rauchen dürfte für Dich offenbar noch gesetzlich verboten sein
Naja, jemand, der es schafft sich a) die Doku zu Amarok-Erweiterungen zu besorgen, b) eine Erweiterung zu schreiben, sich c) durch eine eventuell auftretende Abhängigkeitshölle zu kämpfen und dann d) das Teil noch fertig zu kompilieren, dem ist wohl auch zuzutrauen, dass er eine Versionsverwaltung elementar bedienen kann.
Von Christopher Roy Bratusek am Di, 15. Dezember 2009 um 20:05 #
GPL würde ja bedeuten, dass ich mir deinen VW Amarok nehmen und fahren darf. Den muss ich dann aber wieder zurück geben. Da bevorzuge ich doch BSDL. Ich nehm' mir deins und sag' es wäre meins.
Von Christopher Roy Bratusek am Di, 15. Dezember 2009 um 21:42 #
Von mir? Dann läuft da aber nur Techno. Rock auf Ausnahmebasis, der Rest ist ausgeschlossen. HipHop steht unter Strafe. Ansonsten musst du dir selbst was einbauen.
Wasn das fürn Techno Event? Auf Masse-Mainstream-Marusha-Kinder-Verkleidungs-sehen-und-gesehen-werden-Proleten Party? *utz utz utz Kümmelrave ? *LOL* Also Techno ist was anderes^^
Jeder registrierte Benutzer kann auf solchen und ähnlichen Seiten Malware-Pakete hinterlegen - da seine Identität nicht weiter geprüft wird, muss er sich um Konsequenzen kaum Gedanken machen.
Und warum überprüft man dann nicht vorher die Identität des Benutzers? - Ich meine: Ein Forum z.B. ist die eine Sache aber so wichtige Zugangsrechte, wo man so viel Mist bauen kann, das ist schon etwas anderes.
Vor Jahren mußte ich mich sogar bei web.de noch mit meiner Ausweiskopie identifizieren, nur um ein Postfach zu erhalten. - Gut. das ist zwar wirklich nun schon ewig her und wird auch schon lange nicht mehr gemacht aber grundsätzlich war sowas doch eine sehr gute Idee.
Mit einem generischem Apparmor Profil für solche "Erweiterungs-Skripte" sollte die Sache doch eigentlich gegessen sein. Insofern gibt es für diese Art von Probleme schon lange ein Lösung. --Nur muss die Lösung auch angewendet werden.
Ein "UserApparmour" wäre sicher auch eine nette Idee. - Ein Programm das der User in seinem Homeverzeichnis Startet hat doch sicher nicht "wild" im Homeverzeichnis rum zu löschen. - ...
Von Flying Circus am Mi, 16. Dezember 2009 um 15:51 #
Deine Lösung setzt bei den Symptomen an. Die vorgeschlagene bei der Ursache.
Mal abgsehen davon, daß es auch durchaus eklig werden kann, wenn Schadsoftware in /home Amok läuft. Nicht jeder kennt das Konzept von "Backups", gar regelmäßigen solchen.
>Deine Lösung setzt bei den Symptomen an. Die vorgeschlagene bei der Ursache. Mal abgsehen davon, daß es auch durchaus eklig werden kann, wenn Schadsoftware in /home Amok läuft. Nicht jeder kennt das Konzept von "Backups", gar regelmäßigen solchen.;-)
Du hast die "vorgeschlagene" Lösung scheinbar nicht verstanden. Sie erschwert nur, unterbindet aber nicht, ist also keine "Lösung" sondern nur ein Teil der Lösung.
PS: Dein vorschlag "Backups" setzt auch "nur" an dem Sysmptom an. :O
Was wäre denn Deiner Meinung nach eine bessere Lösung des Problems?
Wer eine Erweiterung für ein Stück Software schreibt, wird es ja wohl gerade noch schaffen, sich mit einem Versionsverwaltungswerkzeug "auseinanderzusetzen", schließlich gibt es auch Webschnittstellen (Du musst ja keinen eigenen Server aufsetzen).
das problem hat man doch auch bei jeder distribution, sobald man etwas ausserhalb der offiziellen quellen braucht muss man in den sauren apfel beissen und fremde repos einbinden. sicher kann man auch verzichten, nur ist das nicht immer möglich.
das leben ist eben voller risiken, typischer ruf aus der vollkasko gesellschaft.
LG,
Aron
Nix Kommandozeile, nix neues Tool lernen. :-)
Diese doch sehr kleine Hürde ist auch vollkommen beabsichtigt, siehe Kretschmanns Punkt zu "Crapware".
Ansonsten dauert es nicht lange und Linux hat im Hinblick auf "Malware" einen genauso schlechten Ruf weg wie Windows.
Aber meine Aussage war auch eher generell gemünzt. Git hab ich nur genannt, da amarok das eben verwendet (und ich es auch ein klein wenig kenne).
lg
Erik
lg
Erik
Das Git und Subversion andere Ansätze bei der Verteilung von Repositories verfolgen ist klar, spielt für die Aussage, die ich treffen wollte, dass die "täglichen Befehle" für einfache Arbeitsabläufe, die sich in der Regel auf wenig mehr Befehle als die oben genannten beschränken, identisch sind, keinerlei Rolle.
lg
Erik
Git ist fundamental anders als Subversion und die genannten Kommandos wirken auch auf eine komplett andere Weise. Wenn würde ich sagen, dass die Mercurial Kommandos noch am ehesten mit svn Kommandos gleichzusetzen sind.
Das bestreitet niemand.
> die genannten Kommandos wirken auch auf eine komplett andere Weise
Wenn Du mit git lediglich einen SVN-Workflow nachbilden willst, dann machen sie bei git genau das, was sie bei SVN machen würden. Das von einem "git commit" kein Changeset auf einem externen Repository landet bestreitet ebenfalls niemand. Es landet eben im der Working Copy zugeordneten Repository, konsequenterweise also dem lokalen Clone.
lg
Erik
Unabhängig davon, rauchen dürfte für Dich offenbar noch gesetzlich verboten sein
Viel Spaß darin, alles kaputt. ;P
lg
Erik
Das darf ja auch gar nicht mehr sein, siehe Link.
lg
Erik
lg
Erik
Und warum überprüft man dann nicht vorher die Identität des Benutzers? - Ich meine: Ein Forum z.B. ist die eine Sache aber so wichtige Zugangsrechte, wo man so viel Mist bauen kann, das ist schon etwas anderes.
Vor Jahren mußte ich mich sogar bei web.de noch mit meiner Ausweiskopie identifizieren, nur um ein Postfach zu erhalten. - Gut. das ist zwar wirklich nun schon ewig her und wird auch schon lange nicht mehr gemacht aber grundsätzlich war sowas doch eine sehr gute Idee.
Sebalin.
Darum gehts ja...
Ein "UserApparmour" wäre sicher auch eine nette Idee.
- Ein Programm das der User in seinem Homeverzeichnis Startet hat doch sicher nicht "wild" im Homeverzeichnis rum zu löschen.
- ...
Die vorgeschlagene bei der Ursache.
Mal abgsehen davon, daß es auch durchaus eklig werden kann, wenn Schadsoftware in /home Amok läuft. Nicht jeder kennt das Konzept von "Backups", gar regelmäßigen solchen.
Die vorgeschlagene bei der Ursache.
Mal abgsehen davon, daß es auch durchaus eklig werden kann, wenn Schadsoftware in /home Amok läuft. Nicht jeder kennt das Konzept von "Backups", gar regelmäßigen solchen.;-)
Du hast die "vorgeschlagene" Lösung scheinbar nicht verstanden. Sie erschwert nur, unterbindet aber nicht, ist also keine "Lösung" sondern nur ein Teil der Lösung.
PS: Dein vorschlag "Backups" setzt auch "nur" an dem Sysmptom an. :O