Skip to content

RadioTux Sendung Dezember 2014

Weihnachtswunder

Durch den Flockenfall klingt süßer Glockenschall, ist in der Winternacht ein süßer Mund erwacht.

Herz, was zitterst du den süßen Glocken zu? Was rührt den tiefen Grund dir auf der süße Mund?

Was verloren war, du meintest, immerdar, das kehrt nun all zurück, ein selig Kinderglück.

O du Nacht des Herrn mit deinem Liebesstern, aus deinem reinen Schoß ringt sich ein Wunder los.

-- Gustav Falke (1853 - 1916)

Wir wünschen euch und euren Familien und Freunden ein besinnliches Weihnachtsfest und einen guten Rutsch ins neue Jahr!

Thema Startzeit
Intro 00:00:00
Musik "Holy Jolly Christmas von MonacoLorenzo" 00:00:27
Thema "Von chroot zu systemd-nspwan" 00:02:22
Musik "Jingle Bells von Dirk Becker" 01:01:08
Fortsetzung "Von chroot zu systemd-nspwan" 01:04:22
Musik "Christmas Together von Leo Bowers" 01:24:51
Thema "elementary OS" 01:28:26
Abmoderation 02:38:29
Musik "We Wish You a Merry Christmas von Antoniogarciavazquez" 02:39:43
Outro 02:41:34

Shownotes

2014-12-24.RadioTux.Magazin.Dezember2014.mp3 2014-12-24.RadioTux.Magazin.Dezember2014.ogg 2014-12-24.RadioTux.Magazin.Dezember2014.m4a 2014-12-24.RadioTux.Magazin.Dezember2014.flac 2014-12-24.RadioTux.Magazin.Dezember2014.opus <a href="http://archiv.radiotux.de/sendungen/radiotux/2014-12-24.RadioTux.Magazin.Dezember2014-low.mp3 class="nopodcast">MP3-Low-Version

Trackbacks

hoersuppe.de am : PingBack

Die Anzeige des Inhaltes dieses Trackbacks ist leider nicht möglich.

Kommentare

Ansicht der Kommentare: Linear | Verschachtelt

detlef am :

Also ich bin seit debian 5, oder ubuntu 7.04 oder sowas überzeugter Linuxer, und ich persönlich wäre schon der meinung, wenn sich Linux entgültig etablieren soll, dann mit SystemD. Wenn dann noch ein System für alles standart währe, ist das doch ne feine Sachen, oder?

Dirk Deimeke am :

Sehr gute Folge, vielen Dank!

SystemD löst meiner Meinung nach leider nicht das Problem von Abhängigkeiten, was ja gerade die besondere Stärke von Linux (und Unix) ist. Die Hauptarbeit einer Distribution liegt meiner Meinung nach nicht darin, Programme zusammenzustellen, sondern die Abängigkeiten so aufzulösen, dass nur eine Version einer Bibliothek vorhanden sein muss.

Wenn mehrere Versionen unterstützt werden, sind wir wieder bei der DLL-Hell von Windows oder benutzen statisch übersetzte Programme. Beide Varianten führen dazu, dass Unix und Linux einen Grossteil ihrer Eleganz verlieren.

Johannes am :

Ich verstehe die Vision von dem "einen Linux" ohne Distributionen nicht ganz. Soll dann auf den Microcontrollern die gleiche Software laufen wie auf meinem Desktop? Gibt es dann keine mächtigen, schlanken, speziallisierten, modernen oder stabilen Varianten mehr von Linux? Wohin geht dann diese Vielfalt, wo wird sie abgebildet?

Ich bin nicht dagegen, Ich verstehe es nur nicht.

Leszek am :

Nein auf Mikrocontroller soll nicht automatisch die gleiche Software laufen wie auf dem Desktop. Es kann aber. Ein Image das nicht nur einen sondern mehrere Mikrocontroller dank des Image Konzepts und btrfs subvolumes unterstützt ist dann die Idee. Ein Image kann so ARM libs und MIPS libs mitbringen und je nach Plattform, das richtige booten.

