ubuntuusers.de

Hallo,

sind Nutzer von Ubuntu 12.04 und 14.04 ausgeschlossen. Damit darf ueber diesen Vorschlag gerne ab 2019 nochmal ernsthaft nachgedacht werden.

So isses in der Tat und vorher wird sich ziemlich sicher im Wiki nichts in diese Richtung tun.

Gruß, noisefloor

horstpenner schrieb:

… auch wenn ich sudo gedit sources.list eingebe, passiert auf TAB …

Das war doch hoffentlich nur ein Test; oder verwendest du wirklich kein gksudo?

fleet_street schrieb:

Das war doch hoffentlich nur ein Test; oder verwendest du wirklich kein gksudo?

Das war natürlich ein Test, ich wusste ja schon vorher, dass das nicht gehen wird... Ist nur zur Sicherheit gewesen, falls ich mich irre. 😀

Trotzdem - wenn man gedit per Kommandozeile startet, führt es immer unweigerlich zu verwirrenden Warnmeldungen, egal auf welche Weise. Theoretisch funktioniert also beides gleich schlecht. Deshalb gebe ich das in der Regel auch so eher nicht mehr als Lösungsweg an, sondern bleibe möglichst bei Nano - das geht einfach immer.

aasche schrieb:

horstpenner schrieb:

Wenn in der Vorlage standardmäßig apt statt apt-get stünde,

sind Nutzer von Ubuntu 12.04 und 14.04 ausgeschlossen. Damit darf ueber diesen Vorschlag gerne ab 2019 nochmal ernsthaft nachgedacht werden.

apt ist in 14.04 definitiv vorhanden. 12.04 meine ich auch, kann ich aber nun nicht mit 100%-Gewissheit sagen. Ausgeschlossen würde also keiner.

Das größte Manko an apt: Es ist noch nicht "fertig", die Ausgaben kann/darf/soll man nicht "greppen" oder anderweitig verarbeiten. Daher ist es hier im Forum sinnvoller apt-get zu verwenden. Wir reduzieren hier doch immer auf den kleinsten gemeinsamen Nenner.

Zur Installation kann man es zwar gut verwenden, bei der Paketsuche und deren Filterung hört es dann aber schon auf. Ich persönlich nutze apt zum Installieren und zur halbautomatischen Aktualisierung. Bei allem anderen greife ich auf die apt-Alternativen zurück.

Also bei 14.04 geht es definitiv bereits und bereits im April fliegt 12.04 raus. Ich persönlich kann mich aber nich so mit den neuen Varianten anfreunden, sie bedienen sich anders (offiziell full-upgrade), beschränkter (minimalistisch), beim Suchen sogar deutlich langsamer, als hätte ich das fette alte Software-Center gestartet.

Ich habe keine Garantie, dass damit Fehlermeldungen kommen, zur Problemlösung also kaum geeignet. Am Ende weiß in Forum und Wiki dann gar keiner mehr, wieso mal apt-get und mal apt. Dennoch verwende ich es hier gelegentlich, um weniger zu tippen oder jemandem eben doch zu verdeutlichen, dass es einfach ist und aussieht. apt install sieht halt doch deutlich einfacher als sudo apt-get install aus. Puh, Text trotz Unity-Absturz am Handy noch fast komplett da - passiert beim Tippen nie, sonst sehr selten.

Die Suchfunktion stellt auch anders dar und sucht anders bzw. es gab da zwei Varianten, also Volltext oder nur Kurzbeschreibung - müsste ich am PC nachgucken. Insgesamt schränkt mich das also mehr ein und verwirrt noch mehr, im Support für Hilfesuchende ebenso. Nur meine Meinung. Vielleicht setzt sich die Mode nie durch oder kommt und geht - weiß man bei systemd auch nie sooo genau.

horstpenner schrieb:

Das würde jetzt schon deutlich mehr Sinn machen. Ich finde es jedenfalls ein Stück weit wichtig, dass eine Konsistenz da ist. Ich persönlich wäre deshalb dafür, apt im Wiki, wie auch im Forum möglichst immer zu verwenden, damit eine absolute Konsistenz da ist, und man apt-get wirklich nur dann liest, wenn es absolut nötig ist, weil der Befehl durch apt ausnahmsweise nicht abgedeckt wird.

Ich wäre dagegen.

Der User bekommt so immer wieder zu Gesicht, was eigentlich nicht das Interface ist, was auf ihn zugeschnitten ist, bekommt beispielsweise eventuell Lösungshinweise bei Fehlermeldungen nicht, etc.

