Tracking ist ein Phänomen, das meistens mit der Werbeindustrie und dem Internet in Verbindung gebracht wird. Das Phänomen betrifft jedoch auf Apps auf Mobilplattformen und immer mehr auch den Desktop. Litte Snitch zeigt das wahre Ausmaß auf dem Mac.

Dier Netzwerkverkehr hiesiger Systeme wird mittels Little Snitch gefiltert (siehe: Little Snitch 4 - macOS-Traffic im Blick). Nicht weil man damit ausgefeilte Schadsoftware bekämpfen kann - diese weiß sich schließlich zu tarnen - sondern, weil die kleine Petze jene Entwicklersünden aufzeigt um die es hier gehen soll.

Ausgefeiltes Tracking ist vor allem ein Internetphänomen (siehe: Tracking - Wenn dein eigener Browser dich verfolgt und allgemein Aktivitäten im Internet schützen) aber weil die Module leicht zu integrieren sind, greifen immer mehr Entwickler auf diese zurück. Im mobilen Bereich zeigt Exodus das Ausmaß der Verfolgung. Neben zahlreichen Verbindungen zu sozialen Netzwerken & Co wird gerne auf Analysetools zur Statistikerhebung und s. g. Tool zum "crash reporting" verwendet. Das ganze hat grenzenlose Ausmaße angenommen, manche Apps integrieren gleich mehrere dieser Tools.

"Crash reporting", also zu deutsch in etwa Absturzbericht, hört sich wunderbar technisch an und der unbedarfte Nutzer mag da einen Sinn hinter sehen. Die meisten dieser Werkzeuge können aber viel mehr. Verbreitung und Nutzungsdaten lassen sich damit mühelos erfassen. Viele verbreitete Dienste wie beispielsweise Crashlytics oder HockeyApp gehören zudem zu großen IT-Konzernen und reichern potenziell deren Datenpool an. Die Kaufpreise hat man ja nicht umsonst investiert.

Auf dem Desktop kann man sich mittels Werkzeuge wie Little Snitch oder auch einem Pi-Hole gegen viele dieser Spionagewerkzeuge schützen, mobil sieht das ganz anders aus. Insbesondere bei mobilen Datenübertragungen sind auf den hochgradig geschlossenen Systemen den Kontrollmöglichkeiten enge Grenzen gesetzt.

Natürlich kann man nachvollziehen, dass App-Entwickler Daten haben wollen um ihre Entwicklung benutzerorientiert voran zu treiben. Aber ist es so schwer in den Einstellungen ein Opt-out anzubieten? Hier fehlt jedes Problembewusstsein bei den Entwicklern. Daten werden erhoben, weil man es kann, weil die Dienste nichts kosten und weil die Entwicklungsbausteine verfügbar sind. Benutzerinteressen spielen keine Rolle.

Man sollte dabei auch nicht dem Glauben erliegen, dass dieses Problem nur Apps und Programme, die eh kein vernunftbegabter Anwender nutzt, betrifft. Die jüngst bekannt gewordene Datenerhebung durch den - bisher als vertrauenswürdig - bekannten Messenger Wire (siehe: Verschlüsselte (Video-)Kommunikation mit Wire) zeigt das Ausmaß der laxen Handhabung des Themas bei vielen Entwicklern. Unter macOS haben zahlreiche Apps solche Tracker integriert, auf den hiesigen Systemen geschätzt ein Drittel der Drittprogramme. Im mobilen Bereich sieht das noch viel schlimmer aus. Interessant wäre hier mal Linux unter die Lupe zu nehmen.

---

Bilder:

Einleitungs- und Beitragsbild von kreatikar via pixabay / Lizenz: CC0 Creative Commons

Retrocomputing ist in. Wer, wie ich, seine ersten Erfahrungen mit Computern in den 80er Jahren gemacht hat, ist für dieses Thema besonders empfänglich. Dabei ist der Blick zurück häufig ziemlich verklärt und die alte Zeit wird als die bessere angesehen. Dabei wird übersehen, dass früher nicht alles eitel Sonnenschein war.
Der folgende Artikel bezieht sich allein auf meine Erfahrungen, welche sehr stark von Heimcomputern und PCs mit MS-DOS geprägt wurden und weniger von Konsolen. Ich habe exemplarisch das Jahr 1992 als Grundlage des Artikels genommen, wobei ich auch spätere Jahre (bis ca. 1997) anspreche um bestimmte Sachverhalte zu verdeutlichen.

Warum ausgerechnet 1992? Weil ich in diesem Jahr meinen ersten PC gekauft habe und zusätzlich weil zu diesem Zeitpunkt der Computermarkt noch sehr viel heterogener war als heute. Neben den PCs waren noch sehr häufig Heimcomputer (Amiga, Atari ST oder C64) im Einsatz und viele Spiele und Programme wurden noch für mehrere Plattformen entwickelt. Zudem war der Leistungsunterschied zwischen den PCs und den Heimcomputern noch nicht so groß, obwohl Letztere mit der breiten Verfügbarkeit von 386er CPUs und VGA-Grafikkarten ins Hintertreffen gerieten.

Hier mal einige Punkte, welche meine Sicht auf die damalige Hardware und Software aufzeigen soll:

Die Hardware damals war sehr teuer

Mein erster PC (Den ich mir von meinem Konfirmationsgeld gekauft hatte) kostete damals im Mai 1992 2000 DM. Die Ausstattung (siehe obigen Kasten) war eher unterdurchschnittlich und von High-End weit entfernt. Der PC hatte zwei Diskettenlaufwerke und keine (!) Soundkarte. Diese habe ich mir im Oktober 1992 zusammen einem CD-ROM-Laufwerk angeschafft. Rechnet man den Kaufpreis von 2000 DM auf die heutige Kaufkraft um, kommt man auf ca. 1.650€ (Errechnet mit DM-Euro-Rechner). Für diesen Betrag bekommt man heute einen ziemlich guten PC inklusive eines guten Monitors.

Damals gab es eine Faustregel:

Für einen brauchbaren PC mit Monitor musste man mindestens 2000 DM ausgeben, für weniger Geld gab es nur veraltete Hardware, welche nicht mehr zeitgemäß war und moderne Programme mehr schlecht als recht ausführen konnte. Wer mehr fühlbare Leistung benötigte oder einen schnellen Mac, Amiga oder Atari wollte, musste deutlich mehr als 4000 DM ausgeben. High-End-PCs, Macs oder Unix-Workstations kosteten über 10000 DM.
Vergleicht man die Situation mit heute, stellt sich die Gegenwart quasi als Paradies dar:
Einsteiger-PCs bekommt man für unter 300 €, Einsteiger-Spiele-PCs für 500 € (jeweils ohne Monitor). Ab 1000 € bekommt man PCs, die für alle Anwendungen uneingeschränkt tauglich sind, ein High-End-PC mit 16 Kernen ist ab 2000 € verfügbar. Dabei reicht selbst die Rechenleistung eines 300 €-PCs locker aus um alle alltäglichen Aufgaben problemlos zu erledigen.

Der Rechner war immer zu schlecht ausgestattet

Die CPU meines ersten PCs hatte eine 386SX-CPU, was heißt, dass die CPU intern mit 32bit-breiten Registern arbeitete, aber nur einen 16 Bit breiten externen Datenbus und einen 24 Bit breiten Adressbus hatte (Der 386DX war durchgängig 32bit). Dadurch war er deutlich langsamer als ein 386DX mit gleicher Taktfrequenz (ca. 25%) und der maximale Speicherausbau war auf 16 MB beschränkt. Er war im Grunde nicht schneller als eine gleich getaktete 286-CPU, hatte aber den Vorteil, dass er ein echter 32bit-Prozessor war und dadurch echte 32bit-Betriebssysteme ausführen konnte. Schon direkt nach dem Kauf des PCs konnte ich viele Spiele nur mit Einschränkung spielen (Wing Commander 2 lief z.B. sehr zäh), weshalb das Mainboard relativ schnell gegen eines mit einem 386DX40 ersetzt wurde.
Ein weiteres Problem war, dass der verfügbare Speicher (Egal ob RAM oder HDD) immer zu klein war. Windows benötigte mindestens 1 MB RAM, besser waren 2 MB. Bei OS/2 waren schon mindestens 4 MB notwendig, wobei man damit nicht viel mit dem System anfangen konnte, da es permanent am Swappen war. Besser waren 8 MB oder sogar 16 MB und das zu Zeiten wo in den PCs gerade 4 MB zum Standard wurden. Es dauerte noch Jahre bis PCs den Speicherhunger moderner Betriebssysteme befriedigen konnten und das System sich mangels RAM nicht mehr selbst ausgebremst hat.
PC-Spiele wie Comanche und DOOM benötigten 1993 mindestens 4 MB RAM, um überhaupt zu starten und verlangten nach mindestens einem 486SX25 um auf spielbare Frameraten zu kommen. Oben genannter 386DX40, den ich zu diesem Zeitpunkt besaß, war für DOOM schon viel zu langsam und ich hatte nur die Wahl zwischen „Guckschlitz“ oder „Riesenpixel“.

Noch schlimmer sah es bei der Festplatte aus:

Meine damalige 40 MB Platte war im Grunde immer voll. Ich habe mir damals Wing Commander 2 von einem Freund ausgeliehen und dieses benötigte mit „Speech Pack“ 36 MB. Neben der DOS-Installation war also kein Platz mehr für andere Dinge. Ich war also permanent am Installieren und Kopieren. Die verfügbaren Festplattenkapazitäten stiegen zwar rasant an und die Kosten fielen ebenso rasant, aber im gleichen Maß stieg auch die Größe der Programme an.

Schaut man sich heute die Situation an, leben wir im Luxus:

4 GB RAM sind selbst in Billigrechnern verbaut, 8 GB Standard. Festplatten unter 1 TB Kapazität bekommt man fast nirgends mehr zu kaufen bzw. sind im Vergleich zu größeren Festplatten deutlich teuer. Die meisten Anwender kommen auch mit „kleinen“ 256 GB SSDs gut zurecht. Man muss heutzutage nur noch selten mit dem Plattenplatz haushalten. Mein beiden PCs (Desktop und Notebook) haben jeweils 16 GB RAM und eine 256 GB SSD und ich komme trotz meines Bioinformatikstudiums selten in die Situation, dass dieser Speicher nicht mehr ausreicht (Ein Beispiel dafür folgt in den nächsten Tagen).

Die Ergonomie der Bildschirme war grausam

Mein damaliger PC wurde mit einem 14-Zoll Monitor ausgeliefert, der gerade mal eine Auflösung von 640×480 Bildpunkten bei 60 Hz schaffte. Die Bildqualität war mies und ich habe den Monitor auch nur ertragen, weil ich nichts Besseres kannte bzw. mir nichts besseres leisten konnte. Zum Spielen reichte der Monitor locker aus, da man bis Mitte der 90er eh meistens in der VGA-Auflösung mit 320×200 Bildpunkten gespielt hat. Bei solch einer geringen Auflösung spielte es keine große Rolle, wenn die Pixel etwas „matschig“ aussahen.
Ein Problem wurden die billigen PC-Monitore zu dem Zeitpunkt als Windows zum Standard wurde. Eine Auflösung von 640×480 Bildpunkten genügte für einfache Arbeiten, wer aber Windows wirklich benutzen wollte, musste mindestens eine Auflösung von 800×600 Bildpunkten benutzen und da wurde es bei den 2000 DM-PCs ziemlich übel. Mein 14-Zoll-Monitor konnte diese Auflösung z.B. nur mit 56 Hz darstellen, eine höhere Auflösung (1024×768) war nur mit 43 Hz im Interlaced-Modus möglich. Also nichts, was auch nur ansatzweise als ergonomisch zu bezeichnen wäre. Ein guter Monitor kostete damals mehr als 1000 DM, einen Betrag, den ich mir nicht leisten konnte.

Wichtig wurde die Auflösung des Monitors für mich, als ich damals Linux entdeckte:

Während man Windows 3.1 und später Windows 95 relativ problemlos mit einer Auflösung von 640×480 Bildpunkten betreiben und mit 800×600 Bildpunkten gut arbeiten konnte, war daran unter Linux mit einer grafischen Oberfläche nicht zu denken. Das lag daran, dass X11 bzw. das „X Window System“ zuerst auf professionellen Unix-Workstations eingesetzt wurde und dort Auflösungen unter 1024×768 Bildpunkten quasi nicht existent waren. Also wurden die Programme bzw. die Widgets der eingesetzten Toolkits auch nicht für kleinere Auflösungen optimiert (Siehe Collage rechts). Einer der Hauptgründe warum ich mir einen besseren Monitor zulegte, war diesem Umstand geschuldet.
Heutzutage sitzen die allermeisten PC-Besitzer vor einem flimmerfreien und hochauflösenden TFT-Monitor. Selbst bei Billig-Notebooks bekommt man mindestens eine Auflösung von 1366×768 Bildpunkten, Standard ist aber die Full-HD-Auflösung mit 1920×1080 Bildpunkten.

Die richtige Wahl der RAM-Verwaltung war ein Abenteuer

Im Jahr 1992 gab es für Heimanwender im PC-Bereich im Grunde nur ein Betriebssystem und zwar DOS. Ich nenne es absichtlich nicht MS-DOS, da z.B. mein damaliger PC mit Digital Research „DR DOS 5.0“ ausgeliefert wurde. Es gab damals noch ein gutes Dutzend weitere kompatible Versionen von verschiedenen Herstellern:

https://en.wikipedia.org/wiki/List_of_disk_operating_systems

Es gab zwar modernere und bessere Alternativen (Windows NT, OS/2 oder ein kommerzielles Unix), diese benötigten aber einen leistungsfähigen Rechner und/oder kosteten ein Vermögen in der Anschaffung.
Das größte Problem mit DOS war die Trennung des Speichers in verschiedene Bereiche. Für jemanden, wie mich, der vorher einen ATARI ST benutzt hat, war das eine neue Welt, da es beim ST keine Trennung des Speichers gab. Der ST konnte schon 1985 mit bis zu 4 MB RAM ausgestattet werden und der RAM war einfach verfügbar. Der wichtigste Speicherbereich für DOS war der Speicherbereich bis 640 kB, welcher von den normalen DOS-Programmen benutzt wurde. Ich spare mir hier weitere Details und verweise auf den passenden Wikipedia-Artikel:

https://en.wikipedia.org/wiki/Conventional_memory

Speicher oberhalb von 1 MB wurde auf hauptsächlich auf zwei Arten angesprochen:

