Hallo,
was haltet Ihr davon, Teile von smxi für das Entfernen bestimmter Pakete zu nutzen? Ich rede nicht von smxi als Aktualisierungswerkzeug, fand aber einige Funktionen sehr hilfreich, wie etwa das Entfernen unnötiger xorg Pakete.
Das Blöde ist, dass ich solche Dinge nur vorschlagen kann. Was die Umsetzung betrifft, habe ich zu wenig Kenntnisse im Umgang mit Skripten.
Viele Grüße,
Holger
Benutz doch einfach apt-get! :mrgreen: oder synaptic.
Halo Micha,
netter Vorschlag :-)
smxi hatte eine Funktion, überflüssigen xorg Kram zu entfernen. Es wertete die genutzten Module aus, und gab dann eine Liste an nicht verwendeten Paketen aus, die ich in einem Rutsch dann entfernen konnte.
Viele Grüße,
Holger
Ich habe von smxi noch nie was gehalten, es hat mehr karpott gemacht als genützt.
...
Auch bei smxi musst du entscheiden welche xorg-Treiber du behalten willst, dann kannst du es aber auch gleich in synaptic machen ohne erst dich durch smxi zu wühlen bis die Option endlich erscheint.
Quote from: "hsp"Ich habe von smxi noch nie was gehalten, es hat mehr karpott gemacht als genützt....
Das kann ich nicht bestätigen. Bei mir hat das Tool sehr gut funktioniert. Politische Machtspielereien führten dann dazu, dass man einem sehr engagierten Entwickler den Garaus gemacht hat. Das war von einigen so gewollt. Das war auch der erste Anfang vom Ende der alten Community. Mobbing wäre noch eine nette Beschreibung zu dem was da passiert ist (Beurteilung meiner Vordergrundsicht, nicht des Hintergrundes).
Unabhängig von der Beurteilung der Qualität oder Geeignetheit von smxi (die ich garnicht machen kann), war der Umgang da mehr als rauh.
Ich fände ein solches Tool interessant. Derjenige, der sich da engagiert, sollte sich aber auch eng mit den führenden Köpfen der siduction-Entwickler abstimmen. Dann könnte es für einige siduction-Anwender interessant werden. Dies gilt auch für eine wachsende community, wo mit der Zeit immer mehr Anwender dazukommen, die natürlich auch immer unerfahrener oder unbedarfter sein werden.
stimme mylo und Holger uneingeschränkt zu.
habe smxi lange Jahre genutzt. War immer zuverlässig.
Ich stimme meinem Vor-Redner/-Schreiber ebenfalls uneingeschränkt zu. 8)
Grüße
Reiner
Auch ich habe smxi lange benutzt, weil das damals als "the all in one tool" verkauft wurde. Ich hatte nie Problem mit dem Script, fand es aber zu umfangreich um mal schnell zu nutzen.
Die Idee Teile davon zu separieren finde ich gar nicht doof.
Ein, wie hier vorgeschlagener "xorgCleaner", der Hilfestellung bei der Entfernung von überflüssigen Paketen gibt, hört sich gut an. Evtl hat es noch weitere Teil in smxi die eine Vereinfachung darstellen könnten ...
In wie weit das technisch machbar ist weiß ich nicht, grundsätzlich hört sich das aber spannend an.
Hallo,
ich hatte schon befürchtet, dieser Thread verschwindet rasch in der Versenkung. Auch wenn ich mit vermutlich nicht böse gemeinten Hinweisen wie "nimm doch apt oder Synaptic" ein Desinteresse an meinem Vorschlag verbinde, das ist natürlich in Ordnung, finde ich sie doch nicht sehr hilfreich. Das ist ähnlich wie: Nimm doch statt dpkg-reconfigure einfach nen Editor. Oder warum eigentlich apt? Man lernt viel mehr über Paketabhängigkeiten, wenn man den Krempel manuell herunter lädt und nur dpkg benutzt ;-)
Und nochmal: Ich rede nicht von smxi als Softwareaktualisierungstool mit holds und anderem technischen Ungemach für ein Rolling Release.
QuoteDie Idee Teile davon zu separieren finde ich gar nicht doof.
Ein, wie hier vorgeschlagener "xorgCleaner", der Hilfestellung bei der Entfernung von überflüssigen Paketen gibt, hört sich gut an. Evtl hat es noch weitere Teil in smxi die eine Vereinfachung darstellen könnten ...
Genau das meinte ich doch.
Viele Grüße,
Holger
Hallo allesamt,
auch ich habe sehr lange smxi benutzt, vor allem in meinen Anfangszeiten mit kanotix / sidux mit prop. Grafikkarten-Treibern, Installation von Google Earth etc.pp. Auch deshalb, weil die Qualität von sid damals bei weitem noch nicht so hoch war wie heute und ich mich dunkel und ungern erinnere, dass man damals mit einem D-U mindestens einmal im Monat sein System zerschossen hat. Heute kommt sid doch schon sehr nahe an stable ran, meine ich.
Ich konnte aber auch immer die Argumente gegen smxi nachvollziehen und bin der Meinung, dass es nicht gut wäre, auch nur bestimmte Teile davon Bestandteil von siduction werden zu lassen. Gerade die Fokussierung auf apt und nur wenige sid-unabhängige distro-eigene Ergänzungen oder Fixes im eigenen Repo finde ich gut.
Ich muss auch sagen, dass ich mit fortschreitendem Erkenntnisgewinn diese Skripte immer weniger benutzt habe und nun schon lange nicht mehr verwende. Und einige nicht benötigte xorg-Pakete sind mir schlicht egal.
Ich schlage mal vor, zum Kern der Sache zu kommen: Wenn ein Script vermisst wird dass einen bestimmten Funktionsumfang erfüllt, wie in diesem Fall das Entfernen der nicht benutzten Xorg Treiber, so kann man dafür schnell ein Script erstellen.
Das Herauslösen dieser Funktionalität aus smxi ist garantiert komplizierter als ein paar simple Zeilen zu schreiben.
Der klare Nachteil an smxi war (ausser seiner Schwatzhaftigkeit): wenn $user sich entschied, fortan ohne smxi zu leben, war er am besten mit einer Neuinstallation beraten, denn es wurde doch so einiges umgebogen. Das ist für mich bei solch einem Script schon das K.O.-Kriterium.
greetz
devil
Hallo zusammen,
also ich muss mich nun auch mal outen zu smxi. Ich hatte das Tool bis zum Ende von sidux genutzt und fand es ganz hilfreich. Ich gebe Holger Recht, wenn er sich ein Tool wünscht das die angesprochene Sache doch wesentlich erleichtern könnte.
Devil, ist mit seinen Vorschlag, ein neues Script dafür zu Erstellen auf der besseren Seite um so etwas zu implementieren. Es müssten sich meiner Meinung nach 2-3 User zusammenfinden die so etwas umsetzen.
Voraussetzung um so ein Script/Vorhaben zu erstellen, wäre Lernwille und ein schon ein wenig Erfahrung beim Schreiben von Bashscripten und gute Kenntnisse von apt.
Ich habe schon ein gute Kenntnisse bzgl. Scriptprogrammierung, würde auch mitmachen bei so einem Projekt wenn sich noch 1-2 Leute finden lassen.
Was ist mit meinem CLI-Menu gesteuertem Empfehlungssystem von vor drei Jahren (*). Ich hatte damit unter noch sidux nur aufgehört, weil slh im IRC sagte, er hätte kein Interesse Leute zu unterstützen, die in der normalen Debian CLI Umgebung nicht überleben ...
Die smxi Befehle kann man isolieren und dort einbauen. Dann kann man sie nebenbei auch besser einem Qualitäts Auditing unterziehen. Für interessierte kann man zusätzlich Spezialzweige anlegen, die aufzeigen wie debootstrap funktioniert, etc ...
(*)PS: ich hatte das damals dushelp (Dusselhilfe) genannt, grob nach der "Dummy" Buchreihe.
Also ich benutze das smxi bis heute seit Jahren. Das mit apt-get ist nat. geschenkt, dass kann man auch simpel selber machen. Im übrigen spricht doch auch nichts dagegen, smxi weiterzuverwenden, denn "smxi, sgfxi, and svmi support all Debian based distributions." http://smxi.org/site/faqs.htm#debian-support
Für mich als user spricht für smxi v.a. dass ich mir den ganzen Krempel nicht merken muss. Ich habe hier Rechner am laufen mit Intel-Graka und NV (für letzteres "brauche" ich den prop. Treiber). Dann bin ich Fan von Opera (steinigt mich) und habe auch die VirtualBox seit Ewigkeiten laufen (da ich auf Arbeit manchmal Windoof brauche, aber dort sonst normal mit Linux arbeiten kann).
Für diesen ganzen Quatsch ist mir smxi ans Herz gewachsen, da ich mir die Befehlszeilen nicht merken / aufschreiben muss. Das gehe ich nacheinander durch, fettich. Ja, da bin ich faul, das gebe ich gerne zu.
Ich lebe nat. auch mit den Konsequenzen (die sich bisher in Grenzen hielten). D.h., falls doch etwas kaputt gehen sollte, dann mach ich mich auf die Suche nach Lösungen (was ich aber auch tue, wenn beim normalen Upgrade mal was schief laufen sollte). Und das hat in den wenigen Fällen meist gut geklappt. I.d.R. war es aber auch kein smxi-Problem sondern ein allg.
Das Problem an smxi in meinen Augen ist, dass sich zu viele das Ding als nonplusultra angesehen haben. Wie auch bei einem "normalen" Upgrade sollte man auch bei smxi nat. die Augen offen halten - sprich was soll entfernt werden bzw. gibt es hier - oder in irgendeinem anderen relevanten Forum - Upgrade-Warnungen. Das denke ich, haben viele nicht gemacht und sich blind auf smxi verlassen.
Was ich nicht nachvollziehen kann @Devil ist, was das Script so alles umgebogen haben soll. M.W. werden die hold-Setzungen z.B. nach dem DU wieder zurückgesetzt (auch eine schöne Erleichterung), an den Quellen wird auch nicht rumgedreht...
Was ich schade fand und finde - und das ist ja auch schon bspw. von @mylo angesprochen worden - dass man bei sidux und aptosid smxi so verteufelt hat. "No support of 3rd-party-tools!" Ich kann verstehen dass man sich nicht mit den Problemen fremder Scripte rumschlagen will (bzw. erst rausfiltern muss, ob es ein d-u oder smxi prob sein könnte), aber warum man da bespw. nicht eine smxi-Ecke eingerichtet hat, wo sich der Entwickler (der hat ja bei sidux fleißig zu seinem Teil supportet) - und andere interessierte - dann damit rumschlagen kann entschließt sich meinem Verständnis.
Für mich ist es einfach ein nettes Helferlein, wenn man es nicht als eierlegende Wollmilchsau missversteht und v.a. die Augen offen hält - was man ja eh machen sollte.
Quote
Wie auch bei einem "normalen" Upgrade sollte man auch bei smxi nat. die Augen offen halten -
Das geht m.E. nur mit Sonnenbrille ;)
Quote
Was ich nicht nachvollziehen kann @Devil ist, was das Script so alles umgebogen haben soll.
Dann schau mal, wo z.B. Deine Kernel hin installiert werden und der nvidia Kram. Das waren zumindest früher nicht die default Verzeichnisse. Das nenn ich umbiegen.
greetz
devil
hm - irgendwas begreife ich nicht. meine proprietären nvidia-Treiber installiere ich mit apt-get. Genau wie ich das mit den proprietären catalysts mache, wenn sie denn man funktionieren.
Überflüssige Xorg-Pakete hab ich nicht auf dem System, nachdem ich mir vor über einem Jahr mal die Mühe gemacht habe, aufzuräumen. und zwar mit apt-get.
Nicht das ich was gegen smxi hätte - ich sehe nur den Sinn nicht so ganz. Der Wiggel mit den proprietären Treibern hat sich mit einem funktionierenden dkms so gut wie erledigt. Was will man denn noch? Das einzige, was mit regelmäßig zum durchticken bringt, ist mein HP-Drucker, der wahlweise in schönster Regelmäßigkeit mit proprietät oder frei nicht zusammenarbeiten will. Die direkte Rache an der Hardware wird kommen, wenn der Toner in 1000 Seiten alle ist. Bis dahin drucke ich im Zweifel über eine Windows-VM, da sind die Farben dann auch ungefähr so, wie ich mir das vorstelle.
Aber wenn ich mich recht entsinne, war den Konsenz am Anfang von siduction: Es gibt keine Berührungsängste beim Umgang mit smxi und anderen Scripten - wir supporten und promoten sie einfach nur nicht. Das würde ich gern weiter so halten, da der Support von h2 wahrscheinlich wesentlich kompetenter ist, als das, was wir leisten können und wollen.
Ich bedaure noch heute wie persönlich diese auseinandersetzung damals geworden war, dass h2 es zuletzt quasi als aufkündigung der freundschzaft ansah wenn man auf smxi verzichtete. Wirklich schade wie sein engagement innerhalb sidux für ihn zum schluss eine einzige enttäuschung wurde.
Sachlich betrachtet war für mich smxi eben ein klasse nvidia installer mit allem möglichen gimmicks drum herum. Das ist wie agaida schon bemerkte, seit funktionierendem dkms nicht mehr notwendig.
Problematisch wurde smxi eben dadurch, dass das es beim d-u die leute noch weniger vorsicht walten lies als dies mit apt alleine möglich war. Dabei war auch bei smxi lesen angesagt, wie das mit apt eben immernoch der fall ist. Dies war meines erachtens das große missverständniss, dass smxi eine nahezu 100% d-u sicherheit anstrebte, die real nie erreichbar war ... und in sofern kontraproduktiv war.
Bei der gelegenheit sei zumindest erwähnt, dass wir hier mit inxi weiter von h2's engagement profitieren, in diesem fall wohl uneingeschränkt positiv!
Zu holgers ausgangsfrage:
Letztlich wäre das mit einem alias zu erledigen, es müsste sich nur einer hinsetzen, und für die wichtigsten grakatreiber eine liste der nicht benötigten xorg treiber pakete erstellen. Dann sähe ein alias für nvidiakarten besitzer einfach so aus:
alias nvidiaonly='apt-get purge <pakete1bisX>'
Statt eines alias kann man dies ähnlich auch in scripte z.b. namens nvidiaonly/readononly/intelonly ... stricken.
Vielleicht wäre dies der beginn einer alias- oder scriptsammlung. smxi dafür wäre meines erachtens absoluter overkill.
(BTW: der timeout für das erstellen von beiträgen ist way to short!!! Und dass text innerhalb "<" ">" gefressen wird falls ein leerzeichen oder bindestrich enthalten ist ist immer noch ätzend)
+1 (wie smxi im Endeffekt für die Benutzer vieles verdeckt)
Hallo,
ich finde den Vorschlag von bluelupo gut, daß sich mal 2-3 user "zusammensetzen" und ein möglichst einfaches script für den speziellen Vorgang basteln.
Ich hab mir mal überlegt wie das -bei meinen begrenzten Kenntnissen- aussehen könnte: -frei nach unserem wiki "home sichern"
Zu Beginn würde ich alle Kandidaten außer fbdev und vesa in einer Datei sammeln:
dpkg -l|awk '/^ii/{ print $2 }'|grep xserver-xorg-video |grep -v -e -fbdev -e -vesa >test.txt
Dann müsste eine Zeile mit einem vom user einzugebenden Muster wieder aus dieser Datei herausgenommen werden bzw gleich in der o. a. Zeile mit ausgeschlossen werden -und da hakts bei mir weil ich nicht weiß wie ich das lösen könnte.
Anschließend ein apt-get purge $(test.txt) und fertig iss die Laube -oder?
Gruß
ayla
EDIT2:
ok, ich glaub ich hab's:
#! /bin/bash
echo "Treiber der zu behalten ist eingeben -z.B. radeon oder intel oder ...
ACHTUNG: ALLE ANDEREN video-Treiber außer -fbdev und -vesa WERDEN ENTFERNT"
read driver
apt-get purge $(dpkg -l|awk '/^ii/{ print $2 }'|grep xserver-xorg-video |grep -v -e $driver -e -fbdev -e -vesa)
ähhm....
Daß init 3 aus KDE heraus bei mir jetzt zum hängen bleiben des Systems führt kann aber nichts mit dem Herumspielen bei dem Entwickeln des Scripts zu tun haben, oder? :oops:
noch'n edit:
Es sollte auch dies hier funktionieren, da ich allerdings nicht weiß wie das bei radeon, nouveau etc aussieht und's auch nicht ausprobieren kann, mal nur für intel:
#! /bin/bash
apt-get purge $(dpkg -l|awk '/^ii/{ print $2 }'|grep xserver-xorg-video |grep -v -e $(apt-cache search $(lsmod|grep video |awk '{print $4}')|grep -v -e dbg |awk '{print $1}') -e -fbdev -e -vesa)
Hier wird, statt den String wie oben von Hand einzugeben, mit lsmod |grep video nachgeschaut welches Kernelmodul geladen ist.
Danach wird mit apt-cache search das zugehörige Paket ermittelt, der String des dbg-Pakets mittels grep davon entfernt und der Paketname dann von awk zum Ausschluß an grep übergeben...
Geht sicher einfacher oder eleganter, funktioniert aber bei meinem i915-Modul -und macht vor allem auch Spaß wenn man mal was davon kapiert hat. :)
Mein Vorschlag, was das Ausmisten von X angeht - IBM, und zwar konsequent. IBM soll heissen: Immer besser manuell, da es einige Konfigurationen gibt, wo ich mit einem generellen Rundumschlag nicht glücklich werde. Also den Vorschlag von ayla aufgreifend:
Scriptlet, was die vorhandenen potentiellen Störer in eine Datei schreibt, diese dann manuell editeren und ein scriptlet, was das Zeug dann aus dem System löscht.
Nennt mich ruhig altmodisch, aber ich kontrolliere solche Listen wirklich vor der Ausführung. Und ja, ich kann auch ohne Wiki X ohne wenn und aber installieren und bis auf wenige Paramenter auch konfigurieren. :twisted:
Quote from: "agaida"Nennt mich ruhig altmodisch, aber ich kontrolliere solche Listen wirklich vor der Ausführung.
Hallo agaida,
soo altmodisch bin ich doch auch :)
So sieht das bei beiden scripten aus, die Abfrage und Auflistung von apt kommt selbstverständlich sowohl bei der ersten wie auch bei der zweiten Variante bevor eine Löschaktion ausgeführt wird :
Quote./ttt.sh
Treiber der zu behalten ist eingeben -z.B. radeon oder intel oder ...
ACHTUNG: ALLE ANDEREN video-Treiber außer -fbdev und -vesa WERDEN ENTFERNT
intel
Paketlisten werden gelesen... Fertig
Abhängigkeitsbaum wird aufgebaut
Statusinformationen werden eingelesen... Fertig
Die folgenden Pakete werden ENTFERNT:
xserver-xorg-video-all* xserver-xorg-video-apm* xserver-xorg-video-ark* xserver-xorg-video-ati* xserver-xorg-video-chips* xserver-xorg-video-cirrus*
xserver-xorg-video-i128* xserver-xorg-video-mach64* xserver-xorg-video-mga* xserver-xorg-video-neomagic* xserver-xorg-video-nouveau*
xserver-xorg-video-openchrome* xserver-xorg-video-r128* xserver-xorg-video-radeon* xserver-xorg-video-rendition* xserver-xorg-video-s3*
xserver-xorg-video-s3virge* xserver-xorg-video-savage* xserver-xorg-video-siliconmotion* xserver-xorg-video-sis* xserver-xorg-video-sisusb*
xserver-xorg-video-tdfx* xserver-xorg-video-trident* xserver-xorg-video-tseng* xserver-xorg-video-vmware* xserver-xorg-video-voodoo*
0 aktualisiert, 0 neu installiert, 26 zu entfernen und 0 nicht aktualisiert.
Nach dieser Operation werden 7.115 kB Plattenplatz freigegeben.
Möchten Sie fortfahren [J/n]?
Die Antwortvorgabe die apt gibt ist allerdings "ja", aber wer da ohne Kontrolle dann "enter" drückt...
Gruß
ayla
Das hab ich bei Arch gelernt: Verlass Dich vor allem auf die Blödheit der Leute vor dem Schirm und gib ihnen gar nicht die Chance auf 'y' zu drücken. Und dabei nehme ich mich nicht aus. Im Zweifel ist der manuelle Aufruf mit einer vorbereiteten Liste schmerzfreier.