Hauptzweck ist aber erst einmal der Desktop und nicht minimale Mikrocontrollersysteme.

Leszek am :

@Dirk

Durch die Systemd Vision würde der Autor einer Software das Abhängigkeitsproblem lösen. In der Realität nutzt halt jeder Programmier andere Bibliotheken oder Versionen dieser. Das btrfs deduplication würde hier das Abhängigkeitsproblem durch doppelte libs minimieren und gleichzeitig gäbe es keine Probleme mehr z.B. auf einem stabilen Debian neuere Software zu installieren. Das Problem, das man dann eine Abhängigkeit nicht kriegt fällt dann weg. Etwas zu Lasten des Speicherplatzes, aber dank btrfs dedup sollte das im idealfall sehr sehr wenig sein.

Eine dll hell oder statische Programme wären also nicht zwingend die Konsequenz der Vision und ich würde sogar sagen stehe dem entgegen.

Dirk Deimeke am :

@Leszek

Wenn ich die Bibliothek in unterschiedlichen Versionen zwei Mal auf dem Rechner und - fast noch spannender - zwei Mal im Speicher habe, dann nutzt mir weder Deduplikation noch eine andere Massnahme, da die beiden ja unterschiedlich sind.

Das Konzept von Shared Libraries ist ja gerade deswegen so toll, weil ich nur eine Bibliothek im Speicher halten muss, die mehrere Programme brauchen können (Nachteil ist, dass ich den Speicherverbrauch eines Programmes nur sehr ungenau bestimmen kann).

Dedup funktioniert nur dort, wo mehrere Programme die gleichen Bilbliotheken einsetzen.

So ein Fall wie Heartbleed führt im schlimmsten Fall sogar dazu, dass ich alle verschiedenen Inkarnationen von OpenSSL patchen muss und nicht nur eine, die systemweit eingesetzt wird.

(Das Threading der Kommentare funktioniert nicht mehr, ist das gewollt?).

Leszek am :

Ja da hast du Recht Dirk. Aber das Problem besteht zu einem Großteil bereits heute. (Steam Spiele z.B. bringen alle ihre eigenen Ogg vorbis libs mit) In Sachen sharen kann man mit dedup aber schon einiges hinkriegen. Binary diffs ist hier das Stichwort. Wenn das auf der Platte geht, sollte es auch im Speicher gehen.

Aber natürlich stimmt es beim Updaten von einem OpenSSL z.B. das dann viele runtime Images geupdatet werden müssten. Natürlich aber auch nur wenn man viele unterschiedliche runtimes installiert hat. Das ist ein Problem dass man bei der Implementierung oder der Vision angehen muss. (vielleicht werden solche libs doch vom paketmanager übernommen)

Dirk Deimeke am :

Leszek, dass es geht, steht für mich völlig ausser Frage und ich finde den Ansatz auch gut, Linux einmal ganzeheitlich anzuschauen und alle Möglichkeiten auszuschöpfen, inklusive Kernel, SystemD, Filesystem und Volumemanager. Ich bin mir nur nicht sicher, wie viel Performance das frisst (BTRFS ist noch ziemlich am Anfang und auch ZFS war am Anfang noch nahezu unbenutzbar).

Bezüglich Steam gebe ich Dir Recht. Kommerzielle Hersteller gehen diesen Weg, um nicht für jede Distribution ein eigenes Paket zu schnüren.

Ich bin in jedem Fall gespannt, was die Entwicklung bringen wird.

Paul Hein am :