Ältere Programme benötigten EMS-Speicher als zusätzlichen Speicher, neuere wollten aber XMS-Speicher (HIMEM.SYS, notwendig z.B. für Windows 3.x) . Dazu kamen dann noch Programme, welche den Speicher direkt adressieren konnten und einen sogenannten DOS-Extender einsetzten, welche aber nicht kompatibel zu EMS bzw. „EMM386.EXE“ waren (Emulierter EMS-Speicher war nicht mehr als XMS-Speicher verfügbar). Also fingen wir DOS-Benutzer an mit verschiedenen Boot-Disketten zu hantieren, welche unterschiedliche Konfigurationen vorhielten („CONFIG.SYS“ und „AUTOEXEC.BAT„). Auf der Festplatte lag die Konfiguration, welche von den meisten Programmen unterstützt wurde. Es wurde quasi zum Sport die beste Konfiguration, mit dem meisten verfügbaren Speicher unterhalb von 640 kB zu erstellen. Die diversen Hersteller von DOS-Betriebssystemen warben damals auch ziemlich offensiv mit diesen Zahlen. Mit dem Erscheinen von MS-DOS 6.0 konnte man sogenannte „Boot-Menüs“ anlegen, welche es ermöglichten beim Booten die jeweils benötigte Konfiguration in den Dateien „CONFIG.SYS“ und „AUTOEXEC.BAT“ auszuführen. Dadurch wurde der Einsatz von Bootdisketten hinfällig, aber nicht das Basteln an den Konfigurationen.
Als größter Fallstrick sollten sich Spiele erweisen. 1992 wurde z.B. „Ultima 7“ veröffentlicht, welches einen eigenen Speichermanager implementierte und nicht mit EMS und XMS zurechtkam. Dazu kam noch, dass sehr viel Speicher unterhalb von 640 kB frei sein musste (620 kB, wenn ich mich richtig erinnere), damit das Spiel überhaupt startete. Das war gerade für deutsche Anwender ein Problem, da man hierzulande üblicherweise den deutschen Tastaturtreiber geladen hatte, welcher ca. 10kB verschlungen hat. Dazu kamen noch ca. 50 kB für die CD-ROM-Treiber und das Programm MSCDEX.EXE. Wer dieses Spiel spielen wollte, musste dafür eine eigene Konfiguration basteln, die im Grunde nur den Maustreiber geladen hat (Welcher üblicherweise 10 kb benötigte).
Im Laufe des Jahres 1993 kamen dann die ersten Spiele auf den Markt, welche den DOS-Extender „DOS4GW.EXE“ benutzten. Spiele, welche EMS-Speicher benötigten, starben danach sehr schnell aus, was dazu führte, dass man die EMS-Konfiguration nur noch selten benötigte. Das Thema sollte aber Windows 95-Anwender noch ein paar Jahre verfolgen, da dieses Betriebssystem DOS zum Starten benötigte. Wollte man ein älteres Programm, welches EMS-Speicher benötigte unter Windows 95 starten, musste man in der „CONFIG.SYS“ den EMS-Speicher über „EMM386.EXE“ aktivieren. Dieser Speicher stand dann aber Windows 95 nicht mehr zur Verfügung. Man war also immer noch auf DOS-Basteleien angewiesen. Die Bastelei mit dem Speicher hatte erst ein Ende, als die meisten Entwickler auf die Win32-API umgestiegen waren bzw. Windows XP erschien.
Heutzutage macht sich kein Mensch mehr Gedanken über die Speicheraufteilung. RAM ist einfach da und wird benutzt.

Treiber waren ein Abenteuer

Hier muss ich zwischen zwei Dingen unterscheiden:

1. Der Hardware bzw. Treiberkonfiguration.
2. Woher man den Treiber bekam.

Die Hardwarekonfiguration musste von Hand vorgenommen werden

In Zeiten vor PCI und Plug’n Play und zu Zeiten von DOS hatten PCs 16 IRQs (Interruptleitungen). Diese waren von 0 bis 15 durchnummeriert. Jedes Gerät und jede Erweiterungskarte benötigte üblicherweise einen dieser IRQs. Die Anzahl von 16 klingt erst einmal nach relativ viel, man muss aber bedenken, dass über die Hälfte von ihnen schon standardmäßgi vergeben waren. Eine Liste ist z.B. hier zu finden:

https://en.wikipedia.org/wiki/Interrupt_request_(PC_architecture)

Ein großes Problem war, dass die damaligen Karten keine Autokonfiguration kannten und man bei den meisten Karten vor dem Einbau die passende Steckbrücke auf der Karte setzen musste. Gerade Anfänger wussten sehr häufig nicht, welche IRQs man verwenden musste bzw. welche noch zur freien Verfügung standen. Bei nur einer Erweiterungskarte spielte die IRQ-Problematik keine große Rolle, aber je mehr Karten man einbaute (Bei mir war damals z.B. eine Soundkarte und der Controller für mein CD-ROM-Laufwerk verbaut. Später kam dann eine Netzwerkkarte dazu), desto kritischer wurde die Situation. Dazu kam noch, dass jede Karte eine passende Hardwareadresse und oft auch einen DMA-Kanal benötigte. Je mehr Karten man im Rechner verbaut hatte, desto unübersichtlicher wurde die Situation. Amiga und Mac-Besitzer konnten damals nur müde über PC-Besitzer und ihre Probleme lächeln, da beide Rechnertypen schon immer „Plug’n Play“ bei ihren Erweiterungskarten unterstützten.
Im Laufe des Jahres 1994 wurden die ersten PCs und ISA-Karten mit „Plug’n Play“-Unterstützung auf den Markt gebracht. Diese erlaubten eine Autokonfiguration der IRQs auch unter DOS (Wobei ein Zusatzprogramm benötigt wurde), trotzdem war deren Konfiguration für die meisten Benutzer aber genauso ein Gefrickel, da parallel dazu immer noch die alten Karten im Einsatz waren und man deren IRQs händisch blocken musste. Mit dem Erscheinen von Windows 95 (Integriertes „Plug’n Play“) und dem breiten Einsatz von PCI-Karten (Diese unterstützen Interrupt-Sharing) verlor das Thema langsam an Bedeutung.
Heutzutage spielen IRQ -und Adresskonflikte keine Rolle mehr. Die Hardware wird einfach vollautomatisch konfiguriert.

Woher bekomme ich nur den passenden Treiber?

Auch wenn das Problem heute, in abgeschwächter Form, noch existiert, muss man bedenken, dass im Jahr 1992 und auch noch später, die einzige Quelle von Gerätetreibern die mitgelieferte Diskette (später CD) des Herstellers war. Ging diese verloren oder war defekt (Was bei Disketten sehr leicht passierte), stand man in der Regel sehr dumm da. Die einzigen weiteren Quellen waren Freunde mit der gleichen Hardware oder Computerläden, welche ihre Rechner selbst zusammengebaut haben. Bei den großen Märkten (Meinen PC habe ich bei ProMarkt gekauft) brauchte man erst gar nicht nachfragen, da sie nur als Händler fungierten.
Zwei Beispiele sollen diese Problematik verdeutlichen:

1. Meinem ersten PC lag eine Treiberdiskette für die VGA-Karte (Irgendein Trident-Chip) bei. Auf dieser waren Treiber für Windows 3.0 und OS/2 2.0. Dumm war nur, dass der Treiber nicht richtig funktionierte und mein Monitor nach der Installation unter Windows 3.0 kein Bild dargestellt hat. Der Monitor zeigte nur quer laufende Streifen, was in Zeichen war, dass dieser außerhalb seiner Spezifikationen betrieben wurde. Es gab keine Möglichkeit die passende Bildwiederholfrequenz einzustellen. Ich konnte unter Windows 3.0 also nur 16 Farben benutzen. Erst Monate später fiel mir durch puren Zufall bei einem Kumpel eine passende Treiberdiskette in die Hände. Höhere Auflösungen hatten aber wegen der schlechten Daten des Monitors aber keinen großen Sinn. Immerhin kam ich in den Genuss von 256 Farben.
2. Als im Oktober 1994 „OS/2 3.0 Warp“ auf den Markt kam, gab es dieses vergünstigt für 99 DM zu kaufen. Ein Kumpel, mein Cousin und ich haben damals das Betriebssystem gekauft, da wir davon überzeugt waren, dass es sich durchsetzen würde. Jedenfalls hatte jener Kumpel einen IBM PS/2-Rechner, was eigentlich die perfekte Voraussetzung für den Betrieb von OS/2 sein sollte. Leider brachte die damalige Version von OS/2 keine Treiber für IDE-CD-ROM-Laufwerke mit (Welches im Rechner nachgerüstet war). Es war also nur möglich die Installation per Disketten (ca. 20 3,5″ Disketten) oder über ein vorübergehend eingebautes Mitsumi-CD-Laufwerk (Nostalgiker werden sich erinnern) durchzuführen. Ein passender Treiber für das IDE-CD-ROM-Laufwerk wurde erst ein paar Monate später als Beilage-Diskette des „PC Magazin“ nachgeliefert. Spätere CD-Pressungen von OS/2 3.0 lieferten den Treiber dann mit aus, aber das hat uns damals nicht viel gebracht, da wir ja nur die erste CD-Pressung besaßen.

Weitere Probleme ergaben sich durch die Treiber selbst:

1. Unterstützte die Hardware kein Plug’n Play musste man die Hardwarekonfiguration im Treiber von Hand vornehmen. Das konnte ziemlich blöd enden, wenn man z.B. einen falschen Interrupt gewählt hatte und das System nach der Treiberinstallation beim Booten hängen blieb. Unter DOS war es relativ einfach den Treiber zu entfernen, bei moderneren Systemen dagegen wurde es ziemlich aufwendig (z.B. Windows 95 im abgesicherten Modus booten, Treiber deinstallieren und nochmal von vorne anfangen).
2. Die Treiberqualität war damals sehr oft nur von schlechter Qualität. Abstürze waren an der Tagesordnung.

Lustigerweise hatte ich damals unter Linux die wenigsten Treiberprobleme. Meine Hardware war so gewöhnlich, dass alles OotB unterstützt wurde.
Heute werden die meisten Treiber mit dem Betriebssystem ausgeliefert. Im Zweifelsfall gibt es das Internet. Dank modernem Plug’n Play muss nichts konfiguriert werden und Hardware funktioniert einfach so.

Disketten waren der Teufel!

Ich hasse Disketten, egal ob 5 1/4″) oder modernere 3,5″-Disketten. Disketten waren notorisch unzuverlässig und zwar immer dann, wenn man deren Inhalt am dringendsten benötigte. Ich weiß gar nicht, wie oft ich am PC saß und vor Frust fast in die Tastatur gebissen habe, weil mal wieder eine Diskette einen Lesefehler hatte. Die Hersteller konnten noch so sehr Werbung machen, aber meiner Erfahrung machte es kaum einen Unterschied ob man billige No-Name oder teure Markendisketten gekauft hat. Bei den teuren Disketten kamen die Fehler halt ein paar Wochen später.
Zu Zeiten eines C64 waren die 5¼“ Floppydisketten viel unempfindlicher als die späteren 3½“ HD-Disketten eines PCs, da Erstere eine viel niedrigere Datendichte hatten und der Lesekopf des Laufwerks einfach mehr Fläche pro Bit zur Verfügung hatte (Ich habe mal eine C64-Diskette, über die Fruchtsaft gelaufen ist, einfach durch Aufschneiden der Hülle, Abspülen mit destilliertem Wasser und Einsetzen in eine neue Hülle retten können.) Das Problem fing mit den 3½“ DD-Disketten an und wurde mit den HD-Disketten richtig schlimm. Die Datendichte war sehr viel höher und jedes kleine Staubkorn, konnte die Diskette bzw. deren Inhalt zerstören. Aus diesem Grund sind die meisten Diskettenbenutzer irgendwann dazu übergegangen wichtige Daten redundant auf mehreren Disketten zu speichern (Praktikabel waren drei Disketten). Irgendwann wurde es ziemlich unpraktikabel, mit den Dingern herumzuhantieren da die Dateien immer größer wurden und man gezwungen war Inhalte auf mehrere Disketten zu verteilen, mit den bekannten Konsequenzen (z.B. Diskette 6 von 10 hatte einen Lesefehler).
Was war das für eine Offenbarung, als es die ersten richtigen Alternativen zu Disketten gab (z.B. das ZIP-Laufwerk), die deutlich weniger fehleranfällig waren und deutlich mehr Speicherplatz anboten (Wobei das ZIP-Laufwerk irgendwann unter dem berüchtigten „Click of Death„-Fehler litt). Dazu kam noch, dass alle Alternativen zu Disketten deutlich schneller beim Lesen und Schreiben waren. Wer einmal ein Programm oder Spiel von 10 Disketten installiert hat, will diese Zeiten nie mehr zurück haben. Als dann die ersten USB-Sticks auf den Markt kamen, waren Disketten für mich komplett gestorben. Die letzte Diskette, welche ich in der Hand hatte, war eine Demo des DOS-Spiels „Aladdin“. Diese habe ich vor ein paar Monaten auf dem Weg zum Bahnhof auf der Straße gefunden. Ich fand den Fund so ungewöhnlich, dass ich die Diskette an die Tür meines Büros geklebt habe.
Heutzutage muss man sich über solche Dinge keine Gedanken mehr machen. Datenaustausch findet üblicherweise das Internet statt und USB-Sticks sind so billig geworden, dass ich regelmäßig einen verliere.

Weitere Gedanken

War früher wirklich alles so schlecht? Natürlich nicht. Gerade was das Verständnis der Hardware und der Betriebssysteme betrifft, war es damals einfacher. Eine 16bit-CPU ist sehr viel einfacher zu programmieren als moderne 64bit-CPUs. Auch konnte man damals sehr viel einfacher selbst Hand anlegen. Beim ATARI ST war es üblich bei bestimmten Hardwareupgrades den Lötkolben zu schwingen. Ein MS-DOS war überschaubar groß und im Endeffekt gab es im Vergleich zu modernen Systemen kaum Stellschrauben.
Vermisse ich diese Zeiten deswegen? Absolut nicht. Aber man erinnert sich gerne daran, da man durch sie geprägt wurde.

Sicherheit steht in einem permanenten Spannungsverhältnis zur Alltagstauglichkeit. Das darf weder zu Sicherheitsnihilismus führen, aber man sollte auch nicht den Fehler machen und Alltagstauglichkeit mit schnöder Bequemlichkeit zu verwechseln.

Dieses Dilemma konnte man kürzlich wieder sehr schön im Blog von Mike Kuketz sehen. In seinem Artikel zum sicheren Online-Banking empfiehlt er den Rückgriff auf ein getrenntes Linux-Live-System zur Erledigung von Online-Bankgeschäften. Damit hat er grundsätzlich natürlich vollkommen recht! Ein normales Alltagssystem ist vielfältigen Angriffsmöglichkeiten ausgesetzt und irgendwann möglicherweise einfach von Schadsoftware befallen.

