Author Topic: [DE] Pro und Contra zur Nutzung des Tool smxi für Rollin Distris (Read 28125 times)

bluelupo · « **on:** 2011/05/15, 16:30:41 »

Hallo zusammen,
ich wollte hier mal eine Diskussion anstoßen was gegen und was für die Nutzung des Script-Wartungstool smxi spricht. Ich persönlich kann mich, aus Gründen der einfachen und schnellen Wartbarkeit mehrerer Rechner, schon für den Einsatz von smxi begeistern. Aber natürlich immer mit den Hintergrund, das man weiß was man tut.

Wie steht ihr zu den Thema?

holgerw · « **Reply #1 on:** 2011/05/15, 16:39:13 »

Hallo @bluelupo,

ich habe es zu Anfangszeiten von sidux sehr gerne benutzt, danach jedoch nicht mehr.

smxi hat schon einige sehr bequeme Funktionen. Der Umgang mit holds bei Aktualisierungen ist jedoch schwierig. Wie möchte Harald das in den Griff bekommen, wenn die Debian Server viermal pro Tag aktualisiert werden?

Aber ich hoffe hier auf eine spannende Diskussion, zumal smxi ja auch noch andere Funktionen hat.

Viele Grüße,
Holger

devil · « **Reply #2 on:** 2011/05/15, 16:46:23 »

ich halte smxi für völligen mist. viel zu viel output (auf EN) den $nutzer lesen muss. essentieller output geht unter.
überbewertet und unnütz in meinen augen.

greetz
devil

bluelupo · « **Reply #3 on:** 2011/05/15, 16:59:51 »

Quote from: "holgerw"

ich habe es zu Anfangszeiten von sidux sehr gerne benutzt, danach jedoch nicht mehr.

@Holger: ich hatte es lange Zeit auch nicht mehr benutzt, werde es aber wieder für einige Rechner einsetzen.

Quote from: "holgerw"

smxi hat schon einige sehr bequeme Funktionen. Der Umgang mit holds bei Aktualisierungen ist jedoch schwierig. Wie möchte Harald das in den Griff bekommen, wenn die Debian Server viermal pro Tag aktualisiert werden?

...zugegeben das HOLD-Handling ist ein schwieriges Thema und auf tatkräftige Mitarbeit von Helfern angewiesen. Aber es hatte in der Vergangenheit (aktuell kann ich das nicht beurteilen) schon ganz passabel funktioniert.

Quote from: "devil"

ich halte smxi für völligen mist. viel zu viel output (auf EN) den $nutzer lesen muss. essentieller output geht unter.
überbewertet und unnütz in meinen augen.

...für Mist halte ich smxi ganz und gar nicht, weil es schon eine gewisse Vereinfachung der Wartbarkeit von Systemen bietet. Zustimmen muss ich dir beim "Output" der oftmals etwas zu lange und damit nur die Unübersichtlichkeit fördert.

hefee · « **Reply #4 on:** 2011/05/15, 17:08:27 »

also apt-get mit apt-listbugs reicht mir völlig. So sehe ich aktuell offene bugs und kann selber entscheiden ob update ja oder nein. Und es ist halt alles unter meiner Kontrolle. Mit smxi konnte ich mich nie anfreunden, weil es meinem Geschmack zu viel magic gemacht hat und ich nicht mehr verstanden, warum es was macht ...
Was eigentlich noch fehlt ist: Ich sage, bug XXXX ist ein Problem für mich und ein Tool das hold dann entfehrnt, wenn der bug gefixed ist bzw. fragt, ob das hold aufgelöst werden soll.

devil · « **Reply #5 on:** 2011/05/15, 17:17:40 »

Quote

..für Mist halte ich smxi ganz und gar nicht, weil es schon eine gewisse Vereinfachung der Wartbarkeit von Systemen bietet.

eben genau diese vereinfachung verneine ich und konstatiere das gegeteil.

greetz
devil

brummer · « **Reply #6 on:** 2011/05/15, 17:31:29 »

Quote from: "devil"

eben genau diese vereinfachung verneine ich und konstatiere das gegeteil.

greetz
devil

Sehe ich genauso, wundert mich das smxi noch nicht grafikfähig ist, und automatisch im background laufen kann, so das man als user nachher nicht mal weiß 'warum die kiste nicht mehr läuft'
:wink:

gruß
brummer

bluelupo · « **Reply #7 on:** 2011/05/15, 19:22:21 »

@hefee, @devil, @brummer:
Ihr habt sicherlich mit euren Argumenten Recht, das smxi für den absoluten Anfänger der Lernfaktor gleich Null ist und wenig zur Lernbereitschaft beiträgt, aber für den fortgeschrittenen User bietet das Tool schon ein gewisse Vereinfachung. Ich sehe smxi als das was ist, als ein Shellscript und nicht mehr. Die Systemwartung wird damit vereinheitlicht und etwas automatisiert.

reddark · « **Reply #8 on:** 2011/05/15, 19:51:58 »