Wann soll das der Fall sein, und welche Fehlermeldungen soll der Benutzer bekommen wenn er apt benutzt, aber nicht, wenn er apt-get benutzt?

… wenn ich sudo gedit sources.list eingebe, passiert auf TAB nichts. Ich muss also den ganzen Pfad kennen, … Mit sudo apt edit-sources ist das nicht nötig.

Ich denke, dass jemand, der manuell die sources.list ändern möchte/muss, auch deren Pfad kennen sollte. Und wenn er sich an den Pfad nicht erinnern kann, wird er vermutlich auch apt edit-sources nicht erinnern. Wenn er aber nur den im Beitrag vorgegebenen Befehl kopiert, so weiß er bei sudo gedit /etc/apt/sources-list zumindest, wo er die Datei, die er gerade fehlerhaft geändert hat, wiederfinden kann.

ist das eigentlich auch ein neues Feature, dass man neuerdings grafische Programme mit sudo öffnet 😈

Ich warte, bis die GTk-Version von apt rauskommt und mit gksu öffenbar ist. Am liebsten wäre mir ja sogar ein gksudo apt-get! (vielleicht zu Weihnachten...) Mal was andres: Das 13,5 GB ISO ist nicht herunterladbar. 😈 Vielleicht geht es (vor) Weihnachten wieder - dann braucht man auch kein apt(-get) mehr 😈 , falls da statt nur Lexika wirklich ca. 40 GB entpacktes Debian drauf ist. Dürfte dann für amd64 hoffentlich fast alles sein...

Frieder108 schrieb:

ist das eigentlich auch ein neues Feature, dass man neuerdings grafische Programme mit sudo öffnet 😈

[Scherzmodus]
Also ich gebe das im Forum immer so vor, um den Benutzern zu zeigen, wie man anschließend mit Hilfe des Wikis den angerichteten Schaden wieder behebt. 🤓
[/Scherzmodus]
Danke für den Hinweis, ich bin auf den Befehl meines Vorredners reingefallen.

ChickenLipsRfun2eat schrieb:

Das größte Manko an apt: Es ist noch nicht "fertig", die Ausgaben kann/darf/soll man nicht "greppen" oder anderweitig verarbeiten.

So ist es auch nicht gedacht, und der Fall, dass es "fertig" ist, wird nie eintreten. Wenn jemand "lustig" drauf ist, ändert er die Hintergrundfarbe der Progress- Bar, schreibt zusätzliches Zeug in die Ausgabe, oder ändert den Text um, wenn er meint, es sei für den User so eingängiger. Die grep- Problematik bezieht sich gerade deshalb aber nicht auf apt search, wenn man einen Substring eines Paketes pipelined, was hier beispielhaft mehrfach angeführt wurde, weil apt search natürlich immer in irgendeiner Form die Paketnamen ausgibt, da es genau sein Zweck ist.
Was natürlich passieren kann, ist eine andere Darstellung als erwartet, und zusätzlich(e)/weniger Zeilen/Text. Und genau letzteres ist auch der Fall, da die Beschreibung bei apt search in der nächsten Zeile steht. Deshalb muss man aktuell die Option -A 1 hinter grep stellen, wenn man unbedingt die Beschreibung des Paketes mit dazu braucht, und Informationen über das gefundene Paket nicht mit apt show PACKAGE0 im Nachhinein ausgeben möchte.(Wie es für den Neuling aber besser wäre, weil er dann die Herkunftsquellen, längere Beschreibung etc. in einer Übersicht aufgeführt bekommt, wodurch das Funktionsprinzip auch verständlicher dargestellt wird, und er beispielsweise auch nachlesen kann, wohin er sich bei Bugs wenden kann.)

Benno-007 schrieb:

Ich persönlich kann mich aber nich so mit den neuen Varianten anfreunden, sie bedienen sich anders (offiziell full-upgrade), beschränkter (minimalistisch), beim Suchen sogar deutlich langsamer, als hätte ich das fette alte Software-Center gestartet.

Ich dachte anfangs immer, dass dist-upgrade logischerweise Distributionsupgrade heißt, und da ich keine Betaversion wollte, habe ich es lieber gelassen.(War zwar nicht Ubuntu, sondern Debian, kommt aber im Prinzip aufs Gleiche raus.) Bei full-upgrade können solche Verwechslungen nicht mehr auftreten. Performanceunterschiede habe ich auf meinem PC bisher noch nicht feststellen können, wobei das natürlich von der Systemkonfiguration abhängen kann.

lionlizard schrieb:

Wann soll das der Fall sein, und welche Fehlermeldungen soll der Benutzer bekommen wenn er apt benutzt, aber nicht, wenn er apt-get benutzt?