Im weiteren Verlauf des Artikels sieht man aber schon welchen Aufwand das bedeutet. Erstens benötigt man ein vollständig abgeschottetes System, weshalb eine virtuelle Maschine eigentlich wegfällt. Hier muss eine Distribution gewählt, ein Live-Medium erstellt und gepflegt werden. Dazu ist ein erhebliches Vorwissen im Linux-Bereich unerlässlich, welches angesichts der Marktanteile nicht verbreitet ist. Selbst wenn man die Sicherheitsbedenken bezüglich anderer Betriebssysteme zurückstellt, lässt sich so ein System nur mit Linux betreiben - schon aufgrund der Lizenzkosten. Hinzu kommt ein potenziell mehrfach tägliches Wechseln des Betriebssystems mittels Neustart, je nachdem wie intensiv man Bankgeschäfte betreibt, was eine erhebliche Einschränkung des Arbeitsflusses darstellen kann.

An diesem Punkt hat man den Normalanwender eigentlich schon verloren. Da beißt sich die Katze zudem in den Schwanz, denn die Alltagssysteme von versierten Anwendern dürften bereits hochgradig geschützt und deutlich seltener von Schadsoftware befallen sein, als die von Normalanwendern (gezielte Angriffe auf eine Person mal ausgeschlossen). Genau diejenigen, die also von einer solchen Systemtrennung profitieren würden, werden aufgrund des Aufwands zurückschrecken.

Zumal das Risiko nicht immer gleich groß ist. Nimmt man ein 2009 installiertes Windows 7, das eher unsystematisch gewartet und mit zahlreichen Softwareprodukten "angereichert" wurde, besteht schon ein erhebliches Risiko Schadsoftware vorzufinden. Bei einem gepflegten Linux oder macOS-System sieht das aber schon wieder ganz anders aus. Schadsoftware ist für diese Systeme in freier Wildbahn einfach nicht in dem Maße unterwegs. Hier ist dann die Frage, ob der Sicherheitsgewinn durch ein Live-System nicht auch eher theoretischer Natur ist.

Genau an diesem Punkt muss man solche Ratgeber kritisieren. Sichere und leicht umzusetzende Maßnahmen wie ein chipTAN-Generator stehen gleichwertig neben extravaganten Lösungen wie einem Parallel-System für das erst einmal intensive Zusatzkenntnisse erworben werden müssen. Es findet oft - und bei weitem nicht nur in dem obigen Beispiel - keine Einordnung statt, ob beides gleichermaßen notwendig ist.

Hier kommt man wieder zum Sicherheitsnihilismus. Viele Experten sagen nun, dass ein nicht vollständig durchdachtes System von Vornherein unsicher ist. Faktisch würde der Normalanwender aber schon profitieren, wenn er mittels chipTAN-Generator am heimischen Desktopsystem - also ohne schlechte App, auf unsicherem Android - arbeitet.

---

Bilder:

Einleitungs- und Beitragsbild von pixelcreatures via pixabay / Lizenz: CC0 Creative Commons

Backups müssen leicht durchzuführen sein, ansonsten macht man sie zu selten. Apple hat dafür in sein Desktopbetriebssystem macOS Time Machine implementiert. Mit diesem kann man sowohl auf externen Speichermedien wie Festplatten sichern, als auch auf Netzwerkfreigaben. Das Ziel einer solchen Sicherung kann ein Linux Server sein (siehe: Time Machine Backups auf einen Linux Server sichern), aber auch FreeNAS eignet sich dafür.

FreeNAS basiert auf FreeBSD und bietet eine ebenso mächtige wie leicht konfigurierbare NAS-Lösung (siehe kurze Vorstellung: Ausflug in die BSD-Welt: FreeNAS). Durch Jails und VMs bietet FreeNAS inzwischen deutlich mehr als lediglich einen Netzwerkspeicher. Bei mir hat es aufgrund der Stabilität und übersichtlichen Oberfläche inzwischen den Linux-Heimserver abgelöst.

Apple hat für Time Machine-Freigaben lange Zeit auf die eigene Lösung AFP (Apple Filing Protocoll) gesetzt. Inzwischen ist man in Cupertino auch auf SMB umgestiegen, allerdings müssen die serverseitigen SMB-Implementierungen dafür einige Anpassungen vornehmen. Diese haben sowohl viele LTS-Distributionen noch nicht erreicht, als auch FreeBSD/FreeNAS. Daher muss man gegenwärtig noch auf AFP zurückgreifen, was entgegen vieler Pressemeldungen auch immer noch funktioniert. (siehe: Time Machine Backup auf einen Linux Server - Stand macOS 10.13 "High Sierra").

Freigabe unter FreeNAS einrichten

FreeNAS unterstützt AFP mit Time Machine-Erweiterung von Haus, weshalb keine zusätzlichen Konfigurationsschritt notwendig sind.

In einem ersten Schritt legt man einen Benutzer an mittels dessen man auf die Freigabe zugreifen möchte. Diesen Benutzer kann man beliebig benennen, im vorliegenden Fall heißt er einfach tmb. Ein Heimatverzeichnis braucht er nicht.

Anschließend legt man auf dem Datenträger ein ZFS-Dataset an. Dieses kann ebenfalls beliebig benannt werden und heißt im vorliegenden Fall ebenfalls tmb mit dem Kommentar Time Machine Backup. Die Voreinstellungen kann man so belassen. Im erweiterten Modus kann man bei Bedarf ein Quota festlegen. Dieses sollte einerseits genug Platz für mehre Sicherungsversionen lassen, andererseits aber den anderen Einsatzzwecken des FreeNAS Rechnung tragen. Im hiesigen Beispiel sind das z. B. 500 GB, was ausreicht, da das zu sichernde System lediglich knapp 70 GB an Daten gespeichert hat.

Im folgenden müssen noch die Zugriffsrechte für das Dataset geändert werden. Über die Schaltfläche Zugriffsrechte ändern legt man den angelegten Nutzer tmb als Eigentümer der Freigabe fest.

Zu guter letzt braucht es nun noch die Freigabe selbst. Unter Freigaben kann man Apple (AFP) Freigaben anlegen. Unter Pfad wählt man das soeben eingerichtete Dataset an. Der Haken bei Time Machine ist selbstverständlich zu setzen.

Time Machine Sicherung in macOS einrichten

Ist die Freigabe eingerichtet kann man in den Systemeinstellungen unter Time Machine die Freigabe als Sicherungsziel auswählen. Sollte die Freigabe nicht sofort auftauchen kann man den Finder einmal neustarten. Entweder im Terminal mittels killall Finder oder bei gedrückter Alt-Taste mit einem Rechtsklick auf das Finder-Symbol.

Hier sollte man noch eine Verschlüsselung das Backups auswählen, sofern man das zu sichernde System ebenfalls per FileVault verschlüsselt hat (siehe: macOS mit FileVault verschlüsseln).

Anschließend fragt das System noch nach dem Benutzer für die Freigabe. Hier ist als Benutzernamen tmb und das zugehörige Passwort einzugeben. Das zu wählende Backup-Passwort verschlüsselt das Sparsebundle, das macOS für die Sicherung auf FreeNAS anlegt.

Abschließend führt macOS Time Machine die erste Sicherung durch, die je nach Größe mehrere Stunden dauern kann. Die folgenden Sicherungen beinhalten nur noch die geänderten Dateien. Sofern FreeNAS und macOS angeschaltet sind, sichert Time Machine einmal stündlich. Diese stündlichen Sicherungen werden einmal täglich zu einer Tagessicherung zusammengefasst. Nach einem Monat erfolgt eine Bereinigung, wodurch nur ein Backup pro Woche aufgehoben wird. Ist das Backupziel voll löscht Time Machine die ältesten Sicherungen.

Auf der FreeNAS-Freigabe befindet sich dabei eine sparsebundle-Date. Dabei handelt es sich um ein mitwachsendes Image, das man auch mittels des Festplattendienstprogrammes für andere Einsatzzwecke anlegen kann. Bei Bedarf kann man diese Datei mit dem DiskImageMounter einbinden und nachgucken welche Sicherungen vorhanden sind. Bei einer vor drei Tagen erstmals eingerichteten Sicherung sieht das wie folgt aus:

---

Bilder:

Einleitungs- und Beitragsbild von FreePhotosART via pixabay / Lizenz: CC0 Creative Commons

In der OSS-Welt hat Guido van Rossum den Begriff des BDFL, Benevolent Dictator for Life (zu dt. Wohlwollender Diktator auf Lebenszeit), geprägt. Von diesem Amt ist er nun zurückgetreten, wie er in der Python Mailing List bekannt gab.

Die Programmiersprache Python sollte den meisten technisch versierten Lesern, die bereits einige Erfahrungen mit Programmierung sammeln konnten, bekannt sein. So setzt diese Sprache auf Einfachheit und Lesbarkeit und greift seit über 20 Jahren zu teils kontroversen Mitteln wie einem Zwang zur Indentation mit Leerzeichen (oder auch Tabs) für Blöcke und (mehr oder weniger) dem Verzicht auf einem klassischen Trennzeichen wie dem Semikolon.

Nicht nur, dass bereits viele Programmierer Python aufgrund dieser Charastika verachten, gab es aufgrund eines Änderungsvorschlags intern viele Proteste. Dies hat im Endeffekt nun dazu geführt, dass der Python-Gründer van Rossum von seiner Leitungsfunktion zurückgetreten ist - aber eins nach dem anderen.

PEP 572

Programmiersprachen werden ebenso wie die durch sie ermöglichte Software laufend weiterentwickelt. Während bei z.B. C++ in bestimmten Abständen neue Versionen wie C++17 veröffentlicht werden, läuft dies bei Python in ähnlicher Weise. Grundlage hierfür bilden die Python Enhancement Proposals, kurz PEP, die als Spezifikationen eine Diskussionsgrundlage für z.B. mögliche neue Features schaffen. Aber auch Empfehlungen wie z.B. die Code style guide in PEP 8 werden hierüber verbreitet.

PEP 572 wird mit "Assignment Expressions" betitelt und beschreibt eine neue Möglichkeit, bestimmte Ausdrücke als Variable für einen untergeordneten Scope zuzuordnen - ich nenne es quasi "with statements auf Stereoide" (stimmt nicht ganz, with statements haben einen anderen Zweck). Ein Codebeispiel:

ohne PEP 572:

env_base = os.environ.get("PYTHONUSERBASE", None)
if env_base:
    return env_base

mit PEP 572:

if env_base := os.environ.get("PYTHONUSERBASE", None):
    return env_base

Der Code wird damit kürzer, aber bleiben die "Maxime" der Python-Sprache (Einfachheit, Lesbarkeit, ...) erhalten? Diese Entscheidung überlasse ich euch. Mir selber würden zwar auf Anhieb einige Anwendungsbereiche einfallen, es wären aber ähnliche, wo ich jetzt schon zu ternären Operationen greife.

Rückzug

Am 11. Juli 2018 wurde die PEP 572 und ihr Vorschlag akzeptiert. Überraschend hat sich gestern Guido van Rossum in einer E-Mail mit dem Titel "Transfer of power" in der Mailing List gemeldet.

Er möchte laut Mail nicht mehr für eine PEP so intensiv kämpfen müssen, die am Ende trotzdem zu so viel Verachtung führt. Aus diesem Grund zieht er sich permanent aus dem Entscheidungsprozess zurück und gibt somit das erstmals für ihn eingeführte Amt (so die allg. Annahme) des Wohlwollenden Diktators auf Lebenszeit, das mittlerweile in viele andere Open Source-Projekte adaptiert wurde, ab. Der BDFL ist das Oberhaupt eines Projektes und hat dort immer das letzte Wort. Zurückzuführen ist dies auch auf gesundheitliche Gründe, so die Mail. Für die nächste Zeit werde er dennoch als Core Developer aktiv sein. Nun benötige er jedenfalls eine Pause.

Die Projektführung ist jetzt vakant, da van Rossum keinen Nachfolger benannt und diese Entscheidung an das Projekt übergeben hat. Er habe jedoch hinsichtlich des Tagesgeschäfts keine großartigen Sorgen um die Nachfolge.

Am Ende seiner Mail verweist der Entwickler, der Python 1991 veröffentlicht hat, auf den Code of Conduct als Grundsatz. Wer diesen "nicht mag", solle das Projekt freiwillig verlassen.

Aus meiner Sicht ist es nun wichtig, dass Python die Frage um die Projektleitung zeitnah löst. Guido van Rossum wünsche ich auf diesem Wege alles Gute und schätze seine bisherige Arbeit.

Wissenswertes

Python entstand als ABC-Nachfolger und kleines Projekt für die Weihnachtstage im Dezember 1989 und ist heute - je nach Betrachtungsweise - eine der wichtigsten und nachgefragtesten Programmiersprachen. Aktuell in Version 3.7 und der auslaufenden Version 2.7 erhältlich, ist es Grundlage für viele wichtige Programme.

Guido van Rossum ist seit 2013 bei Dropbox angestellt und war vorher von 2005 bis 2012 bei Google tätig.

In der OSS-Welt hat Guido van Rossum den Begriff des BDFL, Benevolent Dictator for Life (zu dt. Wohlwollender Diktator auf Lebenszeit), geprägt. Von diesem Amt ist er nun zurückgetreten, wie er in der Python Mailing List bekannt gab.

Die Programmiersprache Python sollte den meisten technisch versierten Lesern, die bereits einige Erfahrungen mit Programmierung sammeln konnten, bekannt sein. So setzt diese Sprache auf Einfachheit und Lesbarkeit und greift seit über 20 Jahren zu teils kontroversen Mitteln wie einem Zwang zur Indentation mit Leerzeichen (oder auch Tabs) für Blöcke und (mehr oder weniger) dem Verzicht auf einem klassischen Trennzeichen wie dem Semikolon.

Nicht nur, dass bereits viele Programmierer Python aufgrund dieser Charastika verachten, gab es aufgrund eines Änderungsvorschlags intern viele Proteste. Dies hat im Endeffekt nun dazu geführt, dass der Python-Gründer van Rossum von seiner Leitungsfunktion zurückgetreten ist - aber eins nach dem anderen.

PEP 572

Programmiersprachen werden ebenso wie die durch sie ermöglichte Software laufend weiterentwickelt. Während bei z.B. C++ in bestimmten Abständen neue Versionen wie C++17 veröffentlicht werden, läuft dies bei Python in ähnlicher Weise. Grundlage hierfür bilden die Python Enhancement Proposals, kurz PEP, die als Spezifikationen eine Diskussionsgrundlage für z.B. mögliche neue Features schaffen. Aber auch Empfehlungen wie z.B. die Code style guide in PEP 8 werden hierüber verbreitet.

PEP 572 wird mit "Assignment Expressions" betitelt und beschreibt eine neue Möglichkeit, bestimmte Ausdrücke als Variable für einen untergeordneten Scope zuzuordnen - ich nenne es quasi "with statements auf Stereoide" (stimmt nicht ganz, with statements haben einen anderen Zweck). Ein Codebeispiel:

ohne PEP 572:

env_base = os.environ.get("PYTHONUSERBASE", None)
if env_base:
    return env_base

mit PEP 572:

if env_base := os.environ.get("PYTHONUSERBASE", None):
    return env_base

