staging.inyokaproject.org

Baustelle/mit_Root-Rechten_arbeiten

Status: Ungelöst | Ubuntu-Version: Nicht spezifiziert
Antworten |
Dieses Thema ist die Diskussion des Artikels Baustelle/mit_Root-Rechten_arbeiten.

noisefloor Team-Icon

Ehemaliger
(Themenstarter)
Avatar von noisefloor

Anmeldungsdatum:
6. Juni 2006

Beiträge: 28316

Hallo,

Bis dahin betrachte ich die jetzige Lösung mit einer TL;DR-Klausel am Anfang des Artikels und dem zusätzlichen Abschnitt als ausreichend funktional.

+1

Zumal: wenn es einen Artikel "Systemddateien bearbeiten" geben würde, dann wäre das nicht "mal eben so" im Wiki geändert. Der Artikel mit Root-Rechten arbeiten hat z.Zt. 282 Backlinks (Baustellen und Archiv nicht mitgezählt), die müssten alle überprüft werden. Was selbst mit einem fiktiven "Wikisprint" mit 5-10 Leuten reichlich Arbeit = Zeitaufwand wäre.

Gruß, noisefloor

Newubunti

Anmeldungsdatum:
16. Februar 2008

Beiträge: 4768

kB schrieb:

Bis dahin betrachte ich die jetzige Lösung mit einer TL;DR-Klausel am Anfang des Artikels und dem zusätzlichen Abschnitt als ausreichend funktional.

Ich wollte damit auch nicht sagen, dass ein etwaiges Abtrennen des Abschnitts "Systemdateien bearbeiten" in einen eigenen Artikel einer Veröffentlichung dieses Artikels hier, so wie er im Moment ist, im Wege steht.

Das Problem mit vielen zu ändernden Backlinks hat man ja jetzt ohnehin schon. Da kommt vielleicht noch der ein oder andere hinzu, der dann zu einem späteren Zeitpunkt zusätzlich zu ändern wäre. Aber das steht einer Veröffentlichung in der jetzigen Form nicht im Wege.

Ich wollte ja auch nur noch mal meine Meinung diesbezüglich in die Diskussion werfen, weil ich das weiter vorne offen gelassen hatte.

Das hätte den Vorteil, dass man für das Thema "Systemdateien bearbeiten" für die Zukunft flexibler bleibt, wenn z.B. jemand eine GUI-Alternative zu sudoedit für ein Derivat hinzufügen wollte, sofern es die zukünftig gäbe.

Eine solche GUI-Alternative habe ich doch längst (zur Zeit zwar noch als Baustelle) im Wiki hinterlegt und der hiesige Artikel verweist bereits darauf.

Das meine ich aber nicht. Die Lösung von Dir in der Baustelle finde ich ebenfalls gut, allerdings ist sie eine, die der Anwender erst aktiv herbeiführen muss und nicht Out-of-the-box existiert.

"Künftige GUI-Alternativen" meinte insofern solche, die standardmäßig vom Derivat bereitgestellt werden und sauber umgesetzt sind, so dass der GUI-Editor nicht unter root läuft, sondern unter dem Nutzer und dann nur als root gespeichert wird. Also im Prinzip so wie es unter Ubuntu OOB jetzt mit gedit admin:///... bereits möglich ist.

Und zweites Argument für das Herauslösen in einen eigenen Artikel ist die Leserperspektive. Ich kann Dir aus eigener Erfahrung sowohl hier im Wiki als auch im Umfeld sagen, dass der "Normalanwender" sich gerne an den Experten wendet, um den "richtigen" bzw. "best möglichen" Weg aufgezeigt zu bekommen, um eine bestimmte Aufgabenstellung zu erledigen. Von einer Aufzählung aller Möglichkeiten fühlt sich diese Nutzergruppe eher überfordert.

Gleichzeitig hat aber der Artikel hier - also mit dem sauberen Aufzählen aller Möglichkeiten - ebenso Berechtigung, Notwendigkeit und es gibt hier auch genug Anwender, die genau diese Art der Informations-Aufarbeitung schätzen und je nach Anlass, so auch benötigen.

Das wird ja hier nun im Wiki auch schon lange so gehandhabt, dass man Informationen z.T. noch mal für die "Normalanwender"-Lesergruppe vereinfacht bzw. übersichtlicher bzw. gezielter aufbereitet. Die Existenz der HowTos verfolgt ja auch einen solchen Ansatz.

Aber wie gesagt, dass alles steht einer Veröffentlichung in der jetzigen Form nicht im Wege!

LG, Newubunti

ChickenLipsRfun2eat Team-Icon

Supporter
Avatar von ChickenLipsRfun2eat

Anmeldungsdatum:
6. Dezember 2009

Beiträge: 12070

Newubunti schrieb:

"Künftige GUI-Alternativen" meinte insofern solche, die standardmäßig vom Derivat bereitgestellt werden und sauber umgesetzt sind, so dass der GUI-Editor nicht unter root läuft, sondern unter dem Nutzer und dann nur als root gespeichert wird. Also im Prinzip so wie es unter Ubuntu OOB jetzt mit gedit admin:///... bereits möglich ist.

Dürfte kein Problem sein, steht ja schon ein Beispiel drin. Plasma arbeitet ja so. Kate normal öffnen, /etc/fstab auswählen, editieren, beim Speichern kommt das PolKit-Popup — braucht aber zwingend sudoedit bei nicht lesbaren Verzeichnissen[1]. Sowas lässt sich ja bei Bedarf ergänzen — daher schrieb ich nen Kilometer weiter oben, das sich ein solcher Artikel nur schwer pflegen lässt, da der Testwillige alles durchtesten muss. Ich weiß nicht, wie viel Zeit kB da reingesteckt hat, aber das ist definitiv nicht „mal eben“ getestet.

Und nein, ich hab keinen Verbesserungsvorschlag auf Basis dieser Portalsoftware, da ich keinen Weg kenne Artikel miteinander zu mischen wie das bspw. mit MediaWiki geht (Einzelne Abschnitte können in separate Artikel-Teile ausgelagert werden und sind somit auch einzeln übersetzbar, testbar, etc.). Daher war mein Vorschlag ja, das sich solche Artikel stur auf Standard-Ubuntu (Server, Ubuntu, keine Flavours) beziehen und die DEs innerhalb ihrer Artikel behandelt werden.

  • 1: Bei nicht lesbaren Verzeichnissen gibt es einen Kubuntu-Bug, der bereits gemeldet aber mWn noch nicht öffentlich zugänglich ist

noisefloor Team-Icon

Ehemaliger
(Themenstarter)
Avatar von noisefloor

Anmeldungsdatum:
6. Juni 2006

Beiträge: 28316

Hallo,

off-topic:

da ich keinen Weg kenne Artikel miteinander zu mischen wie das bspw. mit MediaWiki

Das geht ohne Probleme - also zumindest früher. Man konnte (kann?) ganze Seiten einbinden. Wurde ganz früher (als wir noch MoinMoin hatten) auch genutzt, aber die Einbindungen wurden dann nach Umstellung auf Inyoka vom Wikiteam aufgelöst. Es wurde AFAIK z.B. bei Installationsseiten benutzt. Der Grund war, dass das unübersichtlich und fehleranfällig wurde. Weil: sagen wir mal, Seite FOO war auf Seite BAR eingebunden:

bla bla bla

[[INCLUDE(FOO)]]

bla bla bla

Man sah auf Seite FOO aber nicht direkt, dass FOO auf BAR eingebunden wurde. D.h. wenn man FOO im größeren Maßstab geändert hat, dann hätte es vorkommen können, dass der Kontext von BAR nicht mehr stimmt.

Die Syntax zum Einbinden von Seiten sollte in der internen Wikidoku (hoffentlich ☺ ) noch irgendwo sein.

Daher war mein Vorschlag ja, das sich solche Artikel stur auf Standard-Ubuntu (Server, Ubuntu, keine Flavours) beziehen und die DEs innerhalb ihrer Artikel behandelt werden.

So halte ich das zumindest, wenn ich Artikel schreibe. Ich nutze primär Ubuntu (=GNMOME Desktop). Wenn ich etwas beschreibe, was evtl. Abhängig von der DE ist, dann schreibe ich das rein.

Aufgrund der Vielzahl von Flavors halte ich es inzwischen auch nicht mehr wirklich für mit vertretbarem Aufwand machbar, dass man z.B. Thema $FOO für alle Standardeditoren oder Standarddateimanager selber testet bzw. testen kann. Plus man macht den Artikel unnötig scher testbar, weil man ja _alles_ für ein zukünftige Ubuntu Version auf allen genannten Derivaten testen müsste.

Gruß, noisefloor

ChickenLipsRfun2eat Team-Icon

Supporter
Avatar von ChickenLipsRfun2eat

Anmeldungsdatum:
6. Dezember 2009

Beiträge: 12070

Ich konnte dazu nichts finden, zumindest in den Vorlagen (mit der Makro-Syntax) ist das wohl nicht (mehr) drin.

Aufgrund der Vielzahl von Flavors…

Eben. Es kommen ja auch immer mehr dazu. Aktuell bräuchte man zum Test 12 VMs um alles abzudecken (Ubuntu, Budgie, Cinnamon, Edubuntu, Kubuntu, Kylin, Lubuntu, MATE, Studio, Unity, Xubuntu, Server). Und da ist nichtmal die Architektur dabei, die hier glücklicherweise nicht oft berücksichtigt werden muss.

kB Team-Icon

Supporter, Wikiteam
Avatar von kB

Anmeldungsdatum:
4. Oktober 2007

Beiträge: 7816

kB schrieb:

[…] In der nächsten Version, die ich vorbereite, aber erst nächste Woche hochladen werde, …

Das ist nun erfolgt.

Antworten |