Fehlermeldungen vielleicht nicht, aber zusätzliche Hinweise:

Frieder108 schrieb:

sudo apt update
.....
Es wurden 24,3 MB in 11 s geholt (2.058 kB/s).                                                                                                                                                            
Paketlisten werden gelesen... Fertig
Abhängigkeitsbaum wird aufgebaut.       
Statusinformationen werden eingelesen.... Fertig
Aktualisierung für 19 Pakete verfügbar. Führen Sie »apt list --upgradable« aus, um sie anzuzeigen.

sudo apt-get update
.....
Es wurden 24,3 MB in 12 s geholt (2.015 kB/s).                                                                                                                                                            
Paketlisten werden gelesen... Fertig

lionlizard schrieb:

Ich denke, dass jemand, der manuell die sources.list ändern möchte/muss, auch deren Pfad kennen sollte. Und wenn er sich an den Pfad nicht erinnern kann, wird er vermutlich auch apt edit-sources nicht erinnern. Wenn er aber nur den im Beitrag vorgegebenen Befehl kopiert, so weiß er bei sudo gedit /etc/apt/sources-list zumindest, wo er die Datei, die er gerade fehlerhaft geändert hat, wiederfinden kann.

So wie Du den Pfad geschrieben hast, ist das eher ein Gegenargument. Wenn er nämlich den richtigen Dateinamen kennt, wird er Schwierigkeiten haben, die Datei wiederzufinden. Ich benutze Linux ja selbst seit etwa 10 Jahren und erst seit 2 oder so muss ich den Dateipfad der sources.list nicht mehr nachschauen. Ich bin heilfroh, dass ich ihn jetzt wieder vergessen kann, damit in meinen Kopf mehr wichtigeres passt.

Edit: An apt edit-sources braucht er sich ja auch nicht zu erinnern, er braucht sich nur an apt erinnern und wissen, dass man Programmfunktionen so gut wie immer mit --help abrufen kann.

Ich bin heilfroh, dass ich ihn jetzt wieder vergessen kann, damit in meinen Kopf mehr wichtigeres passt.

Was gibt es da zu merken? Systemeinstellungen liegen immer in /etc, die von apt logischerweise in /etc/apt. Naheliegend, dass die sources.list dann dort ist. Und die Tab-Taste weiß das eh alles..

horstpenner schrieb:

Ich dachte anfangs immer, dass dist-upgrade logischerweise Distributionsupgrade heißt, und da ich keine Betaversion wollte, habe ich es lieber gelassen.(War zwar nicht Ubuntu, sondern Debian, kommt aber im Prinzip aufs Gleiche raus)

Aber auch nur im Prinzip. 😛

Bei Debian hat man die Wahl ob man die Version (unstable, testing, stable, oldstable, oldoldstable) oder den Codenamen (aktuell: sid, stretch, jessie, wheezy, squeeze) verwendet.

Mit Ausnahme von sid, was den Namen nicht umsonst trägt und niemals veröffentlicht werden wird, werden alle Codename später zu einer anderen Version, während die Versionsnamen gleich bleiben.

Wer also jetzt in den Quellen jessie eingetragen hat hat aktuell ein stable installiert, nach der Veröffentlichung von stretch bleibt er nach einem

# apt-get update
# apt-get dist-upgrade

bei der Version, hat dann aber kein stable mehr sondern ein oldstable.

Wenn im gleichen System aber nicht jessie sondern stable eingetragen ist wird nach der Veröffentlichung von Stretch durch ein

# apt-get update
# apt-get dist-upgrade

aus Jessie Stretch, so dass der Befehl hier durchaus ein Distributions-Upgrade ausführen würde.

Danke, dass Du mir das nochmal in Erinnerung gerufen hast. Ich glaube, dass das nach dem Release auch mal passiert ist, müsste von Stretch auf Lenny gewesen sein. Jedenfalls dachte ich anfangs, dass ich mit dist-upgrade nach testing wechseln würde ☺

horstpenner schrieb:

Ich glaube, dass das nach dem Release auch mal passiert ist, müsste von Stretch auf Lenny gewesen sein.

Etch (and a half) auf Lenny. 😈

Jedenfalls dachte ich anfangs, dass ich mit dist-upgrade nach testing wechseln würde ☺

Gut, das geht nur mit Mehrarbeit. ☺

# sed -i s/stable/testing/g /etc/apt/sources.list # Bei Nutzung des Codenamens wäre stable durch jessie und testing durch stretch zu ersetzen
apt update
apt dist-upgrade

(Um die Verwirrung komplett zu machen mit undokumentiertem apt-Befehl.)