Der Code wird damit kürzer, aber bleiben die "Maxime" der Python-Sprache (Einfachheit, Lesbarkeit, ...) erhalten? Diese Entscheidung überlasse ich euch. Mir selber würden zwar auf Anhieb einige Anwendungsbereiche einfallen, es wären aber ähnliche, wo ich jetzt schon zu ternären Operationen greife.

Rückzug

Am 11. Juli 2018 wurde die PEP 572 und ihr Vorschlag akzeptiert. Überraschend hat sich gestern Guido van Rossum in einer E-Mail mit dem Titel "Transfer of power" in der Mailing List gemeldet.

Er möchte laut Mail nicht mehr für eine PEP so intensiv kämpfen müssen, die am Ende trotzdem zu so viel Verachtung führt. Aus diesem Grund zieht er sich permanent aus dem Entscheidungsprozess zurück und gibt somit das erstmals für ihn eingeführte Amt (so die allg. Annahme) des Wohlwollenden Diktators auf Lebenszeit, das mittlerweile in viele andere Open Source-Projekte adaptiert wurde, ab. Der BDFL ist das Oberhaupt eines Projektes und hat dort immer das letzte Wort. Zurückzuführen ist dies auch auf gesundheitliche Gründe, so die Mail. Für die nächste Zeit werde er dennoch als Core Developer aktiv sein. Nun benötige er jedenfalls eine Pause.

Die Projektführung ist jetzt vakant, da van Rossum keinen Nachfolger benannt und diese Entscheidung an das Projekt übergeben hat. Er habe jedoch hinsichtlich des Tagesgeschäfts keine großartigen Sorgen um die Nachfolge.

Am Ende seiner Mail verweist der Entwickler, der Python 1991 veröffentlicht hat, auf den Code of Conduct als Grundsatz. Wer diesen "nicht mag", solle das Projekt freiwillig verlassen.

Aus meiner Sicht ist es nun wichtig, dass Python die Frage um die Projektleitung zeitnah löst. Guido van Rossum wünsche ich auf diesem Wege alles Gute und schätze seine bisherige Arbeit.

Wissenswertes

Python entstand als ABC-Nachfolger und kleines Projekt für die Weihnachtstage im Dezember 1989 und ist heute - je nach Betrachtungsweise - eine der wichtigsten und nachgefragtesten Programmiersprachen. Aktuell in Version 3.7 und der auslaufenden Version 2.7 erhältlich, ist es Grundlage für viele wichtige Programme.

Guido van Rossum ist seit 2013 bei Dropbox angestellt und war vorher von 2005 bis 2012 bei Google tätig.

OpenSUSE Leap 15.0 ist nun seit einer Weile veröffentlicht (siehe: openSUSE Leap 15.0 im Test) und so langsam ist es an der Zeit die Systeme zu aktualisieren. Die bisherigen Upgrades waren nur Versionssprünge innerhalb des 42er-Leap-Zweiges und daher problemlos, umso gespannter konnte man daher sein, wie openSUSE sich bei einer Aktualisierung von einer Hauptversion zur nächsten schlägt.

Das System ist eine typische Office-Installation. Die Desktopumgebung ist MATE mit den üblichen zugehörigen Programmen. Hinzu kommen die üblichen Standardprogramme wie LibreOffice, Thunderbird und Firefox. Außerdem noch einige Programme aus dem GNOME-Umfeld wie z. B. Seahorse.

Eine grafische Update-Routine wie unter Ubuntu und den Derivaten gibt es nicht, aber die wenigen Handgriffe lassen sich auch problemlos in YaST oder der Konsole erledigen. Zuerst deaktiviert man etwaige Fremdquellen, sofern man überhaupt welche nutzt, dann aktualisiert man die Paketquellen auf die neueste Version. Dazu kann man im YaST-Modul Software-Repositories einfach im jeweiligen Pfad das "42.3" durch "15.0" ersetzen.

Anschließend führt man im Terminal das Update aus. Die grafische Paketverwaltung eignet sich dazu nicht!

# zypper dup

15.0 ist der reinen Versionslogik nach natürlich älter als 42.3, weshalb zypper einige Pakete in der Kategorie downgrade einordnet. Dabei handelt es sich aber natürlich selbstredend dennoch um ein Upgrade und es ist auch keine Benutzerinteraktion notwendig. Es werden dann noch einige Pakete entfernt und neue installiert, sowie zahlreiche Pakete ordnungsgemäß aktualisiert.

Im vorliegenden Fall konnten die Voreinstellungen komplett abgenickt werden. Nach Download und Aktualisierung noch ein Neustart und es begrüßt einen der MATE Desktop auf 15.0-Unterbau. Keine Fehler, keine Probleme.

Das Upgrade verlief derart problemfrei, dass es fast schon langweilig ist. Als nächstes kommt dann ein System mit KDE Plasma als Desktop. Man darf gespannt sein.

---

Bilder:

Einleitungs- und Beitragsbild von dariolafelicia via pixabay / Lizenz: CC0 Creative Commons

OpenSUSE Leap 15.0 ist nun seit einer Weile veröffentlicht (siehe: openSUSE Leap 15.0 im Test) und so langsam ist es an der Zeit die Systeme zu aktualisieren. Die bisherigen Upgrades waren nur Versionssprünge innerhalb des 42er-Leap-Zweiges und daher problemlos, umso gespannter konnte man daher sein, wie openSUSE sich bei einer Aktualisierung von einer Hauptversion zur nächsten schlägt.

Das System ist eine typische Office-Installation. Die Desktopumgebung ist MATE mit den üblichen zugehörigen Programmen. Hinzu kommen die üblichen Standardprogramme wie LibreOffice, Thunderbird und Firefox. Außerdem noch einige Programme aus dem GNOME-Umfeld wie z. B. Seahorse.

Eine grafische Update-Routine wie unter Ubuntu und den Derivaten gibt es nicht, aber die wenigen Handgriffe lassen sich auch problemlos in YaST oder der Konsole erledigen. Zuerst deaktiviert man etwaige Fremdquellen, sofern man überhaupt welche nutzt, dann aktualisiert man die Paketquellen auf die neueste Version. Dazu kann man im YaST-Modul Software-Repositories einfach im jeweiligen Pfad das "42.3" durch "15.0" ersetzen.

Anschließend führt man im Terminal das Update aus. Die grafische Paketverwaltung eignet sich dazu nicht!

# zypper dup

15.0 ist der reinen Versionslogik nach natürlich älter als 42.3, weshalb zypper einige Pakete in der Kategorie downgrade einordnet. Dabei handelt es sich aber natürlich selbstredend dennoch um ein Upgrade und es ist auch keine Benutzerinteraktion notwendig. Es werden dann noch einige Pakete entfernt und neue installiert, sowie zahlreiche Pakete ordnungsgemäß aktualisiert.

Im vorliegenden Fall konnten die Voreinstellungen komplett abgenickt werden. Nach Download und Aktualisierung noch ein Neustart und es begrüßt einen der MATE Desktop auf 15.0-Unterbau. Keine Fehler, keine Probleme.

Das Upgrade verlief derart problemfrei, dass es fast schon langweilig ist. Als nächstes kommt dann ein System mit KDE Plasma als Desktop. Man darf gespannt sein.

---

Bilder:

Einleitungs- und Beitragsbild von dariolafelicia via pixabay / Lizenz: CC0 Creative Commons

Heute ist mir was merkwürdiges passiert.

Mein Notebook Tuxedo X1506 läuft mit Debian Buster eigentlich problemlos.

Nun bin ich gerade dabei etwas neues  (neuer Controller [Hardware]) auszuprobieren und musste deshalb auch mal rebooten. Oh Schreck, kein Login mehr möglich. Offenbar versuchte systemd das grafische Login (gdm3) zu starten und erlitt damit Schiffbruch. Immer und immer wieder wurde es versucht.

Nur wildes rumhacken auf ALT-F9- F1 F2 F3 STRG-ALT-F9 F1 F2 F3 STRG-D STRG-C führte dann mal zum Erfolg.

Dann funktionierte das Login und das System wieder einwandfrei -- bis zum nächsten Reboot.

Also Ursache suchen und beseitigen war angesagt.

ein dmesg -HTw brachte segfaults zum Vorschein. Ein Ausschnitt gefällig? 

Bitte sehr:

Jul 11 20:10:56 tuxedo kernel: [  245.931762] gnome-shell[6921]: segfault at 20 ip 00007fa6d5c93aed sp 00007ffdb88d4330 error 4 in libmutter-2.so.0.0.0[7fa6d5b96000+165000]
Jul 11 20:10:59 tuxedo kernel: [  249.770883] gnome-shell[7027]: segfault at 20 ip 00007f4627e2faed sp 00007fff112a8360 error 4 in libmutter-2.so.0.0.0[7f4627d32000+165000]
Jul 11 20:11:03 tuxedo kernel: [  253.668634] gnome-shell[7159]: segfault at 20 ip 00007f16f21cbaed sp 00007fff073068c0 error 4 in libmutter-2.so.0.0.0[7f16f20ce000+165000]
Jul 11 20:11:07 tuxedo kernel: [  257.467717] gnome-shell[7239]: segfault at 20 ip 00007f1523bd1aed sp 00007ffc4e207870 error 4 in libmutter-2.so.0.0.0[7f1523ad4000+165000]
Jul 11 20:11:11 tuxedo kernel: [  261.281186] gnome-shell[7319]: segfault at 20 ip 00007f28e6099aed sp 00007ffe6cb884c0 error 4 in libmutter-2.so.0.0.0[7f28e5f9c000+165000]
Jul 11 20:11:15 tuxedo kernel: [  265.076490] gnome-shell[7399]: segfault at 20 ip 00007fdd9631aaed sp 00007ffeb8107990 error 4 in libmutter-2.so.0.0.0[7fdd9621d000+165000]
Jul 11 20:11:19 tuxedo kernel: [  268.836405] gnome-shell[7479]: segfault at 20 ip 00007f8fd0ee4aed sp 00007ffd74d1a760 error 4 in libmutter-2.so.0.0.0[7f8fd0de7000+165000]
Jul 11 20:11:22 tuxedo kernel: [  272.671850] gnome-shell[7559]: segfault at 20 ip 00007f4eed3fcaed sp 00007ffc26024ee0 error 4 in libmutter-2.so.0.0.0[7f4eed2ff000+165000]

Installieren von systemd-coredump stellte das tool coredumpctl zur Verfügung.

Also installiert und erneut gebootet. jetzt mit coredumpctl die generierten Coredumps gesehen und mit coredumpctl gdb untersucht

z.B.: gnome-shell[5021]: segfault at 20 ip 00007f97ad0bfaed sp 00007ffc38165c20 error 4 in libmutter-2.so.0.0.0[7f97acfc2000+165000]

Aha. Die Ursache hat evtl. mit  libmutter und gnome-shell zu tun.

Ok, dachte ich, googelste mal, ob das bereits ein bekanntes Phänomen ist, ja es gibt elend viele Treffer.

Allerdings nicht direkt dasselbe, mit Einschränkung der Aktualität auf letzte Woche wurd ich dann fündig.

Das Problem ist ein Bug, der mit dem Wayland Support zusammen hängt. Ich habe im Notebook eine Nvidia Karte, Wayland Support kann ich daher eh nicht nutzen, also den Support im GDM3 explizit abgeschaltet.

Die Option   WaylandEnable=false  in /etc/gdm3/daemon.conf entkommentieren, also das # wegnehmen.

Nun gehts wieder. Puh!

Gefunden habe ich das bei den Leuten von Archlinux.

Zugegeben, das Thema Emojis ist ein Streitpunkt, aber um es einfach zu halten: Manchmal braucht man diese einfach in gewissen Konversationen.

Der Kurztipp für Zwischendurch also: Die Gnome Shell unterstützt bereits seit einiger Zeit die Eingabe von Emojis durch zwei entsprechend vorkonfigurierte Tastenkürzel. Diese sind:

• Strg + .
• Strg + Shift + ;

Durch drücken eines der Tastenkürzel öffnet sich dann ein entsprechender Dialog. Unglücklicherweise scheint dies aktuell nur bei Software zu funktionieren, welche zum Gnome-Projekt gehört (wie beispielsweise Gedit), und sieht dann etwa so aus:

Die Emoji-Selektion am Beispiel von Gedit

Sollten Emojis fehlen, empfiehlt es sich eine Schriftart zu installieren welche diese nachrüstet, wie etwa noto-fonts-emoji (unter Archlinux direkt aus dem Repo "Extra" zu beziehen, eine weitere Konfiguration war bei mir nicht nötig).

Zugegeben, das Thema Emojis ist ein Streitpunkt, aber um es einfach zu halten: Manchmal braucht man diese einfach in gewissen Konversationen.

Der Kurztipp für Zwischendurch also: Die Gnome Shell unterstützt bereits seit einiger Zeit die Eingabe von Emojis durch zwei entsprechend vorkonfigurierte Tastenkürzel. Diese sind:

• Strg + .
• Strg + Shift + ;

Durch drücken eines der Tastenkürzel öffnet sich dann ein entsprechender Dialog. Unglücklicherweise scheint dies aktuell nur bei Software zu funktionieren, welche zum Gnome-Projekt gehört (wie beispielsweise Gedit), und sieht dann etwa so aus:

Sollten Emojis fehlen, empfiehlt es sich eine Schriftart zu installieren welche diese nachrüstet, wie etwa noto-fonts-emoji (unter Archlinux direkt aus dem Repo "Extra" zu beziehen, eine weitere Konfiguration war bei mir nicht nötig).

Bei der Softwareentwicklung ist es manchmal nötig, zum Testen von z.B. Migrationen die Datenbank eines Livesystems zu klonen, d.h. diese an eine andere Stelle zu kopieren. Dieser Artikel erklärt, wie das geht.

Unter MySQL und Linux ist das Vorhaben mit einem sehr einfachen Kommando möglich:

DB auf anderen Host klonen

mysqldump --add-drop-table --no-create-db --databases dbname1 -uDBUSER1 -pPASSWORD1 -h 192.168.100.1 | mysql -h 192.168.100.2 -uDBUSER2 -pPASSWORD2 dbname1

Der Kern des Kommandos ist relativ einfach und einleuchtend: erst wird ein mysqldump erstellt, der per Pipe sofort in eine SQL-Shell geleitet wird. Konkret kommt es auch auf die Optionen an, die je nach Anwendungsfall angepasst werden müssen. So habe ich in diesem Beispiel auf dem Zielhost (192.168.100.2) die Datenbank bereits (ohne weitere Tabellen) erstellt und bestimmte Rechte den Benutzern zugewiesen. Deswegen nutze ich die Option --no-create-db. Damit unter dem Szenario aber die Tabellen sauber gelöscht werden, wird --add-drop-table benötigt. Die konkrete Befehlsreferenz (insb. für die Optionen) lässt sich in der MariaDB-Dokumentation einsehen.

Hinweis: die Option -h wird nur benötigt, wenn auf einem anderen Host gearbeitet werden soll. Die beispielhaft gewählten Adressen müssen dann entsprechend angepasst werden.

