News Ubuntu 22.10 („Kinetic Kudu“): Linux 5.19 und Gnome 43 nicht nur für die Ein- und Umsteiger

Meint ihr wir werden es noch erleben dass Ubuntu seine Pakete standardmäßig über HTTPS bezieht?
Ja wir haben Signaturen um die Manipulation zu verhindern, aber seit das ganze Netz auf TLS umstellt und Zertifikate gratis zu haben sind, halte ich es für guten Stil keine Daten mehr im Klartext zu übertragen.
Jedes bisschen an Metadaten und Infos was man schützen kann sollte man auch schützen.
 
  • Gefällt mir
Reaktionen: Nine-tailed Fox
0815burner schrieb:
Ausserdem, wie soll ein Normalsterblicher sowas im Vorfeld überprüfen?
Der Normalsterbliche bliebt ja auch bei der LTS Version.

Ohne manuelle Änderungen, informiert einem die LTS Version nicht mal, dass es eine neue STS Version gibt. Die Idee ist es eben neue Dinge wie z.b. PipeWire in den STS Versionen einzuführen, aus den Bugs und Fehler die da auftauchen, kann man lernen, und dann versuchen, dass bei Upgrade von LTS zu LTS diese Fehler nicht mehr auftreten.

Geht natürlich nur, wenn man solche Fehler an Canonical meldet. Die müssen wissen, dass es ein Problem gibt bevor man es beheben kann.
 
Ich bin froh Linux Mint zu nutzen.
Da ist snapd noch nicht zum Standard geworden.
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: polyphase
Bin mir da nicht so sicher mit der LTS. Der Normalo wird wohl eher bei Windows landen. Der, der Ubuntu ausprobieren will nimmt erstmal das Aktuellste. Die STS informiert aber zum Wechsel zur LTS, muss sie ja da der Support ausläuft. Dann ist man auf einmal in der LTS Upgrade-Schiene und hört und sieht 4 Jahre nix. Und spätestens dannn fällt der User auf die Nase.
Gerade wenn man nicht der Profi ist will man ja das Bewährte behalten und bleibt bei der bisher guten Konfig. Da sollte einfach was an der Setup-Routine gemacht werden! Warnhinweis, automatisch neuinstallieren und bei erstem Boot die 2 Versionen nebeneinader anzeigen, oder einfach drüberbügeln.
So fand ich es jedenfalls nicht gut (und über solche Sätze ärgere ich mich im Berufsleben maßlos. Aber hier ist er einfach angebracht).

P.S.: Im zweiten Anlauf, mit Akzeptanz der beiden Konfig Änderungen (Scite & /etc/mime.types) lief es problemlos durch. Willkommen kinetic!
 
Ein installiertes Snap kann systemweit von jedem User benutzt werden. Ich frage mich manchmal schon woher all die Snap-Falsch-Informationen kommen.
 
  • Gefällt mir
Reaktionen: @mo
0815burner schrieb:
Ich versteh denn Sinn dieser Optionen nicht.
Ja, da geb ich dir Recht.
Sinn macht die Option nur wenn sie auch wirklich reibungslos funktioniert.

Könnte mir vorstellen das sie für Server sinnvoll ist, aber dann sollten sie sie beim Desktop lieber ganz weglassen. 🤷🏻‍♂️

Hab nen schönen Sonntag.
 
duckyisshiny schrieb:
Was ist das Problem mit snap?
Squashfs, die komprimierten Pakete und das jeder Hans und Franz dort Pakete hochladen kann.
Das ganze ist insgesamt viel zu lahmarschig.
Ein absolutes No-Go.

Ich habe es auch unter Ubuntu jedesmal deinstalliert.
 
Zuletzt bearbeitet:
Mmn sind eher der proprietäre Snap-Server ohne Möglichkeit externer Repositories + Useraccount Zwang im Softwarecenter die größten Probleme mit Snap, denn die sind nicht technischer Natur.

Für mich Grund genug das definitiv zu meiden, die technischen Probleme mögen sich lösen oder nicht...
 
riloka schrieb:
Ja wir haben Signaturen um die Manipulation zu verhindern, aber seit das ganze Netz auf TLS umstellt und Zertifikate gratis zu haben sind, halte ich es für guten Stil keine Daten mehr im Klartext zu übertragen.
Naja. Pakete als http auszuliefern hat den riesen Vorteil das man problemlos und irgendwelche umständlichen Konfigurationen Pakete in HTTP-Proxies (oder auch Mirrors) zwischenspeichern kann, was gerade dann praktisch ist, wenn man mehrere Rechner aktualisieren bzw. Lastverteilung machen will.
Außerdem kostet Verschlüsseln/Entschlüsseln Performance und braucht auch mehr Energie (nicht viel, aber es läppert sich halt).

riloka schrieb:
Jedes bisschen an Metadaten und Infos was man schützen kann sollte man auch schützen.
Wenn Dir das wichtig ist, kannst Du es ja auch so konfigurieren.
 
