staging.inyokaproject.org

Ich schlage vor den von mir verfassten Artikel "Communtu" ins Wiki zu verschieben.

Er beschreibt das Communtu-Projekt, ein Projekt das sich zum Ziel gesetzt hat dem Benutzer die Installation von aus rechtlichen oder anderen Gründen nicht auf der InstallationsCD befindlichen Programm-, Bibliotheks-, Codec-, und anderen Paketen zu erleichtern. Das Projekt eignet sich so besonders für Newbies und alle die, die eigene Metappakete zusammenstellen und diese anderen zur Verfügung stellen wollen.

vgl. http://forum.ubuntuusers.de/topic/communtu-gemeinsam-ubuntu-linux-an-individuel/

Bernd vom Communtu-Projekt

für mich klingt der Artikel wie eine Neuauflage von Automatix (automatisches anpassen der sources.list, automatische Installation von Paketen). Daher von mir ein dickes -1 gegen die Aufnahme ins Wiki.

Ohne Anmeldung kann ich mir nicht anschauen, was dieses "Installations" Skript so alles anstellt und daher fürchte ich, dass dieser Artikel unsere Nutzer gefährdet.

martingr schrieb:

für mich klingt der Artikel wie eine Neuauflage von Automatix (automatisches anpassen der sources.list, automatische Installation von Paketen). Daher von mir ein dickes -1 gegen die Aufnahme ins Wiki.

Ohne Anmeldung kann ich mir nicht anschauen, was dieses "Installations" Skript so alles anstellt und daher fürchte ich, dass dieser Artikel unsere Nutzer gefährdet.

Hallo,

doch kannst Du anschauen, dort gibt es einen Punkt auf der Startseite der "nutze Communtu anonym" heißt. Den kannst Du einfach nutzen.

Nein, dass ist keine Neuauflage von Automatix. Es wird auf die Wünsche der Nutzer Rücksicht genommen, ob diese ausschließlich freie oder auch unfreie Software haben wollen.

Gruß

Torsten

Nein!

1. warum muss ich meine Daten preisgeben (Anmeldung)? Warum gibt es verschiedene Möglichkeiten sich dort zu beteiligen?

Klicke auf Registrierung, um einen neuen Benutzer anzulegen, oder melde dich an, oder nutze Communtu anonym.

Das ist mir persönlich sehr suspekt.

2. Jeder, der sich entscheidet, Ubuntu als Betriebssystem zu installieren, sollte sich im Klaren sein, dass es hier und da Nacharbeiten gibt.

Grüße aus Bonn

Klaus

der_Beueler schrieb:

1. warum muss ich meine Daten preisgeben (Anmeldung)? Warum gibt es verschiedene Möglichkeiten sich dort zu beteiligen?

Hallo,

der Nutzer/die Nutzerin hat bei einer Anmeldung die Möglichkeit die eigene Installation zu pflegen und somit das eigene Metapaket gesichert im Netz verfügbar zu haben. Die anonyme Nutzung haben wir wieder implementiert, da dies viele Nutzer in Chemnitz auf den Linuxtag wollten (sowohl im Vortrag als auch beim Stand hatten es welche angemerkt).

2. Jeder, der sich entscheidet, Ubuntu als Betriebssystem zu installieren, sollte sich im Klaren sein, dass es hier und da Nacharbeiten gibt.

Ja und genau dort wollen wir den Einsteiger auch helfen.

Grüße aus Bonn

Klaus

Grüße aus Bremen

Torsten

toddyhb schrieb:

Nein, dass ist keine Neuauflage von Automatix. Es wird auf die Wünsche der Nutzer Rücksicht genommen, ob diese ausschließlich freie oder auch unfreie Software haben wollen.

Doch, das ist Automatix Reloaded. Erst werden ein paar neue Quellen eingetragen und dann ein Haufen Pakete installiert. Dass man eine bestimmte Vorauswahl bzgl. der Quellen treffen kann, ändert daran nichts, vor allem weil gerade Neueinsteiger überhaupt nicht in der Lage sind, eine qualifizierte Entscheidung darüber zu treffen.

Wenn man solche Quellen wie Backports oder Fremdquellen einsetzt, kann es früher oder später passieren, dass man eine negative Überraschung erlebt, weil dort z.B. auf einmal fehlerbehaftete neue Versionen von Software auftauchen, mit denen man gar nicht gerechnet hat.