Knackpunkt bei dieser Variante ist, dass die geklonte Datenbank den gleichen Datenbanknamen trägt (deswegen macht dies nur bei zwei Hosts Sinn).

DB auf gleichen Host klonen

mysqldump --add-drop-table --no-create-db --databases dbname1 -uDBUSER1 -pPASSWORD1 -h 127.0.0.1 | sed --expression='s/dbname1/dbname2/g' | mysql -h 127.0.0.1 -uDBUSER2 -pPASSWORD2 dbname2

Um der geklonten Datenbank einen anderen Namen zu geben, kann sich an einem Trick bedient und der mysqldump noch einmal durch sed geschoben werden, um den Datenbanknamen auszutauschen.

Bei der Softwareentwicklung ist es manchmal nötig, zum Testen von z.B. Migrationen die Datenbank eines Livesystems zu klonen, d.h. diese an eine andere Stelle zu kopieren. Dieser Artikel erklärt, wie das geht.

Unter MySQL und Linux ist das Vorhaben mit einem sehr einfachen Kommando möglich:

DB auf anderen Host klonen

mysqldump --add-drop-table --no-create-db --databases dbname1 -uDBUSER1 -pPASSWORD1 -h 192.168.100.1 | mysql -h 192.168.100.2 -uDBUSER2 -pPASSWORD2 dbname1

Der Kern des Kommandos ist relativ einfach und einleuchtend: erst wird ein mysqldump erstellt, der per Pipe sofort in eine SQL-Shell geleitet wird. Konkret kommt es auch auf die Optionen an, die je nach Anwendungsfall angepasst werden müssen. So habe ich in diesem Beispiel auf dem Zielhost (192.168.100.2) die Datenbank bereits (ohne weitere Tabellen) erstellt und bestimmte Rechte den Benutzern zugewiesen. Deswegen nutze ich die Option --no-create-db. Damit unter dem Szenario aber die Tabellen sauber gelöscht werden, wird --add-drop-table benötigt. Die konkrete Befehlsreferenz (insb. für die Optionen) lässt sich in der MariaDB-Dokumentation einsehen.

Hinweis: die Option -h wird nur benötigt, wenn auf einem anderen Host gearbeitet werden soll. Die beispielhaft gewählten Adressen müssen dann entsprechend angepasst werden.

Knackpunkt bei dieser Variante ist, dass die geklonte Datenbank den gleichen Datenbanknamen trägt (deswegen macht dies nur bei zwei Hosts Sinn).

DB auf gleichen Host klonen

mysqldump --add-drop-table --no-create-db --databases dbname1 -uDBUSER1 -pPASSWORD1 -h 127.0.0.1 | sed --expression='s/dbname1/dbname2/g' | mysql -h 127.0.0.1 -uDBUSER2 -pPASSWORD2 dbname2

Um der geklonten Datenbank einen anderen Namen zu geben, kann sich an einem Trick bedient und der mysqldump noch einmal durch sed geschoben werden, um den Datenbanknamen auszutauschen.

Passwortmanager sollten zur Grundausstattung jedes digital tätigen Menschen gehören. Das Prinzip der meisten Passwortmanager ist einfach. Mittels eines zentralen Passworts, das man sich merken muss, lässt sich eine Datenbank entschlüsseln in der die individuellen Passwörter für zahllose Dienste hinterlegt sind. Dadurch kann man einerseits sehr komplexe Passwörter nutzen und andererseits für jeden Dienst ein eigenes anlegen.

Passwortmanager schrecken auf den ersten Blick ab. Insbesondere die Vorstellung alle Passwörter gesammelt an einem Ort aufzubewahren behagt vielen erst einmal nicht. Zumal viele die Losung verinnerlicht haben, Passwörter niemals irgendwo zu notieren. Die Vorteile überwiegen jedoch definitiv die theoretischen Risiken. Kaum ein anderes System gewährleistet die Verwendung eines separaten Passworts für jeden Dienst, das theoretisch eine unbegrenzte Länge aufweist, unter Verwendung aller möglichen Zeichen. Dadurch schützt man sich erstens gegen Bruteforce-Angriffe und zweitens gegen Datendiebstähle, wie sie in der Vergangenheit bei vielen großen Dienstleistern vorgekommen sind. Schließlich gilt das entwendete Passwort nur für den gehackten Dienst.

Manche sehen in Passwörtern ein gescheitertes System und verweisen auf die jüngsten Errungenschaften biometrischer Authentifizierung. Hier ist jedoch Vorsicht geboten, da biometrische Merkmale nicht so sicher sind, wie sie dargestellt werden (siehe: (Un-)Sicherheit per Fingerabdruck)

Große Auswahl - viel Mist!

Weil Passwortmanager derart beliebt sind, gibt es unzählige verschiedene Anbieter auf den diversen Plattformen. Die einzelnen Programme werben mit unterschiedlichen Komfortfunktionen und diversen Preismodellen. Der letzte Schrei sind Abomodelle und Cloudsynchronisation. Zwei Funktionen von denen man tunlichst die Finger lassen sollte.

Eine Passwortdatenbank beinhaltet den Zugang zum kompletten digitalen Leben, man sollte sich also niemals an einen Anbieter ketten, schon gar nicht wenn dieser regelmäßige Zahlungen erfordert. Sofern ein proprietäres Programm zum Einsatz kommt muss also auf standardisierte Exportformate wie z. B. eine CSV-Datei geachtet werden.

Cloudsynchronisation ist zudem ein absolutes Unding. Verbunden mit dem Versprechen der sicheren Verschlüsselung will man die Faulheit des Anwenders bedienen. Der Anwender sollte jedoch bedenken, dass jede Verschlüsselung nur für den Moment sicher ist (und eventuell nicht mal das), aber zukünftig gebrochen werden könnte. Ist die Datenbank einmal in der Cloud, verliert man die Kontrolle darüber. Sollte die Verschlüsselung mal gebrochen werden verliert man die Kontrolle über sein digitales Ich, denn kaum jemand ändert seine Passwörter mehrmals im Jahr. Selbst alte Datenbanken dürften noch einen Bestand aktiver Passwörter beinhalten. Verliert man zudem die Kontrolle über die Datenbank, kann ein potenzieller Angreifer beliebig viel Zeit in das Brechen der Verschlüsselung investieren. Rechenleistung und Zeit sind zwei grundsätzliche Feinde jeder Verschlüsselung.

Der gleiche Vorbehalt gilt gegenüber Onlinediensten zur Passwortverwaltung, da man sich damit in die Hände eines Anbieters begibt und ihm unangebracht viel Vertrauen entgegen bringt. Wer so etwas nutzt kann auch gleich dem seriös wirkenden Anzugträger auf der Parkbank seine Geldbörse zur Aufbewahrung aushändigen. Es ist immer erstaunlich wie viel Quatsch Menschen tun, sobald sie vor einem Bildschirm sitzen. Dinge vor denen sie im Alltag sofort zurückschrecken würden.

Open Source & Interoperabilität

Es gibt einige Nischenlösungen, die durchaus ihren Sinn haben (siehe: Passwörter mit QtPass / pass verwalten). Hierbei sollte man immer darauf achten, dass entweder Standards genutzt werden - pass verwendet OpenPGP - oder klare Spezifikationen vorliegen. Ansonsten läuft man Gefahr eine Insellösung zu nutzen, die sich zur Sackgasse entwickeln kann.

Die beste gegenwärtige verfügbare Lösung ist dabei KeePass. Die KBX-Datenbanken sind dokumentiert und erfreuen sich großer Beliebtheit. Die Community hat deshalb für jede verfügbare Plattform Anwendungen entwickelt und die Wahrscheinlichkeit, dass man seine Datenbank irgendwann nicht mehr öffnen kann ist somit gering. Die meisten Anwendungen kosten zudem nichts und erfordern auf jeden Fall kein Abosystem.

Die Windows-Anwendung basiert auf .NET und kommt direkt von den KeePass-Machern. Unter Linux dominierte lange das Qt-basierte KeePassX, dessen Entwicklung aber in den letzten Jahren vor allem durch Langsamkeit gekennzeichnet war. Mit KeePassXC steht nun ein aktiv entwickelter Fork zur Verfügung. Für MacOS gibt es mit Kypass sowohl eine Lösung im App Store, als auch mit MacPass eine Open Source-Lösung auf GitHub. Android und iOS werden mit zahllosen Apps bedient, wobei für iOS MiniKeePass heraussticht und für Android das etwas angestaubte KeePassDroid.

Der Funktionsumfang variierte je nach Plattform etwas, das kann z.B. Bereiche wie Autotype etc. umfassen. KeePass speichert die Passwörter in Datenbanken mit der Dateiendung .kbx. Diese Datenbanken können dann manuell auf die verschiedenen Systeme übertragen werden. Da man Passwörter meist nicht tagtäglich wechselt ist der Aufwand auch zu verschmerzen und man muss seine Daten nicht in die Cloud legen.

Alternativ kann man auch die Basisfunktionen des Systems nutzen. Die meisten Linux-Desktopumgebungen, aber auch macOS verfügen über eine integrierte Passwortverwaltung. Diese Lösungen eignen sich jedoch nur, wenn man sich in einem homogenen Umfeld bewegt und sind funktional stark beschränkt. Hier droht die eingangs erwähnte Sackgasse.

Grenzen des Systems

Das System stößt jedoch auch an Grenzen. Das Passwort für das System und das Hauptkenntwort für die KeePass-Datenbank muss man sich weiterhin merken. Hinzu kommen Dienste, die man oft von unterwegs aufruft, wenn man seine Passwortdatenbank nicht zur Hand hat. Hier ist man weiterhin auf ein gutes Gedächtnis angewiesen. Im Idealfall verfügen die Dienste jedoch über eine Zweifaktorauthentifizierung, die ein wenig die Risiken schwächerer Passwörter abfängt.

---

Bilder:

Einleitungs- und Beitragsbild von MasterTux via pixabay / Lizenz: CC0 Creative Commons

Ein neuer unabhängiger Benchmark von PSPDFKit bestätigt die beeindruckende Geschwindigkeit von WebAssembly in Firefox: Mozillas Browser stellt sämtliche Browser, einschließlich Google Chrome, deutlich in den Schatten.

WebAssembly, oder kurz: wasm, ist ein neues Binärformat für das Web, entwickelt von Mozilla, Google, Microsoft und Apple in einer W3C Community Group. Ähnlich wie bei Mozillas asm.js oder Googles PNaCl handelt es sich dabei um das Resultat kompilierten Codes und soll die Performance von Webanwendungen beinahe auf das Niveau nativer Anwendungen heben.

Firefox war nicht nur der erste Browser mit WebAssembly-Unterstützung, Mozilla hatte auch bei der Performance von WebAssembly von Beginn an eine Vorreiter-Rolle. Dies bestätigt sich nun auch in einem neuen und unabhängigen Benchmark der Macher von PSPDFKit. Vor ein paar Monaten veröffentlichte PSPDFKit eine Version seines Web-SDKs, welche WebAssembly zum Rendern von PDF-Dateien im Browser verwendet. Entsprechend ist man bei PSPDFKit natürlich an der WebAssembly-Performance interessiert und hat einen Benchmark erstellt, der den Anspruch hat, eine reale Nutzung zu simulieren und nicht nur ein praxisferner Benchmark zu sein.

Die folgenden Grafiken zeigen Firefox, Chrome und Safari auf macOS respektive Firefox, Chrome und Microsoft Edge auf Windows. Während Firefox in den Messungen beim JavaScript-Fallback wenig überzeugt, sind die Werte für WebAssembly umso beeindruckender. Selbst der noch gar nicht erschienene Chrome 69, welcher gegenüber der aktuellen Chrome-Version nicht unwesentliche Performance-Verbesserungen für WebAssembly bereithält, ist auf Windows noch immer fast halb so langsam wie Firefox 61 und auf macOS ist der Unterschied zu Firefox 61 noch deutlicher. Safari auf macOS und Microsoft Edge auf Windows sind deutlich abgeschlagen die langsamsten WebAssembly-Browser in diesem Benchmark und spielen nicht einmal ansatzweise in der gleichen Liga mit.

Hinweis zu den Diagrammen: Je niedriger die Balken, desto besser.

Der Beitrag WebAssembly-Performance: Firefox stellt Chrome und alle anderen Browser in den Schatten erschien zuerst auf soeren-hentzschel.at.

Vergangene Woche stand wieder die gute alte E-Mail im Fokus der Sicherheitsdebatte. Schon wieder möchte man sagen, nachdem im Zuge der EFAIL-Geschichte (siehe: Kommentar: EFAIL - Nebelkerzen und was ist eigentliche eine Lücke?) die E-Mail mal wieder gestorben ist - zumindest für private Kommunikation. Nun ist nun auch klar, dass manch großer Maildienstleister auf die Privatsphäre der Anwender pfeift und andere der systematischen Überwachung den Weg bereiten.

Die erste Meldung kam vom Software-Giganten aus Redmond. E-Mails und auch Microsoft-Produkte allgemein haben immer seltener Privatanwender zum Ziel, sondern finden sich immer häufiger im ausschließlichen Businesseinsatz. Um der vollkommenen Kontrolle der Angestellten den Weg zu bereiten hat Microsoft daher eine API in seine Office 365 Lösung implementiert, die eine exakte Auswertung des Mail- und Arbeitsverhaltens ermöglicht.

Im Grunde genommen ist das nicht wirklich neu. Administratoren konnten schon immer ziemlich exakt nachvollziehen, wer, wann, wo und wie eine E-Mail verfasst, weitergeleitet, gelesen, gelöscht hat. Neu ist, dass man diese Funktion auf dem Silbertablett anbietet. Glücklich derjenige, der in einer Firma mit Personal-/Betriebsrat arbeitet, die den Gebrauch solcher Funktionen unterbindet oder an hohe Auflagen koppelt.

Google bietet zwar keine detaillierte Auswertung für die Personalabteilung - was möglicherweise auch daran liegt, dass GMail in Firmen nicht so verbreitet ist - sondern ermöglicht das Mitlesen durch Dritte. Hier muss der Nutzer zwar die Erlaubnis geben oder eine entsprechende App nutzen, die sich wiederum durch entsprechende AGBs absichert. Es spricht jedoch Bände, dass man erstens so eine Funktion überhaupt implementiert und zweitens keinerlei Problem darin sieht. Privatsphäre ist so 20. Jahrhundert...

Nicht alles was man kann, sollte man auch umsetzen. In Anbetracht der technischen Möglichkeiten unserer Zeit sollte Ethik eine deutlich größere Rolle spielen. Sowohl in der Ausbildung der so genannten high potentials in den MINT-Fächern, wie auch in Firmen allgemein. Solche Funktionen implementiert man einfach nicht!

Da gibt es nicht viel zu diskutieren. Erstens sollte man zu einem vertrauenswürdigen Maildienstleister wechseln (siehe: E-Mail Dienstleister mit Fokus auf Datenschutz) und zweitens seine E-Mails verschlüsseln (siehe: E-Mail Kommunikation absichern). Trotz der angeschlagenen Sicherheit von OpenPGP und S/MIME ist das zur Zeit immer noch besser als der offen einsehbare Inhalt, abgelegt bei irgendwelchen Datenkraken.