Ich habe mit Suse, später OpenSuse angefangen und bin nach meiner Ubuntu-irrfahrt bei sidux gelandet. Anfangs war smxi für mich ganz angenehm, hatte ich doch das gefühl es nimmt mir ne menge Arbeit ab. Nachdem dann doch immer mehr davon abgeraten wurde, habe ich mich an apt gewagt und muss nun sagen, mithilfe aliase hab ich genauso wenig arbeit. Hab mir alles per kurzbefehle eingerichtet und vermisse seid dem smxi absolut garnicht

hefee · « **Reply #9 on:** 2011/05/15, 20:22:51 »

@bluelupo: Wie du schon erwähntest, kann es nicht alles wissen, was zuunter hold fällt, also du musst auch schauen, ob es ein Fehler gibt, der dirch trifft. Das ist der selbe aufwand wie bei reinem apt-get.
Du schreibst davon, das es einfacher ist und weniger Probleme bereitet als die reine apt-get Lösung, kannst du dies an einer Liste aufzeigen? Welche Anforderungen hast du an deine Maschinen? Wie unterschiedlich sind sie in Bezug auf installierte Pakete?

Ich sehe es so: Ich update einen Rechner und schaue, was es da für Probleme gibt. Danach kann ich alle anderen Rechner gefahrlos auch auf den selben Stand bringen... (Natürlich je nach Hardware erfordert es hier und da ein hold mehr oder weniger) oder halt die spezifischen Anforderungen...

bluelupo · « **Reply #10 on:** 2011/05/15, 20:41:01 »

Quote from: "hefee"

@bluelupo: Wie du schon erwähntest, kann es nicht alles wissen, was zuunter hold fällt, also du musst auch schauen, ob es ein Fehler gibt, der dirch trifft. Das ist der selbe aufwand wie bei reinem apt-get.

Natürlich das Finden von evtl. Problemen (Hold) kann mir smxi nicht gänzlich abnehmen. Aber die evtl. gröbsten Schnitzer nimmt es mir ab und Zweifalls setze noch ein zusätzliches Paket auf Hold.

Quote from: "hefee"

Du schreibst davon, das es einfacher ist und weniger Probleme bereitet als die reine apt-get Lösung, kannst du dies an einer Liste aufzeigen? Welche Anforderungen hast du an deine Maschinen? Wie unterschiedlich sind sie in Bezug auf installierte Pakete?

Meine Rechner sind zu 95% mit dem gleichen Paketen versehen und zudem teilweise auch baugleich. Da möchte bei der ganzen Upateprozedur dann ab dem zweiten Rechner nicht mehr groß Nachdenken. Da ist mir smxi schon von Nutzen.

hschn · « **Reply #11 on:** 2011/05/15, 22:19:06 »

Hallo
ich habe zu Beginn von sidux manchmal smxi benutzt.
Schließlich hat es mich nur noch genervt.
Dauerte ewig, setzte Pakete auf hold, vergaß diese zurückzusetzen, ich hatte keinen Überblick. Ganz aktuelle Probleme konnte es auch nicht lösen. Hing eigentlich immer hinterher.

Also ich sehe hier bei apt-get nur Vorteile.
D-u mit der Option -dy unter x, kurz mal die Meldungen nachlesen, auch mal ins Forum schauen, dann entweder init 3 und d-u oder einfach warten; was ist da das Problem? Geht schnell, sogar teilweise im Hintergrund, und wenn die Rechner sogar ziemlich identisch sind läuft doch die Sache.

Ich sehe bei smxi eigentlich nur den Vorteil, dass man, wenn etwas schiefgeht, die Schuld erstmal auf jemand anderes abwälzen kann und das Ziel der Flüche nicht selbst ist.

Ansonsten bin ich voll devils Meinung: smxi ist nur Mist!

Viele Grüße
hschn

ralul · « **Reply #12 on:** 2011/05/15, 23:21:50 »

@devil +1

Die Idee von den holds bei smxi war ja wohl, dem geneigten Benutzer das Lesen im Forum Upgrade-Warnings zu ersparen. Das sollte auch das kommende Debian Rollin' können ...

Wenn ich mehrere identische Rechner hätte, würde ich dann nicht ein lokales Repo im Netzwerk einrichten, was die Pakete vorselektiert beim DU des ersten Rechners?

Lanzi · « **Reply #13 on:** 2011/05/15, 23:52:38 »

Die Zusatzfunktionen geballt in einem Tool (Alternative Kernel, Kernel-Remover, Mscorefonts, Skype, Virualbox, apt-clean usw) finde ich interessant. für den reinen DU-Prozess ist es nicht so wichtig, aber praktisch.

agaida · « **Reply #14 on:** 2011/05/16, 09:19:19 »

@ralul +1
Da ich smxi nicht kenne, will ich mir da keine Meinung zu erlauben. Bei mehreren Rechnern ist ein eigenes Repo wohl die beste Variante - allerdings muss das ja auch gepflegt werden. Ich bleibe momentan bei IBM (immer besser manuell). Da ich Egomane bin, habe ich mir aber bis auf Arch über so was keine Gedanken gemacht. Rechner werden dann bei mir aktualisiert, wenn ich an ihnen arbeite. Es kann also passieren, dass bestimmte Maschinen, die nicht exponiert sind und keine Probleme machen, über Wochen nicht aktualisiert werden.