Die Idee an sich, quasi einen Community-Fundus sinnvoller Metapakete bereitzustellen, finde ich eigentlich gar nicht schlecht. Und dass man für die eine oder andere Software Fremdquellen benötigt, ist auch klar. Ich hätte aber weitaus weniger Bedenken gegen dieses Projekt, wenn es ein konsequentes Apt-Pinning implementieren würde, so dass Nicht-Standardquellen (und die Backports gehören für mich dazu) wirklich nur für die ausgewählten Pakete benutzt werden, für die man sie in die sources.list einträgt.

Das automatische Eintragen der Apt-Key-Schlüssel ist mMn auch noch nicht optimal. Ich weiß, dass das im Wiki bei jeder Fremdquelle auch so beschrieben wird, mit dieser wget-Zeile, aber im Grunde genommen könnte jemand der die Quelle manipuliert auch den GPG-Schlüssel manipulieren, der vom selben Server bezogen wird. Es wäre daher vielleicht ein Sicherheitsmehrwert, wenn Communtu die Fingerprints der Schlüssel beinhalten und die jeweiligen Schlüssel nur bei Übereinstimmung installieren würde.

Außerdem sollte auf der Webseite klar dokumentiert werden, welches Paket aus welcher Quelle bezogen wird, und warum, so dass man sich nicht erst das Skript zusammenstellen und analysieren muss.

otzenpunk schrieb:

toddyhb schrieb: Die Idee an sich, quasi einen Community-Fundus sinnvoller Metapakete bereitzustellen, finde ich eigentlich gar nicht schlecht. Und dass man für die eine oder andere Software Fremdquellen benötigt, ist auch klar. Ich hätte aber weitaus weniger Bedenken gegen dieses Projekt, wenn es ein konsequentes Apt-Pinning implementieren würde, so dass Nicht-Standardquellen (und die Backports gehören für mich dazu) wirklich nur für die ausgewählten Pakete benutzt werden, für die man sie in die sources.list einträgt.

Das ist aber der Fall. Es werden nur die Quellen eingetragen, die für die ausgewählten Pakete nötig sind, bei entsprechender Auswahl also auch gar keine.

Das automatische Eintragen der Apt-Key-Schlüssel ist mMn auch noch nicht optimal. Ich weiß, dass das im Wiki bei jeder Fremdquelle auch so beschrieben wird, mit dieser wget-Zeile, aber im Grunde genommen könnte jemand der die Quelle manipuliert auch den GPG-Schlüssel manipulieren, der vom selben Server bezogen wird. Es wäre daher vielleicht ein Sicherheitsmehrwert, wenn Communtu die Fingerprints der Schlüssel beinhalten und die jeweiligen Schlüssel nur bei Übereinstimmung installieren würde.

Die neue Konzeption ist ja die Installation über Metapakete, nicht über das Skript. Die Metapakete werden wir auch noch signieren, so dass dann nicht mehr manipuliert werden kann.

Außerdem sollte auf der Webseite klar dokumentiert werden, welches Paket aus welcher Quelle bezogen wird, und warum, so dass man sich nicht erst das Skript zusammenstellen und analysieren muss.

OK, das können wir gerne machen. Bisher kann man schon jedes einzelne Paket auf seiner Webseite nachgucken, aus welchen Quellen es verfügbar ist. Verstehe ich dich richtig, dass du vorschlägst, dass vor der Installation das nochmal zusammenfassend aufgelistet wird?

Gruß Till

also solange ihr die Installation über Skript macht, kommt dieser Artikel nicht ins Wiki.

Ich hab mir das Skript angeschaut und für Kubuntu heruntergeladen. Erste Zeile

gksudo echo

An der Stelle bricht das dann schon ab, weil gksudo nicht in Kubuntu installiert ist.

Das gleiche gilt für zenity.

Zu der Paketzusammenstellung und Bearbeitung der Quellen schreib ich jetzt nichts. Dazu wurde schon genug in Bezug auf automatix gesagt.

Hallo,

martingr und otzenpunk +1

Abgesehen davon ist zumindest mir nach dem Lesen des Artikels nichts klar, warum man Communtu eigentlich einsetzten soll. Was kann Communtu, was man nicht auch so über die Paketverwaltung machen kann?

Vom Schreibstil her ist der Artikel außerdem ähnlich einer Werbebroschüre (für Communtu 😉 ).

Gruß, noisefloor

Hallo Noisefloor,

Abgesehen davon ist zumindest mir nach dem Lesen des Artikels nichts klar, warum man Communtu eigentlich einsetzten soll. Was kann Communtu, was man nicht auch so über die Paketverwaltung machen kann?