Wollte nochmal zu elementary OS Freya ansprechen. Die Entwickler selbst wünschen sich noch keine Tests zu der Beta version, daher schonmal die richtige Entscheidung. Jedoch hatte ich selbst mal die Beta 1 getestet. Mittlerweile sind sie bei der Beta 2 angekommen. Und es ist genial zu benutzen. Ich persönlich weiß noch nicht genau, aber sie wollten Services wie Google, Facebook, Flickr, Owncloud etc. in Online Konten nativ einbinden. Vllt funktioniert es mittlerweile. Was das update von Luna auf Freya betrifft, wollten die macher selbst erstmal gucken ob es überhaupt klappt und wenn nicht werden sie davon abraten, ein upgrade zu machen. Ansonsten ist dies natürlich das Ziel schnell und einfach ein Upgrade durchzuführen. Aber was beeindruckend an ihrem OS ist, ist die geschwindigkeit, die sie haben. Kein OS reagiert so flott, so smooth, so schön. Einfach gut. Auf jedenfall lohnt es sich sie via bountysource zu unterstützen.

Unter http://stats.elementaryos.org/ kann man auch die aktuelle Entwicklung( Bug crushing ) verfolgen.

Ingo Ebel am :

@Dirk; Eine DLL Hölle sehe ich nicht. Da die Programme ja gekapselt sind ist das dann wie bei Mac OS dass jedes Programm seine eigenen Teilwelt hat und nicht auf ein gemeinsames Verzeichnis zugreift in dem unterschiedliche DLLs mit Versionen rumliegen um die sich keiner kümmert. In Zeiten wo Festplatten und RAM groß genug sind ist es auch kein Problem wenn Daten doppelt vorhanden sind. Problematisch ist natürlich dass dann verschiedene Libs mit unterschiedlichen Sicherheitslücken rumliegen um die sich keine zentrale Instanz kümmert. Das ist bei jetzigen Distros natürlich viel besser.

PS: Keine Ahnung warum das mit dem Einrücken der Kommentare nicht geht.

Dirk Deimeke am :

Das sehe ich anders.

Deine Argumentation kann ich für private oder Entwicklermaschinen nachvollziehen. Wenn Du hunderte von Servern (virtualisiert) betreibst, macht sich der Overhead deutlich bemerkbar.

IT Blogger am :

Ich kenne mich nicht so gut mit SystemD und internen Mechanismen von Linux aus. Aber aus der Sicht von einem Linux Fan (auf Hobby-Ebene):

Linux fehlt Automatismus oder bessere Kompatibilität mit älteren Versionen. Aus meiner Erfahrung: Wenn eine Migration von Ubuntu 10 auf Ubuntu 14 gemacht wird, funktionieren viele Programme nicht mehr, weil "ein Paket xy ist nicht kompatibel mit Ubuntu 14 " oder "In Ubuntu 14 gibt es eine Funktion nicht mehr, in einem Script soll deswegen eine neue Funktion verwendet werden, die ganz anders implementiert ist".

Upgrades, Migration, etc. - immer viel Aufwand, weil alte Pakete mit neuen nicht kompatibel sind und sich Funktionen ständig ändern.

maltris am :

Die Qualität ist wirklich unter aller Sau. Habe bei der dritten Minute wieder abgeschalten.

Kommentar schreiben

Markdown-Formatierung erlaubt
Umschließende Sterne heben ein Wort hervor (*wort*), per _wort_ kann ein Wort unterstrichen werden.
Standard-Text Smilies wie :-) und ;-) werden zu Bildern konvertiert.
Die angegebene E-Mail-Adresse wird nicht dargestellt, sondern nur für eventuelle Benachrichtigungen verwendet.

Um maschinelle und automatische Übertragung von Spamkommentaren zu verhindern, bitte die Zeichenfolge im dargestellten Bild in der Eingabemaske eintragen. Nur wenn die Zeichenfolge richtig eingegeben wurde, kann der Kommentar angenommen werden. Bitte beachten Sie, dass Ihr Browser Cookies unterstützen muss, um dieses Verfahren anzuwenden.
CAPTCHA

Formular-Optionen
tweetbackcheck