---

Bilder:

Einleitungs- und Beitragsbild von ribkhan via pixaybay / Lizenz: CC0 Creative Commons

Linux ist heute vielen ein Begriff - selbst solchen, die es selbst nicht nutzen. Die zahlreichen BSD-Variationen sind hingegen nur unter Insidern ein Thema. Eigentlich zu unrecht, Varianten wie FreeBSD sind schon lange nicht mehr unbenutzbar oder funktional eingeschränkt. In vielerlei Hinsicht kann es auf dem Desktop mit Linux gleichziehen. Umsteiger sollten dennoch lernwillig sein, die oberflächliche Nähe zu Linux täuscht.

FreeBSD im Vergleich mit Linux

Warum der Vergleich mit Linux? FreeBSD ist nicht ganz einfach zu bedienen und erfordert viel Handarbeit. Die Handbücher sind zwar sehr gut, aber auch technisch anspruchsvoll. FreeBSD-Interessenten werden daher meist bereits von einem alternativen Betriebssystem wie Linux kommen und eher selten von Windows.

BSD - Mehr als nur ein Kernel

Linux bezeichnet nur den Kernel. Dieses Mantra ignoriert die Linux-Community immer wieder gerne, wie schon der inflationäre Gebrauch von Linux im Namen vieler Distributionen illustriert. Lediglich Debian präzisiert mit dem GNU/Linux die Ursprünge der Distribution. Linux ist in der Form, wie es die meisten Anwender auf dem Desktop einsetzen, eine Komposition unterschiedlicher Projekte. Neben dem Linux-Kernel gehören dazu viele Tools aus dem GNU-Projekt und andere zentrale Projekte jüngeren Datums wie systemd. Die Zusammenstellung übernimmt der Distributor, der aber meist weder großen Einfluss auf die Entwicklung hat, noch unbedingt langfristig an einem Werkzeug festhält. Große Updates mit Kompatibilitätsbrüchen gehören quasi zur DNA der Linux-Distributionen und sind - wenn man sich das Echo anhört - ebenso oft ein Ärgernis.

BSD Systeme sind hingegen mehr als lediglich der Kernel. Es gibt hier keine organisatorische Trennung zwischen Kernel, zentralen Bibliotheken sowie dem so genannten "Userland". BSD-Varianten wie FreeBSD fassen diese alle zusammen und entwickeln sie gemeinsam, wodurch ein hohes Maß an Konsistenz angestrebt wird. Dieses Userland unterscheidet sich stark von den GNU-Umgebungen der Linux Distributionen, weshalb man nicht zu viele Gemeinsamkeiten erwarten sollte.

Paketmanager nur für Drittanwedungen

Diese grundsätzliche Trennung zieht sich durch das gesamte System. Mit pkg hat FreeBSD zwar einen Paketmanager für Binärpakete, der mit seinen Pendants unter Linux vergleichbar ist, dieser ist jedoch nicht für das Basissystem verantwortlich. Das eigentliche FreeBSD-Kernsysteme wird mittels des Befehls freebsd-update aktualisiert. Bei einer Neuinstallation ist pkg standardmäßig nicht einmal installiert. Mittels pkg verwaltet man lediglich die zusätzlich installierten Programme aus den ports, was jedoch unter anderem auch den Desktop und vieles weiteres umfasst.

Eine weitere Möglichkeit ist die angeleitete Kompilierung direkt aus den Quellen. Man kennt so etwas von Arch Linux AUR oder Gentoo. Das ist aber dank der Binärpakete und pkg nicht mehr unbedingt notwendig, ältere Anleitungen berücksichtigten dies teilweise noch nicht.

FreeBSD trennt daher auch in der Administration strikt zwischen FreeBSD-Kernsystem und (portierten) Anwendungen aus dem OSS-Universum. Zukünftig ist angeblich geplant das Kernsystem auch mit pkg verwalten zu können, aber vor der Veröffentlichung von FreeBSD 12 im kommenden Jahr ist das nicht einmal experimentell verfügbar.

Die Trennung zwischen Kernsystem und Installation via pkg ist im Dateisystem abgebildet. Installierte Programme liegen in einer Struktur unterhalb von /usr/local und nicht verteilt im System wie bei Linux. Lediglich das Kernsystem liegt direkt unterhalb von /.

Freies System ohne Autopilot

FreeBSD ist alles andere als kompliziert zu installieren. Die Installationsroutine ist optionsarm, aber leichter zu absolvieren als beispielsweise bei Arch Linux. Die Nachinstallation moderner Desktopumgebungen wie z. B. Plasma 5 ist mittels pkg vollkommen problemlos.

In den letzten Jahren haben die Entwickler im Linux-Umfeld jedoch viel getan um Prozesse zu automatisieren. Manuelle Konfigurationsarbeit in /etc ist nicht mehr unbedingt erforderlich, selbst bei fortgeschrittenen Distributionen. FreeBSD verlangt hier weiterhin viel Handarbeit und erinnert damit stark an Linux Distributionen vor 5-10 Jahren. Dienste müssen beispielsweise manuell in /etc/rc.conf aktiviert, Sprachprofile in /etc/profile gewählt werden.

Treiber

Lange Zeit standen FreeBSD & Co im Ruf quasi überhaupt keine echte Hardware zu unterstützen. Aus eigener Erfahrung lässt sich das nicht bestätigen. Hardware, die unter Linux mit normalen quelloffenen Treibern angesprochen werden kann - und das ist inzwischen eine Menge - läuft auch unter FreeBSD. Proprietäre Hardware im WLAN- oder Grafik-Bereich mag immer noch Probleme bereiten - hier fehlen mir die Testgeräte. Für die Peripherie stehen CUPS und die Foomatic/Gutenprint-Treiber zur Verfügung. Wer hier in der Vergangenheit auf Kompatibilität geachtet hat, kann seine Hardware auch unter FreeBSD nutzen.

Software

Die Auswahl bei freier Software ist gut, da die POSIX-Kompatibilität hier den Portieraufwand minimiert. Der Umfang der via pkg installierbaren Produkte lässt sich mit openSUSE Leap vergleichen, kommt also nicht ganz an Debian und seine parasitären Derivate heran. Problematisch sind aber proprietäre Programme wie Spotify oder Skype, die sich auch unter Linux großer Beliebtheit erfreuen. DRM-Erweiterungen für Streamdienste haben in den letzten Jahren auch Einzug in Linux gehalten, sind aber für FreeBSD immer noch nicht verfügbar.

Die Administration des Systems erfolgt zudem weiterhin primär auf der Konsole. Es gibt kaum grafische Verwaltungswerkzeuge, wie sie inzwischen die meisten Linux-Distributionen haben.

Zusammengefasst

FreeBSD ist durchaus benutzbar - auch für den Desktop. Der Funktionsumfang und die Softwareauswahl kommt an die meisten Linux-Distributionen heran. Insbesondere wer bereits jetzt seine Linux Distribution gerne bis ins letzte Detail händisch konfiguriert oder generell die Konsole bevorzugt dürfte sich schnell einarbeiten.

Reizvoll ist die strikte Trennung zwischen dem FreeBSD-Basissystem und den Anwendungen. Dadurch erhält man eine stabile Basis, die sehr konservativ entwickelt wird, kombiniert mit einer aktuellen Desktopumgebung und aktuellen Endanwenderprogrammen.

Wer aber bereits mit Linux zufrieden ist und keinen ausgeprägten Spieltrieb hat, kann BSD auch weiterhin getrost ignorieren. Die Vorteile eines Wechsels sind eher gering, vieles ist halt einfach nur anders. Wem Linux aber zu langweilig ist, zu wenig händische Konfigurationsmöglichkeit bietet oder wer von aktuellen Entwicklungen frustriert ist, der sollte sich FreeBSD mal ansehen.

---

Bilder:

Einleitungs- und Beitragbild von stevepb via pixabay / Lizenz: CC0 Creative Commons

Linux ist heute vielen ein Begriff - selbst solchen, die es selbst nicht nutzen. Die zahlreichen BSD-Variationen sind hingegen nur unter Insidern ein Thema. Eigentlich zu unrecht, Varianten wie FreeBSD sind schon lange nicht mehr unbenutzbar oder funktional eingeschränkt. In vielerlei Hinsicht kann es auf dem Desktop mit Linux gleichziehen. Umsteiger sollten dennoch lernwillig sein, die oberflächliche Nähe zu Linux täuscht.

FreeBSD im Vergleich mit Linux

Warum der Vergleich mit Linux? FreeBSD ist nicht ganz einfach zu bedienen und erfordert viel Handarbeit. Die Handbücher sind zwar sehr gut, aber auch technisch anspruchsvoll. FreeBSD-Interessenten werden daher meist bereits von einem alternativen Betriebssystem wie Linux kommen und eher selten von Windows.

BSD - Mehr als nur ein Kernel

Linux bezeichnet nur den Kernel. Dieses Mantra ignoriert die Linux-Community immer wieder gerne, wie schon der inflationäre Gebrauch von Linux im Namen vieler Distributionen illustriert. Lediglich Debian präzisiert mit dem GNU/Linux die Ursprünge der Distribution. Linux ist in der Form, wie es die meisten Anwender auf dem Desktop einsetzen, eine Komposition unterschiedlicher Projekte. Neben dem Linux-Kernel gehören dazu viele Tools aus dem GNU-Projekt und andere zentrale Projekte jüngeren Datums wie systemd. Die Zusammenstellung übernimmt der Distributor, der aber meist weder großen Einfluss auf die Entwicklung hat, noch unbedingt langfristig an einem Werkzeug festhält. Große Updates mit Kompatibilitätsbrüchen gehören quasi zur DNA der Linux-Distributionen und sind - wenn man sich das Echo anhört - ebenso oft ein Ärgernis.

BSD Systeme sind hingegen mehr als lediglich der Kernel. Es gibt hier keine organisatorische Trennung zwischen Kernel, zentralen Bibliotheken sowie dem so genannten "Userland". BSD-Varianten wie FreeBSD fassen diese alle zusammen und entwickeln sie gemeinsam, wodurch ein hohes Maß an Konsistenz angestrebt wird. Dieses Userland unterscheidet sich stark von den GNU-Umgebungen der Linux Distributionen, weshalb man nicht zu viele Gemeinsamkeiten erwarten sollte.

Paketmanager nur für Drittanwedungen

Diese grundsätzliche Trennung zieht sich durch das gesamte System. Mit pkg hat FreeBSD zwar einen Paketmanager für Binärpakete, der mit seinen Pendants unter Linux vergleichbar ist, dieser ist jedoch nicht für das Basissystem verantwortlich. Das eigentliche FreeBSD-Kernsysteme wird mittels des Befehls freebsd-update aktualisiert. Bei einer Neuinstallation ist pkg standardmäßig nicht einmal installiert. Mittels pkg verwaltet man lediglich die zusätzlich installierten Programme aus den ports, was jedoch unter anderem auch den Desktop und vieles weiteres umfasst.

Eine weitere Möglichkeit ist die angeleitete Kompilierung direkt aus den Quellen. Man kennt so etwas von Arch Linux AUR oder Gentoo. Das ist aber dank der Binärpakete und pkg nicht mehr unbedingt notwendig, ältere Anleitungen berücksichtigten dies teilweise noch nicht.

FreeBSD trennt daher auch in der Administration strikt zwischen FreeBSD-Kernsystem und (portierten) Anwendungen aus dem OSS-Universum. Zukünftig ist angeblich geplant das Kernsystem auch mit pkg verwalten zu können, aber vor der Veröffentlichung von FreeBSD 12 im kommenden Jahr ist das nicht einmal experimentell verfügbar.

Die Trennung zwischen Kernsystem und Installation via pkg ist im Dateisystem abgebildet. Installierte Programme liegen in einer Struktur unterhalb von /usr/local und nicht verteilt im System wie bei Linux. Lediglich das Kernsystem liegt direkt unterhalb von /.

Freies System ohne Autopilot

FreeBSD ist alles andere als kompliziert zu installieren. Die Installationsroutine ist optionsarm, aber leichter zu absolvieren als beispielsweise bei Arch Linux. Die Nachinstallation moderner Desktopumgebungen wie z. B. Plasma 5 ist mittels pkg vollkommen problemlos.

In den letzten Jahren haben die Entwickler im Linux-Umfeld jedoch viel getan um Prozesse zu automatisieren. Manuelle Konfigurationsarbeit in /etc ist nicht mehr unbedingt erforderlich, selbst bei fortgeschrittenen Distributionen. FreeBSD verlangt hier weiterhin viel Handarbeit und erinnert damit stark an Linux Distributionen vor 5-10 Jahren. Dienste müssen beispielsweise manuell in /etc/rc.conf aktiviert, Sprachprofile in /etc/profile gewählt werden.

Treiber

Lange Zeit standen FreeBSD & Co im Ruf quasi überhaupt keine echte Hardware zu unterstützen. Aus eigener Erfahrung lässt sich das nicht bestätigen. Hardware, die unter Linux mit normalen quelloffenen Treibern angesprochen werden kann - und das ist inzwischen eine Menge - läuft auch unter FreeBSD. Proprietäre Hardware im WLAN- oder Grafik-Bereich mag immer noch Probleme bereiten - hier fehlen mir die Testgeräte. Für die Peripherie stehen CUPS und die Foomatic/Gutenprint-Treiber zur Verfügung. Wer hier in der Vergangenheit auf Kompatibilität geachtet hat, kann seine Hardware auch unter FreeBSD nutzen.

Software

Die Auswahl bei freier Software ist gut, da die POSIX-Kompatibilität hier den Portieraufwand minimiert. Der Umfang der via pkg installierbaren Produkte lässt sich mit openSUSE Leap vergleichen, kommt also nicht ganz an Debian und seine parasitären Derivate heran. Problematisch sind aber proprietäre Programme wie Spotify oder Skype, die sich auch unter Linux großer Beliebtheit erfreuen. DRM-Erweiterungen für Streamdienste haben in den letzten Jahren auch Einzug in Linux gehalten, sind aber für FreeBSD immer noch nicht verfügbar.

Die Administration des Systems erfolgt zudem weiterhin primär auf der Konsole. Es gibt kaum grafische Verwaltungswerkzeuge, wie sie inzwischen die meisten Linux-Distributionen haben.

Zusammengefasst

FreeBSD ist durchaus benutzbar - auch für den Desktop. Der Funktionsumfang und die Softwareauswahl kommt an die meisten Linux-Distributionen heran. Insbesondere wer bereits jetzt seine Linux Distribution gerne bis ins letzte Detail händisch konfiguriert oder generell die Konsole bevorzugt dürfte sich schnell einarbeiten.