Für die versierten Ubuntu-Nutzer bringt Communtu vermutlich nichts Neues. Aber für Einsteiger ist es schon hilfreich, Vorschläge zu bekommen und eine Nachinstallation durchzuführen, ohne sich erst lange durch Wikiseiten und Foren zu wühlen. Nach unserer Erfahrung aus der Face-to-face-Beratungspraxis (die nochmal was anderes ist als die Foren!) senkt das die Hemmschwelle, Ubuntu zu nutzen. Andere Nutzer finden die Möglichkeit interessant, eigene Metapakete per Mausklick bauen zu können. Auf dem Chemnitzer Linuxtag gab es zumindest fast durchgehend positives Feedback.

Vom Schreibstil her ist der Artikel außerdem ähnlich einer Werbebroschüre (für Communtu 😉 ).

Wir haben schon versucht, diese Tendenz in dem Artikel abzuschwächen, könnten das aber natürlich auch noch deutlicher tun.

Gruß Till

tillmo schrieb:

Hallo Noisefloor,

Abgesehen davon ist zumindest mir nach dem Lesen des Artikels nichts klar, warum man Communtu eigentlich einsetzten soll. Was kann Communtu, was man nicht auch so über die Paketverwaltung machen kann?

Für die versierten Ubuntu-Nutzer bringt Communtu vermutlich nichts Neues. Aber für Einsteiger ist es schon hilfreich, Vorschläge zu bekommen und eine Nachinstallation durchzuführen, ohne sich erst lange durch Wikiseiten und Foren zu wühlen. Nach unserer Erfahrung aus der Face-to-face-Beratungspraxis (die nochmal was anderes ist als die Foren!) senkt das die Hemmschwelle, Ubuntu zu nutzen. Andere Nutzer finden die Möglichkeit interessant, eigene Metapakete per Mausklick bauen zu können. Auf dem Chemnitzer Linuxtag gab es zumindest fast durchgehend positives Feedback.

Für Einsteiger ist aber euer Skript auch nicht geeignet. Abgesehen davon ist ein "magisches" Skript wunderbar wenn es dann ans Supporten geht. Wenn irgendetwas nicht funktioniert kommen die Leute ins Forum mit "Ich hab da was installiert und jetzt geht nichts mehr?" und wenn man sie dann fragt, was sie genau installiert haben, kommt dann als Antwort "Keine Ahnung. war so ein Skript dass ich aus dem Internet heruntergeladen habe".

Mit den Metapaketen wird das besser, aber ist immer noch sehr suboptimal. Wie deinstalliere ich die Pakete wieder? Deinstalliere ich eines, wird das Metapaket auch deinstalliert und keine Chance mehr, den Rest einfach loszuwerden. Alles Probleme, die es auch mit automatix gab.

Ganz ehrlich: wenn irgendjemand mit einem Problem ins KDE Forum kommt, weil er euer Skript oder Metapaket verwendet hat, wäre meine Reaktion "Selber Schuld" und ich würde keinen Support geben. Wenn das bei uns dann aber im Wiki empfohlen wird, haben die Supporter ein Problem.

Es gibt das Metapaket ubuntu-restricted-extras - damit hat man schon fast alles als Normalnutzer erschlagen.

Dann gibt es noch Medibuntu, mit dem man den Rest erschlägt.

Ergo: Communtu -1

tillmo schrieb:

otzenpunk schrieb:

Ich hätte aber weitaus weniger Bedenken gegen dieses Projekt, wenn es ein konsequentes Apt-Pinning implementieren würde, so dass Nicht-Standardquellen (und die Backports gehören für mich dazu) wirklich nur für die ausgewählten Pakete benutzt werden, für die man sie in die sources.list einträgt.

Das ist aber der Fall. Es werden nur die Quellen eingetragen, die für die ausgewählten Pakete nötig sind, bei entsprechender Auswahl also auch gar keine.

Was ich meinte, ist folgendes: Der Benutzer braucht Paket X, welches es nur in Quelle Y gibt. Also trägt Communtu Quelle Y in die sources.list ein. Zwei Wochen später wird in Quelle Y eine experimentelle neue Version von Bibliothek Z eingepflegt. Dieses wird dann auf dem System automatisch per Update-Manager eingepflegt, obwohl Quelle Y ja gar nicht dafür gedacht war um Bibliothek Z zu beziehen, sondern nur für Paket X. Sowas kann man mit Apt-Pinning verhindern, indem man klar festlegt, dass Pakete unabhängig von der Versionsnummer nur aus den Standardquellen bezogen werden sollen, außer Paket X, welches aus Quelle Y installiert und upgedatet werden soll.