andy_m4 schrieb:
Naja. Pakete als http auszuliefern hat den riesen Vorteil das man problemlos und irgendwelche umständlichen Konfigurationen Pakete in HTTP-Proxies (oder auch Mirrors) zwischenspeichern kann, was gerade dann praktisch ist, wenn man mehrere Rechner aktualisieren bzw. Lastverteilung machen will.
In welcher Umgebung hat man zwar einen grossen Bedarf an Ubuntu Paketen bei niedriger Bandbreite und gleichzeitig keine Möglichkeit einen lokalen Spiegelserver anzubieten? Halte das für wenig realistisch.

andy_m4 schrieb:
Außerdem kostet Verschlüsseln/Entschlüsseln Performance und braucht auch mehr Energie (nicht viel, aber es läppert sich halt).
In our production frontend machines, SSL/TLS accounts for less than 1% of the CPU load, less than 10 KB of memory per connection and less than 2% of network overhead. Many people believe that SSL/TLS takes a lot of CPU time and we hope the preceding numbers will help to dispel that.
Sagt Google und ich denke dass kann man vom Einfluss her nu wirklich ignorieren.

andy_m4 schrieb:
Wenn Dir das wichtig ist, kannst Du es ja auch so konfigurieren.
Es geht darum den Standard umzudrehen. Verschlüsselung an, wer es anders haben will stellt es ab.
Ein sehr grosser Anteil der Spiegelserver inklusive den Standardservern hat keine ordentlichen TLS Zertifikate.
Launchpad PPAs zum Beispiel.
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: Nine-tailed Fox
@mo schrieb:
Wer nutz denn freiwillig das Softwarecenter?
ich eigentlich manchmal gerne. aber bestimmt jeder der eine art App-Store gewohnt ist/erwartet.
 
Ich würde gerne KDE's Muon mehr nutzen, aber die weigern sich hartnäckig andere Formate zu unterstützen als DEBs.
 
riloka schrieb:
In welcher Umgebung hat man zwar einen grossen Bedarf an Ubuntu Paketen bei niedriger Bandbreite und gleichzeitig keine Möglichkeit einen lokalen Spiegelserver anzubieten? Halte das für wenig realistisch.
Naja. Im Prinzip lohnt es sich schon bei zwei Rechnern Pakete zwischenzuspeichern. Der zweite Rechner muss nicht mal ein physischer Rechner sein. Kann auch eine VM sein oder sonstwas.
Die Tatsache das also mehr als ein ubuntu-System irgendwo vorkommt ist alles andere als unrealistisch.
Einen Spiegelserver zu machen ist auch nicht immer angezeigt. Weil oftmals wird ja auch nur ein Teil der Pakete benötigt. Dann gleich das gesamte Repository zu spiegeln wäre in vielen Fällen total überzogen.
So ein lokaler HTTP-Proxy ist halt einfach und unkompliziert eingerichtet.

Und egal ob Spiegelserver oder Proxy, kommt https ins Spiel wird das alles komplizierter.

riloka schrieb:
Sagt Google und ich denke dass kann man vom Einfluss her nu wirklich ignorieren.
Hab ja selbst gesagt das das nicht viel ist, aber es läppert sich halt.

riloka schrieb:
Es geht darum den Standard umzudrehen.
Wo besteht denn nun der riesen Gewinn dabei?

riloka schrieb:
Ein sehr grosser Anteil der Spiegelserver inklusive den Standardservern hat keine ordentlichen TLS Zertifikate.
Launchpad PPAs zum Beispiel.
Mit anderen Worten den Standard zu ändern macht in der Praxis mehr Probleme als das es irgendwie was bringt. Bitte. Damit hast Du Dir Deine Frage selbst beantwortet.
 
Mir als Privatanwender würde es trotzdem ein sichereres Gefühl geben wenn https der Standard nach der Installation wäre.
Weiß so nie ob ich es ändern oder besser bei http belassen sollte. Für den Fall das Canonical sich evtl schon was dabei gedacht hat. 🤷🏻‍♂️
In der Regel belasse ich es dann bei http.

Was würden die Profis empfehlen?
 
andy_m4 schrieb:
Wo besteht denn nun der riesen Gewinn dabei?
Encryption by Default hat den Vorteil dass man es nicht aktiv setzen muss und damit die meisten Standardanwender die eh nix ändern vor unnötigen Leaks bewahrt. Als Standardfall denke ich sind HTTP-Caches eher selten.

andy_m4 schrieb:
Mit anderen Worten den Standard zu ändern macht in der Praxis mehr Probleme als das es irgendwie was bringt. Bitte. Damit hast Du Dir Deine Frage selbst beantwortet.
Ich hatte auch keine nennenswerten Probleme als nach den Veröffentlichungen von Snowden und der Inbetriebnahme der LetsEncrypt CA die Webdienste großflächig TLS ausgerollt haben.
Das is relativ einfach geworden und im Caddy Server werden sogar automatisch Zertifikate geholt.
TLS auf dem Server einzurichten ist relativ einfach und je nach Software sogar mit LE Skripten direkt möglich inklusive Konfiguration und Erneuerung.
Damit ist der Aufwand gering und damit das Verhältnis Aufwand zu Nutzen deutlich auf Seiten des Nutzens.
 
Zurück
Oben