Reizvoll ist die strikte Trennung zwischen dem FreeBSD-Basissystem und den Anwendungen. Dadurch erhält man eine stabile Basis, die sehr konservativ entwickelt wird, kombiniert mit einer aktuellen Desktopumgebung und aktuellen Endanwenderprogrammen.

Wer aber bereits mit Linux zufrieden ist und keinen ausgeprägten Spieltrieb hat, kann BSD auch weiterhin getrost ignorieren. Die Vorteile eines Wechsels sind eher gering, vieles ist halt einfach nur anders. Wem Linux aber zu langweilig ist, zu wenig händische Konfigurationsmöglichkeit bietet oder wer von aktuellen Entwicklungen frustriert ist, der sollte sich FreeBSD mal ansehen.

---

Bilder:

Einleitungs- und Beitragbild von stevepb via pixabay / Lizenz: CC0 Creative Commons

Mozilla wird in Kürze mit der Auslieferung von Firefox 61.0.1 beginnen. Mit dem Update behebt Mozilla mehrere Probleme der Vorgängerversion.

Eines der behobenen Probleme von Firefox 61.0.1 betrifft die Seite, die beim Öffnen eines neuen Tabs erscheint sowie die Einstellungs-Seite dazu. Auf Systemen mit defekter IndexedDB-Datenbank im Profil konnte es vorkommen, dass der neue Tab komplett leer und der dazugehörige Abschnitt in den Firefox-Einstellungen unvollständig war. Ein weiterer Defekt in der Datenbank places.sqlite konnte in seltenen Fällen beim Update von Firefox 60 auf Firefox 61 einen Verlust der Lesezeichen verursachen.

Mit dem Update wurden außerdem Probleme bei der Wiedergabe von 1080p-Videos auf Twitch behoben sowie das Überschreiben der Firefox-Startseite via WebExtension, was unter bestimmten Umständen nicht funktionierte.

Die Option, Dateien von FTP-Servern via Kontextmenü-Eintrag auf einen Link herunterzuladen, funktioniert mit dem Update auf Firefox 61.0.1 wieder, ebenso das Öffnen heruntergeladener Dateien ohne Dateiendung auf Windows.

Außerdem wurde ein Fokus-Problem beim Öffnen von Popups behoben sowie ein Problem beim Laden von Webseiten, von welchem chinesische Nutzer mit aktivierten Werkzeugen für Barrierefreiheit betroffen waren.

Der Beitrag Mozilla veröffentlicht Firefox 61.0.1 und behebt diverse Probleme erschien zuerst auf soeren-hentzschel.at.

Was hatte Zockertown lange nicht?

Richtig eine Besprechung eines coolen rundenbasierten Games.

Nun, da gibt es richtig gute Neuigkeiten.

 

Einer der Schöpfer und Hauptdesigner der originalen XCOM-Spiele, Julian Gollop hat im Rahmen einer Croud Gründungskampagne die Entwicklung von Phoenix Point begonnen. Erscheinungstermin wird wohl erst im Juni 2019 erscheinen.

Da ich erklärter XCOM Fanatiker bin, habe ich natürlich auch meinen Obulus geleistet. Als kleinen Dank kann ich seit dem 15.5. 2018 das sogenannte Backer Build 1.2 spielen. Und zwar nativ unter Linux.

Das Original ist ja von 1994, es lief noch mit DOS, Linux war da in etwa bei dem  Stand 1.0 und an eine Emulation von DOS war damals noch nicht zu denken, obwohl ich es bereits nutzte.

Doch nun zum Backer Build 1.2:

Es ist eine Mission "Fort Freiheit" spielbar, in ein paar interessanten Varianten.

Natürlich ähnelt das Spielgefühl dem der XCOM Reihe von Fireaxis, es gibt aber einen großen Unterschied.

Das Ziel/Schaden System ist neu erfunden, obwohl man sowas bereits in anderen Spielen gesehen hat, gab es das in dem Sinne nicht bei Xcom.

Man kann, wenn man will, frei zielen und einen Schwachpunkt in der Rüstung / Verteidigung des Gegners finden.

Neu (bzw. erneut wie im Original) gibt es Friendly Fire, wenn man nicht aufpasst, schiesst man seinem Kameraden in den Rücken, was der sicher nicht witzig findet, oder er bekommt einen Querschläger ab.

Ein zweiter Unterschied zum Original sind die Bossgegner, die aufzuhalten gelingt nur, wenn man gezielt Schwachpunkte aufspürt.

Munition ist ziemlich knapp, man findet aber Nachschub auf der Map

Im Netzt gibt es zu Hauf Videos, die ihr euch ansehen könnt, damit will ich euch nicht langweilen. Ich möchte nur ein paar Teilaspekte darstellen.

Ich bin über das aktuelle Marketing, wenn man es denn so nennen will positiv überrascht.

Es ist gestern der 2te Backer Build gewesen, der erste allergings mit einem Linux und Mac Client.

Es ist vorgesehen ca. alle 2 Monate oder auch häufiger einen neuen Build zur Verfügung zu stellen. Im Game kann - und soll- man bei aufgefallenen Bugs das Entwickler Team benachrichtigen.

Die hören allerdings nicht nur über diesen Kanal von den Spielern, sondern auch über ein eigens eingerichtetes Forum, wo die Spieler ihre Kritik und Vorschläge zum Game mitteilen und diskutieren.

Ich habe den Eindruck, dass dort auch auf die Strömungen reagiert wird und sie sich Mühe geben ein umfassendes großartiges Spiel abzuliefern.

Ein Screenshot utility ist für das Bug Meldesystem integriert, leider nicht für normale Screenshots, deshalb habe ich das Game im Fenstermodus gestartet, um leichte Screenshots zu machen. Das Game läuft aber in Fullscreen Mode einwandfrei.

Zum konkreten Backer Build schreibe ich noch später etwas mehr....

Update 4.7.2018 (ups, habe ich ja doch nicht.)

Egal, es gibt ein weiteres Build.

Im Telegrammstil kann der geneigte Leser es hier lesen, was ich dazu geschrieben habe.

https://www.linuxgaming.de/neuigkeiten-f6/phoenix-point-t6413.html

 

Ich hätte da ein Anliegen:

Wo sind denn meine Spielartikel besser aufgehoben?

Wie bisher hier im Blog, schliesslich habe ich hier keine Begrenzungen, was Grafiken betrifft und was ich schreibe, der Mod bin ich selber

Oder aber bei linuxgaming.de: Da seid ihr ja auch und warum 2 Quellen abgrasen, wenn man es an einer prominenten Stelle tun kann?

Ich freue mich auf Antworten

Es gibt in der heutigen Zeit gute Gründe, über VPN, einen Proxy oder über TOR ins Netz zu gehen. Sei es das öffentliche W-Lan im Lieblingscafé oder aber wesentlich relevanter, ihr befindet euch in einem Land, in dem kein freies Internet vorhanden ist bzw. gewisse Inhalte blockiert werden.
Nicht jeder Mensch kann oder möchte sich damit herumschlagen, beispielsweise einen OpenVPN-Server oder Proxy-Server einzurichten. Oft fehlt auch einfach das technische Verständnis bzw. Kenntnis.

Streisand zeigt wie wundervoll OpenSource im Kampf gegen Unterdrückung und Zensur im Internet helfen kann. Mittels Streisand lassen sich in wenigen Minuten auf Wunsch unzählige Gateway-Server zum anonymen Zugriff einrichten, die euch folgende fertig konfigurierte Dinge bieten:

• Passwortgeschützte Gateway-Seite mittels NGINX, erreichbar über SSL und Tor als Hidden service
• Installation folgender Dienste: OpenSSH, OpenConnect / Cisco AnyConnect, OpenVPN, Shadowsocks, sslh, Stunnel, Tor, UFW, unattended-upgrades, WireGuard
• Schritt-für-Schritt-Anleitungen zur Einrichtung der einzelnen Dienste
• Sämtliche empfohlene Software wird gemirrored. Die Authentizität wird mittels Checksummen sichergestellt.
• Alle genutzten Ports wurden so gewählt, dass Port-Blockierungen sich als schwierig erweisen. Als Beispiel verwendet OpenVPN Port 636, der auch von LDAP verwendet wird.

Eine deutlich umfangreichere Auflistung findet ihr in der Readme vom Projekt.

Die Installation ist zur Zeit leider noch mit Mehraufwand verbunden, was in Zukunft aber vereinfacht werden soll.
Der Normalfall sieht vor, dass von eurem Client aus mittels Ansible-Scripts ein neuer Server bei Amazon EC2, Azure, DigitalOcean, Google Compute Engine, Linode und Rackspace angelegt und automatisch eingerichtet wird. Es gibt aber auch die Möglichkeit lokal vorzugehen. Ich beschreibe im folgenden, wie ich vorgegangen bin.

Ausgangslage ist bei mir ein Cloud-Server von Hetzner. Voraussetzung ist - leider noch - ein Ubuntu 16.04-Image. Als erstes sorgt dafür, dass euer Server mittels DNS erreichbar ist, damit ihr später im Verlauf der Installation ein Let´s Encrypt-Zertifikat beantragen könnt.
Bevor wir mit der Installation beginnen, muss - sofern noch nicht vorhanden - mittels ssh-keygen ein SSH-Key erstellt werden. Übernimmt einfach die vorgeschlagenen Standard-Pfade.

Als erstes müssen wir nun ein ein paar benötigte Pakete installieren sowie das Projekt von Github clonen:

apt update
apt-get install git python-pip
git clone https://github.com/StreisandEffect/streisand.git && cd streisand

Mittels folgenden Befehl wird der Installer für Ansible gestartet. Dieser prüft zunächst auf fehlende Pakete und wird euch diese auflisten. Installiert diese wie angegeben.

./util/venv-dependencies.sh ./venv

Anschließend ruft ihr den Befehl erneut auf um die Installation durchzuführen. Ist die Installation durchgelaufen aktiviert ihr mit folgendem Befehl die installierten Ansible-Pakete:

source ./venv/bin/activate

Ein Ausführen von ./streisand startet nun die Installation. Wählt im Installer nun den Punkt 7. localhost (Advanced) aus und bestätigt im weiteren Verlauf die Warnung, dass ggf. Konfigurationen überschrieben werden können.

Wenn ihr gefragt werdet, ob ihr Änderungen an den Standard-Einstellungen vornehmen möchtet, widersprecht ihr mit Eingabe von no.

Ebenfalls werdet ihr im Verlauf der Installation nach Hostnamen des Servers und eurer E-Mail-Adresse gefragt. Beides ist lediglich von Bedeutung, sofern ihr Let's Encrypt nutzen wollt - was sich allerdings gerade bei solch einem Anwendungsfall empfiehlt.

Die Installation wird mit einer Fehlermeldung erfolgreich beendet werden, was daran liegt, dass der Installer versucht euch die HTML-Datei mit dem Zugangsdaten anzuzeigen.
Kopiert euch von eurem System den Ordner generated-docs herunter. Dieser enthält Informationen zur Firewall und die erwähnten Zugangsdaten.

Streisand ist nun eingerichtet und bereit zur Benutzung. :)

Sofern jemand in der anfangs beschriebenen Situation ist und solch eine Installation benötigt, schreibt mir eine E-Mail und ich helfe gerne weiter!

Es gibt in der heutigen Zeit gute Gründe, über VPN, einen Proxy oder über TOR ins Netz zu gehen. Sei es das öffentliche W-Lan im Lieblingscafé oder aber wesentlich relevanter, ihr befindet euch in einem Land, in dem kein freies Internet vorhanden ist bzw. gewisse Inhalte blockiert werden.
Nicht jeder Mensch kann oder möchte sich damit herumschlagen, beispielsweise einen OpenVPN-Server oder Proxy-Server einzurichten. Oft fehlt auch einfach das technische Verständnis bzw. Kenntnis.

Streisand zeigt wie wundervoll OpenSource im Kampf gegen Unterdrückung und Zensur im Internet helfen kann. Mittels Streisand lassen sich in wenigen Minuten auf Wunsch unzählige Gateway-Server zum anonymen Zugriff einrichten, die euch folgende fertig konfigurierte Dinge bieten:

• Passwortgeschützte Gateway-Seite mittels NGINX, erreichbar über SSL und Tor als Hidden service
• Installation folgender Dienste: OpenSSH, OpenConnect / Cisco AnyConnect, OpenVPN, Shadowsocks, sslh, Stunnel, Tor, UFW, unattended-upgrades, WireGuard
• Schritt-für-Schritt-Anleitungen zur Einrichtung der einzelnen Dienste
• Sämtliche empfohlene Software wird gemirrored. Die Authentizität wird mittels Checksummen sichergestellt.
• Alle genutzten Ports wurden so gewählt, dass Port-Blockierungen sich als schwierig erweisen. Als Beispiel verwendet OpenVPN Port 636, der auch von LDAP verwendet wird.

Eine deutlich umfangreichere Auflistung findet ihr in der Readme vom Projekt.

Die Installation ist zur Zeit leider noch mit Mehraufwand verbunden, was in Zukunft aber vereinfacht werden soll.
Der Normalfall sieht vor, dass von eurem Client aus mittels Ansible-Scripts ein neuer Server bei Amazon EC2, Azure, DigitalOcean, Google Compute Engine, Linode und Rackspace angelegt und automatisch eingerichtet wird. Es gibt aber auch die Möglichkeit lokal vorzugehen. Ich beschreibe im folgenden, wie ich vorgegangen bin.

Ausgangslage ist bei mir ein Cloud-Server von Hetzner. Voraussetzung ist - leider noch - ein Ubuntu 16.04-Image. Als erstes sorgt dafür, dass euer Server mittels DNS erreichbar ist, damit ihr später im Verlauf der Installation ein Let´s Encrypt-Zertifikat beantragen könnt.
Bevor wir mit der Installation beginnen, muss - sofern noch nicht vorhanden - mittels ssh-keygen ein SSH-Key erstellt werden. Übernimmt einfach die vorgeschlagenen Standard-Pfade.

Als erstes müssen wir nun ein ein paar benötigte Pakete installieren sowie das Projekt von Github clonen:

apt update
apt-get install git python-pip
git clone https://github.com/StreisandEffect/streisand.git && cd streisand

Mittels folgenden Befehl wird der Installer für Ansible gestartet. Dieser prüft zunächst auf fehlende Pakete und wird euch diese auflisten. Installiert diese wie angegeben.

./util/venv-dependencies.sh ./venv

Anschließend ruft ihr den Befehl erneut auf um die Installation durchzuführen. Ist die Installation durchgelaufen aktiviert ihr mit folgendem Befehl die installierten Ansible-Pakete:

source ./venv/bin/activate

Ein Ausführen von ./streisand startet nun die Installation. Wählt im Installer nun den Punkt 7. localhost (Advanced) aus und bestätigt im weiteren Verlauf die Warnung, dass ggf. Konfigurationen überschrieben werden können.

Wenn ihr gefragt werdet, ob ihr Änderungen an den Standard-Einstellungen vornehmen möchtet, widersprecht ihr mit Eingabe von no.