Die neue Konzeption ist ja die Installation über Metapakete, nicht über das Skript. Die Metapakete werden wir auch noch signieren, so dass dann nicht mehr manipuliert werden kann.

In dem Metapaket steht dann nur drin "Depends: Paket X". Gegen Manipulation am Paket X hilft die Signatur des Metapakets also gar nicht.

OK, das können wir gerne machen. Bisher kann man schon jedes einzelne Paket auf seiner Webseite nachgucken, aus welchen Quellen es verfügbar ist. Verstehe ich dich richtig, dass du vorschlägst, dass vor der Installation das nochmal zusammenfassend aufgelistet wird?

Wenn das so ist, dann ist das zu versteckt, denn ich hab's nicht gefunden. 😉 Eine Zusammenfassung vor der Installation wäre daher viel besser.

otzenpunk schrieb:

Was ich meinte, ist folgendes: Der Benutzer braucht Paket X, welches es nur in Quelle Y gibt. Also trägt Communtu Quelle Y in die sources.list ein. Zwei Wochen später wird in Quelle Y eine experimentelle neue Version von Bibliothek Z eingepflegt. Dieses wird dann auf dem System automatisch per Update-Manager eingepflegt, obwohl Quelle Y ja gar nicht dafür gedacht war um Bibliothek Z zu beziehen, sondern nur für Paket X. Sowas kann man mit Apt-Pinning verhindern, indem man klar festlegt, dass Pakete unabhängig von der Versionsnummer nur aus den Standardquellen bezogen werden sollen, außer Paket X, welches aus Quelle Y installiert und upgedatet werden soll.

sorry, da hatte ich dich wohl missverstanden. Also Apt-Pinning... Würde es reichen, die neuen Quellen alle mit Priorität=100 in die /etc/apt/preferences einzutragen? Dann werden sie ja wirklich nur benutzt, wenn es nicht anders geht, d.h. selbst bei offiziellen Versionen, die älter sind, würden diese bevorzugt.

Die neue Konzeption ist ja die Installation über Metapakete, nicht über das Skript. Die Metapakete werden wir auch noch signieren, so dass dann nicht mehr manipuliert werden kann.

In dem Metapaket steht dann nur drin "Depends: Paket X". Gegen Manipulation am Paket X hilft die Signatur des Metapakets also gar nicht.

Gut, aber die von dir vorgeschlagenen Fingerprints der Schlüssel würden ja auch nur vor eine Manipulation des Installations-Skripts bzw. des Communtu-Metapakets schützen, und nicht vor Manipulation an Paket X.

OK, das können wir gerne machen. Bisher kann man schon jedes einzelne Paket auf seiner Webseite nachgucken, aus welchen Quellen es verfügbar ist. Verstehe ich dich richtig, dass du vorschlägst, dass vor der Installation das nochmal zusammenfassend aufgelistet wird?

Wenn das so ist, dann ist das zu versteckt, denn ich hab's nicht gefunden. 😉 Eine Zusammenfassung vor der Installation wäre daher viel besser.

Zumindest unter Ubuntu wird vor dem Hinzufügen neuer Quellen eine Zusammenfassung angezeigt. Dazu musst du z.B. auf den 1. Link unter "Installation über Metapakete" klicken und das Paket installieren. Unter Kubuntu wird es demnächst auch laufen...

Danke für das Feedback! Gruß Till

ebenfalls aus mehreren gründen dagegen:

• führt zur weiteren verdummung von Nutzern, was wiederum zu noch mehr topics hier im forum führt. Die Leute sollen sich mit dem Computer auseinander setzen, wer dafür keine Zeit hat braucht auch keinen PC. Durch die weiterführende verdummung wird auch das verbreiten eines Virusses einfacher, wer garantiert das die Paketquellen entsprechend geprüft werden? Richtig! niemand. Bei den Canonical quellen steht Canonical dahinter.

• verwurschtelt einem seine Paketversionen (siehe otzenpunk)

Desweiteren verstehe ich nicht was so schwierig ist einen Codec zu installieren? Man startet den Film/Das video, dann kommt totem hoch und einem wird sofort ein entsprechender Dialog präsentiert, wo man sich durchhangelt und fertig.

Da ist nichts schwieriges drann.