Ebenfalls werdet ihr im Verlauf der Installation nach Hostnamen des Servers und eurer E-Mail-Adresse gefragt. Beides ist lediglich von Bedeutung, sofern ihr Let's Encrypt nutzen wollt - was sich allerdings gerade bei solch einem Anwendungsfall empfiehlt.

Die Installation wird mit einer Fehlermeldung erfolgreich beendet werden, was daran liegt, dass der Installer versucht euch die HTML-Datei mit dem Zugangsdaten anzuzeigen.
Kopiert euch von eurem System den Ordner generated-docs herunter. Dieser enthält Informationen zur Firewall und die erwähnten Zugangsdaten.

Streisand ist nun eingerichtet und bereit zur Benutzung. :)

Sofern jemand in der anfangs beschriebenen Situation ist und solch eine Installation benötigt, schreibt mir eine E-Mail und ich helfe gerne weiter!

Es gibt in der heutigen Zeit gute Gründe, über VPN, einen Proxy oder über TOR ins Netz zu gehen. Sei es das öffentliche W-Lan im Lieblingscafé oder aber wesentlich relevanter, ihr befindet euch in einem Land, in dem kein freies Internet vorhanden ist bzw. gewisse Inhalte blockiert werden.
Nicht jeder Mensch kann oder möchte sich damit herumschlagen, beispielsweise einen OpenVPN-Server oder Proxy-Server einzurichten. Oft fehlt auch einfach das technische Verständnis bzw. Kenntnis.

Streisand zeigt wie wundervoll OpenSource im Kampf gegen Unterdrückung und Zensur im Internet helfen kann. Mittels Streisand lassen sich in wenigen Minuten auf Wunsch unzählige Gateway-Server zum anonymen Zugriff einrichten, die euch folgende fertig konfigurierte Dinge bieten:

• Passwortgeschützte Gateway-Seite mittels NGINX, erreichbar über SSL und Tor als Hidden service
• Installation folgender Dienste: OpenSSH, OpenConnect / Cisco AnyConnect, OpenVPN, Shadowsocks, sslh, Stunnel, Tor, UFW, unattended-upgrades, WireGuard
• Schritt-für-Schritt-Anleitungen zur Einrichtung der einzelnen Dienste
• Sämtliche empfohlene Software wird gemirrored. Die Authentizität wird mittels Checksummen sichergestellt.
• Alle genutzten Ports wurden so gewählt, dass Port-Blockierungen sich als schwierig erweisen. Als Beispiel verwendet OpenVPN Port 636, der auch von LDAP verwendet wird.

Eine deutlich umfangreichere Auflistung findet ihr in der Readme vom Projekt.

Die Installation ist zur Zeit leider noch mit Mehraufwand verbunden, was in Zukunft aber vereinfacht werden soll.
Der Normalfall sieht vor, dass von eurem Client aus mittels Ansible-Scripts ein neuer Server bei Amazon EC2, Azure, DigitalOcean, Google Compute Engine, Linode und Rackspace angelegt und automatisch eingerichtet wird. Es gibt aber auch die Möglichkeit lokal vorzugehen. Ich beschreibe im folgenden, wie ich vorgegangen bin.

Ausgangslage ist bei mir ein Cloud-Server von Hetzner. Voraussetzung ist – leider noch – ein Ubuntu 16.04-Image. Als erstes sorgt dafür, dass euer Server mittels DNS erreichbar ist, damit ihr später im Verlauf der Installation ein Let´s Encrypt-Zertifikat beantragen könnt.
Bevor wir mit der Installation beginnen, muss – sofern noch nicht vorhanden – mittels ssh-keygen ein SSH-Key erstellt werden. Übernimmt einfach die vorgeschlagenen Standard-Pfade.

Als erstes müssen wir nun ein ein paar benötigte Pakete installieren sowie das Projekt von Github clonen:

apt updateapt-get install git python-pipgit clone https://github.com/StreisandEffect/streisand.git && cd streisand

Mittels folgenden Befehl wird der Installer für Ansible gestartet. Dieser prüft zunächst auf fehlende Pakete und wird euch diese auflisten. Installiert diese wie angegeben.

./util/venv-dependencies.sh ./venv

Anschließend ruft ihr den Befehl erneut auf um die Installation durchzuführen. Ist die Installation durchgelaufen aktiviert ihr mit folgendem Befehl die installierten Ansible-Pakete:

source ./venv/bin/activate

Ein Ausführen von ./streisand startet nun die Installation. Wählt im Installer nun den Punkt 7. localhost (Advanced) aus und bestätigt im weiteren Verlauf die Warnung, dass ggf. Konfigurationen überschrieben werden können.

Wenn ihr gefragt werdet, ob ihr Änderungen an den Standard-Einstellungen vornehmen möchtet, widersprecht ihr mit Eingabe von no.

Ebenfalls werdet ihr im Verlauf der Installation nach Hostnamen des Servers und eurer E-Mail-Adresse gefragt. Beides ist lediglich von Bedeutung, sofern ihr Let’s Encrypt nutzen wollt – was sich allerdings gerade bei solch einem Anwendungsfall empfiehlt.

Die Installation wird mit einer Fehlermeldung erfolgreich beendet werden, was daran liegt, dass der Installer versucht euch die HTML-Datei mit dem Zugangsdaten anzuzeigen.
Kopiert euch von eurem System den Ordner generated-docs herunter. Dieser enthält Informationen zur Firewall und die erwähnten Zugangsdaten.

Streisand ist nun eingerichtet und bereit zur Benutzung. ?

Sofern jemand in der anfangs beschriebenen Situation ist und solch eine Installation benötigt, schreibt mir eine E-Mail und ich helfe gerne weiter!

Es gibt in der heutigen Zeit gute Gründe, über VPN, einen Proxy oder über TOR ins Netz zu gehen. Sei es das öffentliche W-Lan im Lieblingscafé oder aber wesentlich relevanter, ihr befindet euch in einem Land, in dem kein freies Internet vorhanden ist bzw. gewisse Inhalte blockiert werden.
Nicht jeder Mensch kann oder möchte sich damit herumschlagen, beispielsweise einen OpenVPN-Server oder Proxy-Server einzurichten. Oft fehlt auch einfach das technische Verständnis bzw. Kenntnis.

Streisand zeigt wie wundervoll OpenSource im Kampf gegen Unterdrückung und Zensur im Internet helfen kann. Mittels Streisand lassen sich in wenigen Minuten auf Wunsch unzählige Gateway-Server zum anonymen Zugriff einrichten, die euch folgende fertig konfigurierte Dinge bieten:

• Passwortgeschützte Gateway-Seite mittels NGINX, erreichbar über SSL und Tor als Hidden service
• Installation folgender Dienste: OpenSSH, OpenConnect / Cisco AnyConnect, OpenVPN, Shadowsocks, sslh, Stunnel, Tor, UFW, unattended-upgrades, WireGuard
• Schritt-für-Schritt-Anleitungen zur Einrichtung der einzelnen Dienste
• Sämtliche empfohlene Software wird gemirrored. Die Authentizität wird mittels Checksummen sichergestellt.
• Alle genutzten Ports wurden so gewählt, dass Port-Blockierungen sich als schwierig erweisen. Als Beispiel verwendet OpenVPN Port 636, der auch von LDAP verwendet wird.

Eine deutlich umfangreichere Auflistung findet ihr in der Readme vom Projekt.

Die Installation ist zur Zeit leider noch mit Mehraufwand verbunden, was in Zukunft aber vereinfacht werden soll.
Der Normalfall sieht vor, dass von eurem Client aus mittels Ansible-Scripts ein neuer Server bei Amazon EC2, Azure, DigitalOcean, Google Compute Engine, Linode und Rackspace angelegt und automatisch eingerichtet wird. Es gibt aber auch die Möglichkeit lokal vorzugehen. Ich beschreibe im folgenden, wie ich vorgegangen bin.

Ausgangslage ist bei mir ein Cloud-Server von Hetzner. Voraussetzung ist - leider noch - ein Ubuntu 16.04-Image. Als erstes sorgt dafür, dass euer Server mittels DNS erreichbar ist, damit ihr später im Verlauf der Installation ein Let´s Encrypt-Zertifikat beantragen könnt.
Bevor wir mit der Installation beginnen, muss - sofern noch nicht vorhanden - mittels ssh-keygen ein SSH-Key erstellt werden. Übernimmt einfach die vorgeschlagenen Standard-Pfade.

Als erstes müssen wir nun ein ein paar benötigte Pakete installieren sowie das Projekt von Github clonen:

apt update
apt-get install git python-pip
git clone https://github.com/StreisandEffect/streisand.git && cd streisand

Mittels folgenden Befehl wird der Installer für Ansible gestartet. Dieser prüft zunächst auf fehlende Pakete und wird euch diese auflisten. Installiert diese wie angegeben.

./util/venv-dependencies.sh ./venv

Anschließend ruft ihr den Befehl erneut auf um die Installation durchzuführen. Ist die Installation durchgelaufen aktiviert ihr mit folgendem Befehl die installierten Ansible-Pakete:

source ./venv/bin/activate

Ein Ausführen von ./streisand startet nun die Installation. Wählt im Installer nun den Punkt 7. localhost (Advanced) aus und bestätigt im weiteren Verlauf die Warnung, dass ggf. Konfigurationen überschrieben werden können.

Wenn ihr gefragt werdet, ob ihr Änderungen an den Standard-Einstellungen vornehmen möchtet, widersprecht ihr mit Eingabe von no.

Ebenfalls werdet ihr im Verlauf der Installation nach Hostnamen des Servers und eurer E-Mail-Adresse gefragt. Beides ist lediglich von Bedeutung, sofern ihr Let's Encrypt nutzen wollt - was sich allerdings gerade bei solch einem Anwendungsfall empfiehlt.

Die Installation wird mit einer Fehlermeldung erfolgreich beendet werden, was daran liegt, dass der Installer versucht euch die HTML-Datei mit dem Zugangsdaten anzuzeigen.
Kopiert euch von eurem System den Ordner generated-docs herunter. Dieser enthält Informationen zur Firewall und die erwähnten Zugangsdaten.

Streisand ist nun eingerichtet und bereit zur Benutzung. :)

Sofern jemand in der anfangs beschriebenen Situation ist und solch eine Installation benötigt, schreibt mir eine E-Mail und ich helfe gerne weiter!

Es gibt in der heutigen Zeit gute Gründe, über VPN, einen Proxy oder über TOR ins Netz zu gehen. Sei es das öffentliche W-Lan im Lieblingscafé oder aber wesentlich relevanter, ihr befindet euch in einem Land, in dem kein freies Internet vorhanden ist bzw. gewisse Inhalte blockiert werden.
Nicht jeder Mensch kann oder möchte sich damit herumschlagen, beispielsweise einen OpenVPN-Server oder Proxy-Server einzurichten. Oft fehlt auch einfach das technische Verständnis bzw. Kenntnis.

Streisand zeigt wie wundervoll OpenSource im Kampf gegen Unterdrückung und Zensur im Internet helfen kann. Mittels Streisand lassen sich in wenigen Minuten auf Wunsch unzählige Gateway-Server zum anonymen Zugriff einrichten, die euch folgende fertig konfigurierte Dinge bieten:

• Passwortgeschützte Gateway-Seite mittels NGINX, erreichbar über SSL und Tor als Hidden service
• Installation folgender Dienste: OpenSSH, OpenConnect / Cisco AnyConnect, OpenVPN, Shadowsocks, sslh, Stunnel, Tor, UFW, unattended-upgrades, WireGuard
• Schritt-für-Schritt-Anleitungen zur Einrichtung der einzelnen Dienste
• Sämtliche empfohlene Software wird gemirrored. Die Authentizität wird mittels Checksummen sichergestellt.
• Alle genutzten Ports wurden so gewählt, dass Port-Blockierungen sich als schwierig erweisen. Als Beispiel verwendet OpenVPN Port 636, der auch von LDAP verwendet wird.

Eine deutlich umfangreichere Auflistung findet ihr in der Readme vom Projekt.

Die Installation ist zur Zeit leider noch mit Mehraufwand verbunden, was in Zukunft aber vereinfacht werden soll.
Der Normalfall sieht vor, dass von eurem Client aus mittels Ansible-Scripts ein neuer Server bei Amazon EC2, Azure, DigitalOcean, Google Compute Engine, Linode und Rackspace angelegt und automatisch eingerichtet wird. Es gibt aber auch die Möglichkeit lokal vorzugehen. Ich beschreibe im folgenden, wie ich vorgegangen bin.

Ausgangslage ist bei mir ein Cloud-Server von Hetzner. Voraussetzung ist - leider noch - ein Ubuntu 16.04-Image. Als erstes sorgt dafür, dass euer Server mittels DNS erreichbar ist, damit ihr später im Verlauf der Installation ein Let´s Encrypt-Zertifikat beantragen könnt.
Bevor wir mit der Installation beginnen, muss - sofern noch nicht vorhanden - mittels ssh-keygen ein SSH-Key erstellt werden. Übernimmt einfach die vorgeschlagenen Standard-Pfade.

Als erstes müssen wir nun ein ein paar benötigte Pakete installieren sowie das Projekt von Github clonen:

apt update
apt-get install git python-pip
git clone https://github.com/StreisandEffect/streisand.git && cd streisand

Mittels folgenden Befehl wird der Installer für Ansible gestartet. Dieser prüft zunächst auf fehlende Pakete und wird euch diese auflisten. Installiert diese wie angegeben.

./util/venv-dependencies.sh ./venv

Anschließend ruft ihr den Befehl erneut auf um die Installation durchzuführen. Ist die Installation durchgelaufen aktiviert ihr mit folgendem Befehl die installierten Ansible-Pakete:

source ./venv/bin/activate

Ein Ausführen von ./streisand startet nun die Installation. Wählt im Installer nun den Punkt 7. localhost (Advanced) aus und bestätigt im weiteren Verlauf die Warnung, dass ggf. Konfigurationen überschrieben werden können.

Wenn ihr gefragt werdet, ob ihr Änderungen an den Standard-Einstellungen vornehmen möchtet, widersprecht ihr mit Eingabe von no.

Ebenfalls werdet ihr im Verlauf der Installation nach Hostnamen des Servers und eurer E-Mail-Adresse gefragt. Beides ist lediglich von Bedeutung, sofern ihr Let's Encrypt nutzen wollt - was sich allerdings gerade bei solch einem Anwendungsfall empfiehlt.

Die Installation wird mit einer Fehlermeldung erfolgreich beendet werden, was daran liegt, dass der Installer versucht euch die HTML-Datei mit dem Zugangsdaten anzuzeigen.
Kopiert euch von eurem System den Ordner generated-docs herunter. Dieser enthält Informationen zur Firewall und die erwähnten Zugangsdaten.

Streisand ist nun eingerichtet und bereit zur Benutzung. :)

Sofern jemand in der anfangs beschriebenen Situation ist und solch eine Installation benötigt, schreibt mir eine E-Mail und ich helfe gerne weiter!