Nachdem ich mich immer wieder mit Festplatten anderer Leute herumschlagen darf, die mal mehr und mal weniger gut funktionieren, und es auch einfach keinen Spaß macht, immer wieder meine Festplattengehäuse dafür zu missbrauchen, habe ich mich vor kurzem dazu entschlossen eine passende Dockingstation zu kaufen.

Nach längerer Recherche (die Dinger selbst gibt es wie Sand am Meer, nur fehlt meist jegliche technische Spezifikation) habe ich mich dann für das Modell FD2002C von Inateck entschieden. Mit 45€ nicht die billigste Variante, dafür hat die Station aber auch zwei Slots, unterstützt das direkte Klonen von Festplatten (ohne angeschlossenen Rechner oder Laptop), und verwendet bereits einen USB-C Stecker.

Besagte Dockingstation, Modell FD2002C von Inateck

Außerdem unterstützt es das USB Attached SCSI Protocol, kurz UAS oder auch UASP. D.h. im Gegensatz zu den meisten SATA-USB-Adaptern/Konvertern kann man hiermit auch ATA-Befehle verwenden (was, gerade für SSDs, ganz praktisch ist).

Unter Linux-basierten Betriebssystemen lässt sich dann mittels lsusb auch herausfinden, ob das Gerät richtig erkannt wurde und ob das UAS Protokoll verwendet. Etwas irritierend ist, dass das nur dann geht, wenn auch eine Festplatte in der Dockingstation steckt. Befindet sich keine Festplatte darin, sieht die Ausgabe wie folgt aus:

$ lsusb
[…]
Bus 004 Device 005: ID 174c:55aa ASMedia Technology Inc. Name: ASM1051E SATA 6Gb/s bridge, ASM1053E SATA 6Gb/s bridge, ASM1153 SATA 3Gb/s bridge, ASM1153E SATA 6Gb/s bridge
[…]

$ lsusb -t
/:  Bus 04.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/2p, 5000M
    |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/4p, 5000M
        |__ Port 1: Dev 5, If 0, Class=Mass Storage, Driver=usb-storage, 5000M
[…]
$ 

Wie man sehen kann wird hier der normale "usb-storage" Treiber verwendet. Das ändert sich tatsächlich erst, nachdem man eine Festplatte in einen der Slots steckt (dabei ist es egal ob Slot A oder B, und auch, ob man eine oder zwei Festplatten reinsteckt):

$ lsusb 
[…]
Bus 004 Device 006: ID 174c:55aa ASMedia Technology Inc. Name: ASM1051E SATA 6Gb/s bridge, ASM1053E SATA 6Gb/s bridge, ASM1153 SATA 3Gb/s bridge, ASM1153E SATA 6Gb/s bridge
[…]

$ lsusb -t
/:  Bus 04.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/2p, 5000M
    |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/4p, 5000M
        |__ Port 1: Dev 6, If 0, Class=Mass Storage, Driver=uas, 5000M
[…]
$ 

Die Festplatte wurde also erkannt, und der passende Treiber ("uas") geladen. ATA-Befehle wie TRIM oder Secure Erase funktionieren jetzt auch wie erwartet.

Eine Liste aller unterstützen Protokolle kann lsusb ebenfalls ausgeben, sofern man die entsprechende ID übergibt (welche man, ebenfalls, via lsusb bekommt):

$ lsusb 
[…]
Bus 004 Device 006: ID 174c:55aa […]
[…]

$ lsusb -v -d 174c:55aa | grep -i interface
Couldn't open device, some information will be missing
    bNumInterfaces          1
    Interface Descriptor:
      bInterfaceNumber        0
      bInterfaceClass         8 Mass Storage
      bInterfaceSubClass      6 SCSI
      bInterfaceProtocol     80 Bulk-Only
      iInterface              0 
    Interface Descriptor:
      bInterfaceNumber        0
      bInterfaceClass         8 Mass Storage
      bInterfaceSubClass      6 SCSI
      bInterfaceProtocol     98 
      iInterface              0 
$ 

Hier sehen wir zum einen das "Bulk-Only" Protokoll, welches von den meisten Adapter verwendet wird, als auch Protokoll "98", welches die Verwendung von ATA-Befehlen erlaubt.

Ein Geschwindigkeitstest der Dockingstation zeigt, dass diese tatsächlich auch hält, was sie verspricht. Mit einer SSD werden gut ~450MB/s im Lesen und Schreiben erreicht, die HDD erreicht immerhin Werte von bis zu 200MB/s im Lesen. Das entspricht auch dem Maximum meines USB 3.0 Anschlusses, und selbst bei einem direkten Anschluss der Festplatten an ein SATA-3 Interface würde ich hier keine höheren Werte erzielen können. Passt also.

Das direkte Klonen einer Festplatte konnte ich leider noch nicht testen, laut Beschreibung ist das aber sehr einfach gehalten: Einfach zwei Festplatten in die Slots stecken, "Klonen"-Taste circa drei Sekunden gedrückt halten bis die LEDs aufleuchten, und dann nochmals zur Bestätigung kurz antippen. Damit startet dann auch der Klonvorgang.

Die Optik der Dockingstation ist sehr gut (unscheinbar und stört nicht), und auch wenn das Gehäuse aus Plastik ist, ist es doch top verarbeitet. Einziges Manko wäre höchstens das fehlende Gewicht: Die Station ist sehr leicht, und muss festgehalten werden, wenn man eine Festplatte herauszieht. Es spricht aber nichts dagegen das Dock einfach auf dem Schreibtisch zu befestigen, und sei es nur mit doppelseitigem Klebeband.

Fazit: Das Gerät macht einen guten Eindruck und hält was es verspricht. Ich bin zufrieden (und zugleich froh, dass gleich das erste Gerät, was ich gekauft habe, so gut funktioniert. Ich hatte mich gedanklich schon auf Kompatibilitätsprobleme und andere Dinge eingestellt).

Für meine “Offside-Backups” benutze ich Borg und rsync.net. Heute wollte ich meine bei rsync.net gespeicherten Datensicherungen einmal komplett überprüfen.

borg check -v --verify-data XXXXX@ch-s010.rsync.net:MeinRepository

Leider bricht der Befehl schlussendlich immer mit der Fehlermeldung “Borg server is too old for scan. Required version 1.1.0b3” ab. Scheinbar verwendet rsync.net von Haus aus eine ältere Version von Borg. Auf der Internetseite kann man aber nachlesen, dass Version 0.29 und 1.x unterstützt werden. Also sollte es doch möglich sein, die aktuelle Version 1.x zu nutzen. Wie so oft hilft RTFM weiter. Es gibt die Variable BORG_REMOTE_PATH. Mit dieser kann man angeben welche Version von Borg auf dem Server verwendet werden soll. Im Fall von rsync.net muss man den bereits genannten Befehl wie folgt ändern, damit man Version 1.x von Borg verwendet.

borg check -v --verify-data --remote-path=/usr/local/bin/borg1/borg1  XXXXX@ch-s010.rsync.net:MeinRepository

Anstelle den Parameter –remote-path= zu verwenden, kann man das ganze auch allgemeiner mit “export BORG_REMOTE_PATH=/usr/local/bin/borg1/borg1” angeben. Für Scripte dürfte das die bessere Lösung darstellen.

Vor der Nutzung von –verify-data muss ich abschließend aber noch warnen. Hierbei wird sozusagen alles auf Herz und Nieren geprüft. Und das dauert. In dem Repository das ich für den Test verwendet habe, sind nur knapp 3 GB Daten vorhanden. Bis alles getestet worden ist, sind einige Stunden vergangen. Für allgemeine Prüfungen sollte man daher andere Einstellungen wählen.

Vor einigen Jahren hat Christiann MacAuley ein bekanntes Comic zur Reaktion verschiedener Nutzergruppen auf ein Update veröffentlicht. Sehr viele IT-Interessierte kennen das Bild. Damals dachte ich mir: So wahr! Heute gilt das nur noch für die Windows- und Apple-Anwender.

Windows-Anwender stöhnen noch heute bei jedem Update. Gefühlt seit Windows 10 noch mehr. Bei Apple-Kunden schlagen Updates zwar nicht mehr so in den Geldbeutel, da das Betriebssystem an das Gerät gebunden ist und Software inzwischen oft als Abo vertrieben wird. Die Kernaussage trifft aber dennoch zu.

Nur bei Linux stimmt die Aussage "Cool, more free stuff!" schon lange nicht mehr. Dazu muss man sich bei typischen Linux-Meldungen nur mal in den Kommentarspalten von Seiten wie Pro-Linux, Heise oder Golem umsehen. Wahlweise auch in einem der großen Foren.

Bei jedem Update kommen die Nörgler aus ihren Löchern gekrochen. Zuletzt konnte man das bei Pro-Linux in der PulseAudio Meldung verfolgen. Alle Änderungen und Umbaumaßnahmen an der Linux-Basis der letzten Jahre werden mit einer reaktionär-konservativen Grundeinstellung abgelehnt. Mythen und hassvoll gepflegte Gerüchte dominieren über viele Jahren die Meldungen zu allen möglichen Projekten. Gelobt werden oft nur noch reaktionäre Projekte wie Devuan oder konservative Softwarepflege wie sie bei Xfce und Konsorten erfolgt.

Der Optimismus und die Aufbruchsstimmung, die aus dem obigen Comic spricht, ist komplett verflogen. Der Glaube mit jedem Update würde Linux ein bisschen besser werden und ein bisschen konkurrenzfähiger ist kaum noch zu spüren. Stattdessen dominieren Anwender, die sich in einem bestimmten Nutzungsszenario eingeigelt haben und jede Änderung hasserfüllt bekämpfen.

Natürlich mag man argumentieren, dass dies nur auf den visuell sichtbaren Teil in den Medien zutrifft, aber dies ist halt der wahrnehmbare Teil. Als Entwickler oder potenzieller Umsteiger würde mich das abschrecken.

Die Linux Community ist online auf vielen Plattformen kein schöner Ort mehr.

Bilder:
Einleitungsbild und Beitragsbild von von geralt via pixabay 

Wenn man mit dem Bootloader syslinux neben Linux auch Windows starten will, erfolgt dies bei Festplatten mit MBR (nicht GPT!) beispielsweise über folgenden Eintrag in der Datei /boot/syslinux/syslinux.cfg.

...
LABEL windows
    MENU LABEL Windows
    COM32 chain.c32
    APPEND hd0 3
...

Hd0 ist in diesem Fall die erste vom BIOS/UEFI erkannte Festplatte. Und 3 bezieht sich auf die dritte Partition auf dieser Festplatte. Was aber wenn man mehrere Festplatten installiert hat und Windows nicht auf der gleichen Platte wie Linux installiert ist? Man müsste herausfinden in welcher Reihenfolge das BIOS/UEFI die Festplatten erkennt. Hierbei muss man beachten, dass Festplatten ab 0 gezählt werden, Partitionen aber ab 1. Also warum das ganze nicht etwas einfacher lösen?

Mit dem Befehl “fdisk -l” lässt man sich zuerst die ganzen vorhandenen Festplatten anzeigen und sucht sich dann die Festplatte, auf der Windows installiert ist, heraus. Sollte man wissen auf welcher Festplatte Windows installiert ist, kann man sich diese auch direkt mit beispielsweise “fdisk -l /dev/sde” anzeigen lassen. Das sieht dann beispielsweise wie folgt aus.

Festplatte /dev/sde: 238,49 GiB, 256060514304 Bytes, 500118192 Sektoren
Festplattenmodell: Crucial_CT256MX1
Einheiten: Sektoren von 1 * 512 = 512 Bytes
Sektorgröße (logisch/physikalisch): 512 Bytes / 4096 Bytes
E/A-Größe (minimal/optimal): 4096 Bytes / 4096 Bytes
Festplattenbezeichnungstyp: dos
Festplattenbezeichner: 0x0000d958

Gerät      Boot    Anfang      Ende  Sektoren  Größe Kn Typ
/dev/sde1  *         2048    206847    204800   100M  7 HPFS/NTFS/exFAT
/dev/sde2          206848 499123111 498916264 237,9G  7 HPFS/NTFS/exFAT
/dev/sde3       499124224 500113407    989184   483M 27 Verst. NTFS WinRE

Wichtig ist hier im Grunde nur der Festplattenbezeichner. Diesen merken wir uns und ändern den Eintrag von Windows in der Konfigurationsdatei von syslinux wie folgt ab.

...
LABEL windows
    MENU LABEL Windows
    COM32 chain.c32
    APPEND mbr:0x0000d958
...

Mit diesem Eintrag sollte man Windows nun problemlose per Chainloading starten können.

As I always forget how to get a backtrace of profanity (or any other TUI application) I write down an example.

Preparation

The following requirements must be installed:

• gdb
• gdbserver
• debug symbols (depending on your distribution they might already be included)
  • e.g. profanity-dbgsym (for profanity when using debian)
  • e.g. libstrophe0-dbgsym (for profanity when using debian)
  • e.g. libexpat1-dbgsym (for profanity when using debian)

Run the application

• Open terminal #1
  • Run gdbserver localhost:1234 /usr/bin/profanity
• Open terminal #2
  • Run gdb /usr/bin/profanity
  • Enter target remote localhost:1234
  • Enter c
• The application (profanity in this example) opens in terminal #1
  • Reproduce crash
• A gdb command line opens in terminal #2
  • Enter bt or bt full ¹
• Copy the output and go molesting the developers. 😁

Mozilla hat mit Firefox 69.0.1 das erste Update für Firefox 69 veröffentlicht und behebt damit mehrere Probleme der Vorgängerversion, einschließlich einer Sicherheitslücke.

Download Mozilla Firefox 69.0.1

Mit dem Update auf Firefox 69.0.1 behebt Mozilla eine Sicherheitslücke in Zusammenhang mit der Pointer Lock API.

Darüber hinaus hat Mozilla das Problem behoben, dass wenn ein Link geklickt wurde, um eine externe Anwendung wie das E-Mail-Programm zu starten, diese im Hintergrund geöffnet und nicht länger automatisch in den Vordergrund geholt worden ist.

In der Leseansicht kann die Schrift nun wieder so weit wie vor Firefox 69.0 vergrößert werden. Auf Netzwerk-Anmeldeseiten ging die Benachrichtigung nach dem Login nicht mehr automatisch weg.

Die Bedienung des neuen Add-on Managers wurde für Nutzer von Screenreadern verbessert. Außerdem wurde ein Problem mit dem Performance-Entwicklerwerkzeug behoben.

Der Beitrag Mozilla veröffentlicht Firefox 69.0.1 erschien zuerst auf soeren-hentzschel.at.

Mozilla wird in Zukunft neue Features und Webtechnologien noch schneller an die Nutzer ausliefern. Statt wie bisher sieben bis acht Wochen muss in Zukunft nur noch vier Wochen auf ein neues Major-Update gewartet werden.

Es ist mittlerweile mehr als acht Jahre her, dass Mozilla auf ein sogenanntes Rapid Release-Modell umgestiegen ist. Lag zuvor zwischen Major-Updates von Firefox ein Jahr oder gar mehr Zeit, waren es seit dem nur noch jeweils sechs Wochen. Mittlerweile erscheinen neue Firefox-Versionen in der Regel alle sieben bis acht Wochen. So kommen nicht nur neue Features, sondern vor allem auch Webtechnologien schneller an den Nutzer, wovon das Web als Ganzes profitiert – nicht nur auf Firefox-Nutzer bezogen.

Mozilla wird die Zeit zwischen Major-Releases ab 2020 reduzieren. In Zukunft sollen nur noch vier Wochen zwischen zwei Firefox-Versionen liegen.

Was Beta-Versionen betrifft, bedeutet die Änderung, dass diese dann ähnlich oft wie Nightly-Versionen statt wie bisher nur ein bis zwei Versionen pro Woche erscheinen werden.

Auf den ESR-Zweig für Unternehmen hat der neue Release-Zyklus keinen Einfluss. Hier plant Mozilla weiterhin mit einem Jahr Abstand zwischen zwei Major-Releases.

Das sind die Release-Termine bis Mitte 2020

Firefox 70, Firefox ESR 68.2
22. Oktober 2019 (7 Wochen nach Firefox 69)

Firefox 71, Firefox ESR 68.3
3. Dezember 2019 (6 Wochen nach Firefox 70)

Firefox 72, Firefox ESR 68.4
7. Januar 2020 (5 Wochen nach Firefox 71)

Firefox 73, Firefox ESR 68.5
11. Februar 2020 (5 Wochen nach Firefox 72)

Firefox 74, Firefox ESR 68.6
10. März 2020 (4 Wochen nach Firefox 73)

Firefox 75, Firefox ESR 68.7
7. April 2020 (4 Wochen nach Firefox 74)

Firefox 76, Firefox ESR 68.8
5. Mai 2020 (4 Wochen nach Firefox 75)

Firefox 77, Firefox ESR 68.9
2. Juni 2020 (4 Wochen nach Firefox 76)

Firefox 78, Firefox ESR 78.0, Firefox ESR 68.10
30. Juni 2020 (4 Wochen nach Firefox 77)

Firefox 79, Firefox ESR 78.1, Firefox ESR 68.11
28. Juli 2020 (4 Wochen nach Firefox 78)

Firefox 80, Firefox ESR 78.2, Firefox ESR 68.12
25. August 2020 (4 Wochen nach Firefox 79)

Firefox 81, Firefox ESR 78.3
22. September 2020 (4 Wochen nach Firefox 80)

Der Beitrag Firefox: Neue Versionen ab 2020 alle vier Wochen erschien zuerst auf soeren-hentzschel.at.

Schon früh war ich von Imaging Software begeistert und habe die
ersten OS/2 Installationen (damals noch HPFS) damit gesichert. Später
habe ich damit auch NTFS und diverse Windows Versionen in Abbilder verwandelt.

Bei Linux war ich die ersten Jahre begeistert von Partimage, welches perfekt
ext3 aber auch ReiserFS oder jfs gesichert hat. Doch mit ext4 hörte die Unterstützung auf.
Als alternative habe ich partclone gefunden welches rein auf cli Basis das gleiche tut.
Der Unterschied ist nur das es auch mit ext4 zurecht kommt.
Sowohl Partimage wie auch partclone arbeitet auf Sektorbasis und erstellt so
ein 1:1 Kopie des Systems.

Bis zur Version 4.5.2 war partclone mit auf der RettungsCD und sicherte mir
alle Dateisysteme. Doch danach verschwand es. Erst als die RettungsCD nicht mehr
Gentoo sondern Arch als Basis nutze kam das Programm wieder dazu. Aktuell habe ich
immer die Version 6.0.3 auf nem Stick mit dabei.

Neben dem sehr nützlichen Programm partclone finden sich auch diverse Rettungsprogramme
darauf, z.b. um ein Windows Kennwort neu zu setzten, oder Daten von defekten Datenträgern
zu retten.

Seit meinem ersten Kontakt mit der CD kann ich mir ein Computer-Leben ohne das
Rettungssystem nicht mehr vorstellen. Selbstverständlich unterstützt die Version 6
auch Computer mit UEFI.

Nachdem, wie vorige Woche angekündigt, die Umstellung der Blogsoftware eigentlich gestern schon geplant war, aber wieder viele andere Sachen dazwischen gekommen sind, ist es nun endlich soweit: Der neue Blog ist online.

Gut, dem ein oder anderen mag es aufgefallen sein: Hier wird (noch) das Standardtheme von Ghost verwendet, und keiner der alten Artikel ist hier auffindbar. Ersteres dauert noch einige Zeit, aber letzteres ist zwischenzeitlich gelöst: Unter archiv.kopfkrieg.org sind alle bisherigen Artikel einsehbar. Ich werde diese natürlich im Laufe der nächsten Tage migrieren, aber bis dahin muss einfach auf dieses Provisorium zurückgegriffen werden. Entschuldigt das bitte.

Das Design folgt auch noch, im Moment bin ich überhaupt erst einmal froh, dass das heute noch etwas geworden ist. Der Tag bräuchte für mich einfach mehr Stunden.

Wer den RSS-Feed abonniert hatte wird möglicherweise auch etwas enttäuscht sein, denn auch die Feeds und Kategorien werden überarbeitet, und funktionieren deswegen nicht mehr so wie erwartet.

Mit Firefox 71 ersetzt Mozilla den bisherigen Zertifikats-Betrachter von Firefox durch eine neue mit Webtechnologie umgesetzte Oberfläche.

Infos zum TLS-Zertifikat einer Website hat Firefox bislang in einem separaten Fenter angezeigt.

Mit Firefox 71 verschwindet das Fenster. Dann verwendet Firefox einen neuen Zertifikats-Betrachter, welcher in einem Tab statt in einem separaten Fenster angezeigt wird und mit moderner Webtechnologie umgesetzt ist. Auch andere Teile von Firefox wurden in den letzten Monaten mit Webtechnologie neu entwickelt, darunter die Adressleiste, der Add-on Manager (beides Firefox 68) und die Konfigurations-Oberfläche about:config, welche in ihrer neuen Form bald ausgeliefert werden wird.

Die Neu-Implementierung des Zertifikat-Betrachters basiert auf der Firefox-Erweiterung Certainly Something von Mozilla-Entwicklerin April King und wurde im Rahmen eines Outreachy-Praktikums in Firefox integriert.

Firefox 71 erscheint nach aktueller Planung am 10. Dezember 2019.

Der Beitrag Firefox 71 bekommt neuen Zertifikats-Betrachter erschien zuerst auf soeren-hentzschel.at.

Mozilla bietet als neuen Service ab sofort kostenpflichtigen Premium-Support für Firefox im Unternehmen an.

Unternehmen können ab sofort von einem Premium-Support für Firefox Gebrauch machen. Während Firefox weiterhin für alle kostenfrei bleibt und allgemeiner Support wie gehabt über eine freie Wissensdatenbank und Community-Support stattfindet, bietet der Premium-Support spezielle Vorteile für Unternehmen.

So erhalten Kunden Zugriff auf das sogenannte Mozilla Enterprise Client Service Desk, wo sie Hilfe zur Anpassung und Verteilung von Firefox im Unternehmen erhalten. Es gibt Service-Level-Agreement (SLA) für kritische Sicherheits-Fixes und Fehler können privat gemeldet werden. Auch zur Produkt-Roadmap kann beigetragen werden, indem Ideen für neue Funktionen dem Produkt-Management mitgeteilt werden, wobei dies natürlich keine Implementierung in Firefox garantiert.

Preislich startet der Premium-Support bei 10 Dollar pro Installation, wobei das Sales-Team für weitere Details zu kontaktieren ist. Eine eigene Seite beantwortet wichtige Fragen zum Service-Level-Agreement (SLA).

Der Beitrag Firefox: Mozilla startet Premium-Support für Unternehmen erschien zuerst auf soeren-hentzschel.at.

Nach Firefox Monitor und Firefox Lockwise hat Mozilla seinen nächsten Dienst mit Privatsphäre-Fokus unter der Firefox-Dachmarke gestartet: Firefox Private Network. Die öffentliche Beta des VPNs ist derzeit allerdings nur für Nutzer in den USA verfügbar.

Mozilla baut sein Produkt-Portfolio rund um das Thema Privatsphäre unter der Firefox-Marke weiter aus. Nicht nur der Firefox-Browser hat in den letzten Monaten verstärkt Privatsphäre-Verbesserungen erhalten, auch wurde mit Firefox Lockwise ein Passwort-Manager für Android und iOS entwickelt und mit Firefox Monitor gibt es einen Dienst, welcher überprüft, ob die eigene E-Mail-Adresse schon einmal Teil eines bekannten Datenlecks geworden ist. Mit Firefox Private Network kommt nun in Zusammenarbeit mit Cloudflare ein VPN dazu.

Firefox Private Network verfolgt primär zwei Ziele. Zum einen soll sämtlicher Verkehr, welcher über den Browser abgewickelt wird, verschlüsselt werden, um so sensible Daten wie Passwörter, E-Mails oder Kreditkarteninformationen vor Angreifern zu schützen. Zum anderen wird aber auch gezielte Werbung erschwert, da der tatsächliche Standort vor Websites und Werbe-Netzwerken versteckt wird.

Der Nutzer muss nicht mehr tun als eine Firefox-Erweiterung zu installieren und sich in seinen Firefox Account einzuloggen. Über ein Symbol in der Navigationssymbolleiste kann Firefox Private Network jederzeit ein- und ausgeschaltet werden.

Firefox Private Network ist während der Betaphase kostenlos. Die spätere Preisstruktur steht zu diesem Zeitpunkt noch nicht fest. Der Dienst ist derzeit nur in den USA verfügbar.

Der Beitrag VPN: Mozilla startet Public Beta von Firefox Private Network erschien zuerst auf soeren-hentzschel.at.

EPEL steht für Extra Packages for Enterprise Linux und ist die wichtigste externe Paketquelle für RHEL- und CentOS-Anwender. EPEL hat deswegen eine so große Bedeutung, weil Red Hat traditionell viel weniger Pakete ausliefert/pflegt als beispielsweise Debian oder Ubuntu. RHEL/CentOS-Anwender, die darüberhinaus weitere Software-Pakete benötigen, richten deswegen zumeist die EPEL-Paketquelle ein.

Wer nach der Freigabe von Red Hat Enterprise Linux 8 (RHEL 8) sofort den Umstieg wagte, musste allerdings ohne EPEL auskommen. Weil Red Hat die Organisation seiner eigenen Pakete grundlegend verändert hat (Modularisierung durch das AppStream-Verfahren), muss auch das EPEL-Repository vollkommen neu organisiert werden — und das kostet Zeit.

Für early adopters bestand zwar grundsätzlich die Möglichkeit, einfach das alte EPEL-7-Repository einzurichten; wirklich praktikabel war das aber nicht, weil sich viele Pakete aufgrund unerfüllbarer Paketabhängigkeiten nicht installieren ließen. (Besonders betroffen waren Python-Pakete.)

EPEL-8-Rollout in mehreren Phasen

Mitte August wurde nun EPEL 8 offiziell freigegeben. Übertriebene Freude ist aber noch nicht angebracht. Wegen der bereits skizzierten Umstrukturierung ist das Paketangebot in EPEL 8 noch viel kleiner als in EPEL 7. Warum das so ist, hat der EPEL-Entwickler Stephen Smoogen bereits im Juli 2019 in seinem Blog skizziert. Demnach wird das EPEL-8-Rollout in mehreren Schritten erfolgen:

• EPEL 8.0: Das aktuelle Release ist nur der erste Schritt, den Stephen Smoogen »EPEL 8.0« nennt. Es nutzt die Modularisierungsfunktionen von RHEL 8 noch nicht.
• EPEL 8.1 wird ca. im November 2019 erwartet und wird möglicherweise parallel zu RHEL 8.1 freigegeben. Es soll RHEL-Module teilweise unterstützen.
• Erst EPEL 8.2 (Zeitraum der Fertigstellung noch unklar) soll vollständig mit dem neuen Modulkonzept von RHEL 8 kompatibel sein.

EPEL 8.0 in der Praxis

Das Einrichten der EPEL-Paketquelle ist unverändert einfach:

yum install https://dl.fedoraproject.org/pub/epel/epel-release-latest-8.noarch.rpm

Hinter den Kulissen werden damit die Repository-Dateien /etc/yum.repos.d/epel*.repo eingerichtet. Anschließend können Sie sich mit yum einen Überblick über die aktuell verfügbaren Pakete verschaffen:

yum repository-packages epel list

Verfügbare Pakete
BackupPC.x86_64             4.3.1-2.el8     epel
BackupPC-XS.x86_64          0.59-3.el8      epel
CGSI-gSOAP.x86_64           1.3.11-7.el8    epel
CGSI-gSOAP-devel.x86_64     1.3.11-7.el8    epel
Field3D.x86_64              1.7.2-16.el8    epel
Field3D-devel.x86_64        1.7.2-16.el8    epel
Lmod.x86_64                 8.1.10-2.el8    epel
...

yum repository-packages epel list | wc -l

971

(Nur zum Vergleich: Unter CentOS 7 mit der EPEL-7-Paketquelle kommt yum repository-packages epel list | wc -l auf über 13.000 Pakete!)

Ob Sie mit EPEL 8 im aktuellen Zustand glücklich werden, hängt naturgemäß stark davon ab, welche Pakete Sie brauchen. Ich installiere üblicherweise als Erstes das Paket joe. Es enthält neben anderen Editoren den winzigen Emacs-Klon jmacs, mit dem ich bevorzugt Konfigurationsdateien verändere. (jmacs ist in seinen Grundkommandos zum Emacs kompatibel. Seine größten Vorteile sind ein blitzartiger Start und ein sparsamer Umgang mit Ressourcen.) Um es kurz zu machen: joe steht aktuell nicht zur Verfügung, eben sowenig wie jove (noch ein Emacs-Klon).

Auf meiner EPEL-Hitliste ganz oben steht des Weiteren fail2ban. Dieses Programm blockiert IP-Adressen, wenn von dort wiederholt fehlerhafte Login-Versuche erfolgen. fail2ban ist damit ein wichtiger Schutz vor Angreifern, die (SSH-)Passwörter durch systematisches Probieren erraten möchten. fail2ban ist erfreulicherweise bereits in EPEL 8.0 enthalten.

Dritter Testkandidat war certbot, um Let’s-Encrypt-Zertifikate einzurichten. Leider Fehlanzeige in EPEL 8.0 :-(

Quellen

• https://fedoraproject.org/wiki/EPEL
• https://smoogespace.blogspot.com/2019/07/epel-8-production-layout.html
• https://smoogespace.blogspot.com/2019/08/announcing-epel-80-official-release.html
• https://lwn.net/Articles/796202/
• https://linuxconfig.org/redhat-8-epel-install-guide
• https://fedoraproject.org/wiki/Infrastructure_2020/EPEL-8 (nicht aktuell)

OMV lässt sich mittels Extensions aus den OMV-Extras automatisch herunterfahren und per RTC-Wake wieder aufwecken. Durch umfangreiche Einstellungsmöglichkeiten kann man das NAS in Zeiten der Nicht-Nutzung schlafen schicken und Energie sparen.

Im Gegensatz zu vielen anderen NAS-Betriebssystemen bietet OMV einige Extensions zum Energiesparen. Bei den heutigen Energiekosten auf dem deutschen Markt und unter Berücksichtigung der aktuellen Klimadebatte sicherlich ein wichtiges Alleinstellungsmerkmal.

Methode 1: Autoshutdown

Vor einigen Jahren war das Autoshutdown-Plugin hier schon mal Thema (siehe: WOL und Autoshutdown - Energie sparen mit OMV). Damals war es das Ziel das NAS komplett herunterzufahren. Das ist mit meiner aktuellen Hardware nicht mehr notwendig, aber man kann das Plugin auch sehr gut so konfigurieren, dass das NAS lediglich in den Suspend-Modus geht.

Die Oberfläche hat sch seitdem kaum geändert. Die gewählten Einstellungen sehen nun wie folgt aus:

In einem definierten Zeitraum (10-20 Uhr) ist das NAS immer in Betrieb und fungiert als Sicherungsziel (siehe: openmediavault 5 mit Time Machine Unterstützung. Ab 20 Uhr kann das NAS sich schlafen legen, sofern mein Arbeits-Mac ebenfalls nicht mehr in Betrieb ist. Daher die Überprüfung ob die IP 55 noch aktiv ist.

Alle anderen Einstellungen können daher für das gewählte Szenario deaktiviert werden.

Methode: 2: Geplante Aufgaben

Sofern keine Überprüfung auf einen aktiven Rechner notwendig ist kann man das Problem auch einfach mit einer geplanten Aufgabe im Menüpunkt Energieverwaltung lösen.

Hier kann man das NAS zu einem definierten Zeitpunkt Herunterfahren, neu starten oder in den Bereitschaftsmodus versetzen.

Starten

Um das NAS morgens wieder zu starten benötigt es eine weitere Extension openmediavault-wol. Hier kann man via Rtcwake einen Startzeitpunkt festlegen. Dazu wählt man die Option "No - Don't suspend. Sets RTC wakeup time only" und legt eine Uhrzeit fest. Das ist nicht sonderlich selbsterklärend aber das reine Wakealarm-Plugin scheint (noch) nicht auf OMV 5 portiert zu sein.

Wenn das nicht funktioniert (das Plugin scheint ein wenig wackelig zu sein) kann man auch auf der Konsole rtcwake entsprechend konfigurieren. Das ist allerdings nicht ganz trivial.

Bilder:

Einleitungs- und Beitragsbild von FreePhotosART via pixabay

Das kommende OMV 5 basiert auf Debian 10 und bringt daher eine für Time Machine geeignete Samba-Version mit. Darüber hinaus haben die Entwickler dies aber auch in der Oberfläche berücksichtigt. Es ist daher sehr einfach ein OMV-NAS zum Sicherungsziel für einen Mac zu machen.

Früher war dies nur mit einer AFP Freigabe möglich (siehe: Time Machine auf openmediavault NAS sichern), was Apple als veraltet deklariert hat und zunehmend abschaltet. Vermutlich ist mit dem kommenden macOS "Catalina" endgültig Schluss.

Dazu legt man unter Dateisysteme eine Partition für Time Machine an. Eine eigene Partition ist sinnvoll weil Time Machine erst löscht wenn das Sicherungsziel voll läuft. Dadurch kann man auf einem NAS schnell Platzprobleme bekommen.

Anschließend legt man noch einen SMB-Benutzer an. Im vorliegenden Beispiel einfach als smbshare bezeichnet.

Im weiteren aktiviert man im Menüpunkt SMB/CIFS Samba und legt eine Freigabe an. Die Standardwerte müssen nicht modifiziert werden, lediglich Time Machine support aktiviert werden. Dadurch werden die entsprechenden Optionen automatisch gesetzt.

In der smb.conf sieht das dann wie folgt aus:

[TimeMachine]
path = /srv/dev-disk-by-label-TMB/TimeMachine/
guest ok = no
guest only = no
read only = no
browseable = yes
inherit acls = yes
inherit permissions = no
ea support = no
store dos attributes = no
fruit:encoding = private
fruit:locking = none
fruit:metadata = netatalk
fruit:resource = file
fruit:time machine = yes
vfs objects = catia fruit streams_xattr
printable = no
create mask = 0664
force create mode = 0664
directory mask = 0775
force directory mode = 0775
hide special files = yes
follow symlinks = yes
hide dot files = yes
valid users =
invalid users =
read list =
write list =

Zu guter letzt muss im Menüpunkt Freigegebener Ordner noch die notwendigen ACL für den Zugriff gesetzt werden. Hierzu räumt man einfach dem smbshare genannten Benutzer Lese- und Schreibrechte auf den Freigabeordner ein.

Die nun erstellte und konfigurierte Freigabe findet macOS automatisch und kann in den Systemeinstellungen unter Time Machine als Sicherungsziel ausgewählt werden. Sofern macOS per FileVault verschlüsselt sein sollte (siehe: macOS mit FileVault verschlüsseln) sollte die Sicherung ebenfalls verschlüsselt werden. Das System warnt in diesem Fall allerdings auch explizit vor einer unverschlüsselten Sicherung. Technisch legt macOS in der SMB-Freigabe ein Sparsebundle ab, das sich in jedes macOS-System einbinden und auch manuell durchsuchen lässt.

Bilder:

Einleitungs- und Beitragsbild von FreePhotosART via pixabay

Manchen Leuten ist scheinbar ab und zu sehr langweilig. Dieses Wochenende habe ich doch tatsächlich eine E-Mail mit Hinweisen auf den einen oder anderen Fehler in meinen Artikeln erhalten. Im Grunde waren es nur Rechtschreibfehler.

In der E-Mail wurde ich auf gefragt ob ich für solche Sachen nicht ein öffentlicht zugängliches Repository anbieten kann. Kann ich. Es ist unter https://github.com/Fryboyter/Hugo erreichbar.

Aber würde ich selbst einen Artikel lesen und dann das Repository aufrufen und die Datei suchen wen ich einen Fehler finden würde? Eher nicht. Daher habe ich nun einen Link unterhalb der jeweilige Artikelüberschrift eingebaut, der direkt auf die betreffende Datei bei Github verweist.

Als erstes habe ich hierfür in der Konfigurationsdatei von Hugo (config.toml) den Bereich [params] um einen Verweis auf das Repository eingetragen.

[params]
ghrepo = "https://github.com/Fryboyter/Hugo/"

Als nächstes habe ich das verwendete Theme (single.html und list.html) von fryboter.de wie folgt erweitert.

| <a href="{{.Site.Params.ghrepo}}edit/master/content/{{.File.Path}}" >Bei Github bearbeiten</a>

Hiermit wird das in der Datei conifg.toml hinterlegte Verweis auf das Respository genutzt. Dieser wird dann einfachum edit/master/content/ erweitert, da sich dieser Teil nicht ändert. Ganz am Schluss wird mit {{.File.Path}} auf die betreffende Datei verlinkt.

Im Grunde ist das mal wieder ziemlich simpel. Huge gefällt mir immer mehr.

DNS over HTTPS, kurz: DoH, soll die Sicherheit und Privatsphäre der Nutzer verbessern. Nach einer langen Testphase wird Mozilla ab Ende September damit beginnen, DoH für erste Nutzer von Firefox standardmäßig auszurollen.

Was ist DNS over HTTPS?

Wikipedia beschreibt DNS over HTTPS mit den folgenden Worten:

DNS over HTTPS (DoH) ist ein Protokoll zur Durchführung einer DNS-Auflösung über das HTTPS-Protokoll. Das Ziel ist es, die Privatsphäre und Sicherheit der Benutzer zu erhöhen, indem das Abhören und Manipulieren von DNS-Daten durch Man-in-the-Middle-Angriffe verhindert wird. Neben der Verbesserung der Sicherheit sind weitere Ziele von DNS über HTTPS, die Leistung zu verbessern und DNS-basierte Zensurmaßnahmen zu verhindern. DNS over HTTPS wurde am 19. Oktober 2018 als RFC 8484 standardisiert.

Wikipedia

DNS over HTTPS in Firefox

Bereits 2017 begann Mozilla die Arbeiten an DNS over HTTPS, seit Juni 2018 führt Mozilla diverse DoH-Experimente mit Firefox-Nutzern durch. Nun steht Mozilla kurz vor der Ausrollung.

Ab Ende September soll DoH für Firefox-Nutzer in den USA ausgerollt werden. Zunächst aber nur für einen kleinen Teil der Firefox-Nutzer, ehe man DoH flächendeckend ausrollen wird. Wann mit einer Ausrollung in Europa zu rechnen ist, ist zu diesem Zeitpunkt noch nicht bekannt.

Mozilla wird standardmäßig zunächst auf 1.1.1.1 von Cloudflare als DNS-Resolver setzen. Der Nutzer kann in den Firefox-Einstellungen aber auch jeden anderen DNS-Anbieter eintragen oder das Feature komplett deaktivieren. Die entsprechende Oberfläche ist bereits in Firefox integriert.

Sobald DoH in Firefox standardmäßig aktiviert wird, wird der Nutzer darüber informiert und erhält eine Möglichkeit, DoH abzuschalten. Keine Aktivierung von DoH findet statt, wenn der Nutzer eine Opt-in-Kindersicherung nutzt oder eine Unternehmenskonfiguration von Firefox entdeckt wird. Letzteres wird dadurch erkannt, dass die Option security.enterprise_roots.enabled auf true gesetzt ist oder durch Vorhandensein einer Enterprise Policy. Bei DNS-Problemen fällt Firefox automatisch auf die DNS-Konfiguration des Betriebssystems zurück.

Der Beitrag DNS over HTTPS (DoH) ab Ende September für erste Firefox-Nutzer erschien zuerst auf soeren-hentzschel.at.

Purism informierte vor kurzem die Interessen für das Librem 5 über die weiteren Pläne. Den bereits mehrfach verschobenen Launch in diesem Jahr schafft man nicht mehr. Vorab gibt es nur eine Kleinserie, die weder bei Hardware, noch bei Software final sein soll.

Ich polarisiere in manchen meiner Blogartikel und bekomme dementsprechend auch gerne - nennen wir es mal - Post in meinen E-Mail Eingang. Doch meine Artikel zu SailfishOS / Jolla (siehe: Jolla / Sailfish OS - Zu enge Staatsverbindungen?) und Purism (siehe: Purism Librem 5 - Bestenfalls eine Experimentalstudie) scheinen bei der Zielgruppe die Knöpfe zum Abschalten von Anstand und Moral getroffen zu haben. Ich schreibe das sonst nicht in dieser Deutlichkeit, aber eigentlich ist so eine Community ein Grund nicht mehr über diese Projekte zu berichten. Wenn man sich derart in einer Filterblase bewegt, dass man Fakten zu Finanzierung (Jolla / Sailfish) oder zum Zustand des Projekts nicht mehr verkraftet ohne ausfallend zu werden, hat man echt ein Problem.

Den heutigen Blogartikel kann ich mir aber nicht verkneifen. Bei der Veröffentlichungen der geplanten Spezifikationen des Librem 5 schrieb ich ja bereits:

Es bleibt zu hoffen, dass Purism in der aktuellen Version lediglich eine Experimentalstudie sieht, wodurch man Feedback einer breiteren Öffentlichkeit erhalten möchte um schnell mit einer weiteren Version nachzulegen.

Das haben zwar einige Fans nicht verkraftet aber Purism sieht das scheinbar selbst so. Weder die Hardware, noch das Gehäuse oder gar die Software werden dieses Jahr auch nur annähernd final sein. Erst im 2. Quartal 2020 (Stand jetzt...) soll ein Gehäuse und eine Software erscheinen, die einen längeren Support bekommt.

Meiner Meinung nach hat sich Purism mit dem Projekt vollkommen verhoben. Ähnlich wie Jolla seinerzeit mit dem Tablet. Der Anspruch eine freie Hardware zu entwickeln und parallel dazu Linux bzw. GNOME tauglich für den Smartphone-Alltag zu bekommen war von Anfang an sehr ambitioniert. Eventuell hätte hier eine stärkere Kooperation mit bestehenden Community-Projekten wie UBports oder Plasma Touch geholfen - man weiß es nicht.

Fakt ist, dass die Hardware mit fortschreitendem zeitlichen Verlauf nicht gerade an Aktualität gewinnt.

Ich halte das Librem 5 in seiner jetzigen Form für gescheitert. Nichtsdestotrotz kann aus dem Projekt noch interessantes hervorgehen. Andere ambitionierte Projekte wie coreboot haben schließlich auch ewig gebraucht um überhaupt nur annähernd relevant für den Endanwender zu werden.

Bilder:
Einleitungs- und Beitragsbild von 3dman_eu via pixabay 

Vor relativ genau sieben Jahren ging meine erste Webseite online. Das Ganze lief mit einem selbst in Python geschriebenen, statischen Blogkompilierer, und nicht ganz zwei Jahre war ich damit auch recht glücklich. Allerdings hatte die Software nur wenige Features, vor allem das automatische generieren von RSS/Atom Feeds hat mir gefehlt.

Im Juli 2014 bin ich dann auf makeblog umgestiegen, und habe mir dazu auch gleich eine neue Domain geholt. Seitdem existiert dieser Blog.

Um jetzt endlich auf den Punkt zu kommen: Ich werde demnächst™ wieder einmal umsteigen. Aber diesmal nicht, weil die bisher verwendete Software Schwächen hätte (tatsächlich kann ich makeblog für statische Seiten nur empfehlen), sondern weil ich in Zukunft auch vermehrt unterwegs Artikel schreiben möchte, und das so einfach wie möglich. Nach langer Suche und vielen Tests werde ich auf Ghost setzen.

Ghost selbst ist, wie auch schon die zwei Programme zuvor, Open Source. Das ganze ist relativ leichtgewichtig (verglichen mit anderen Systemen wie Wordpress), und erlaubt zudem das Erstellen von Artikeln mittels Markdown, was ich als ganz angenehm empfinde. Ich selbst hoste bereits mehrere Instanzen und bin dabei auf noch keine Probleme gestoßen (bei mittlerweile fast einem Jahr). Wer sich vorab ansehen möchte, wie so ein Blog aussehen kann: Bitte hier klicken.

Jetzt ist es so, dass ich den Umzug schon länger geplant habe, aber bisher nicht wirklich dazu gekommen bin das Standard-Theme von Ghost anzupassen, geschweige denn die Artikel zu portieren. Heißt konkret: Die neue Seite wird nächsten Samstag (14.09.2019) online gehen, und komplett anders aussehen wie diese hier. Die jetzige Seite wird in ein Archiv verschoben. Das Design werde ich nach und nach portieren, ebenso wie die Artikel. Wer meinen RSS/Atom Feed abonniert hat wird manche Artikel möglicherweise kurzzeitig doppelt sehen - dafür möchte ich mich vorweg entschuldigen, leider geht es nicht anders.

Nächste Woche wird es dazu dann auch nochmal einen gesonderten Artikel geben. Bis dahin - stay tuned!

Im Podcast bei netzpolitik ging es um den Einsatz von freier Software in der Verwaltung (siehe: netzpolitik.org Podcast zu freier Software). Es wurde zu Recht auf Schwierigkeiten bei den Ausschreibungen und Anforderungen hingewiesen. Auf wichtige Stärken der gegenwärtigen - überwiegend, aber nicht ausschließlich proprietären - Lizenzmodelle wurde nicht eingegangen.

Ursprünglich wollte ich diesen Kommentar bereits direkt in den Artikel schreiben, aber das hätte den Podcast mit zu viel ungerechtfertigter Kritik überzogen und zu weit weg vom Thema geführt.

Bezüglich der Hemmnisse beim Einsatz von freier Software in der Verwaltung gibt es oft zwei Argumente. Erstens seien die Ausschreibungen nicht auf OSS zugeschnitten, zweitens müssten sich doch nur mal genug staatliche Stellen zusammen tun um gemeinsam etwas voran zu bringen. Bei letzterem wird immer gerne auf Russland mit seinen Ambitionen in Richtung freier Software verwiesen.

Dahinter steht meiner Meinung nach ein mangelndes Verständnis davon wie ein demokratischer Staat wie Deutschland funktioniert und eine wenig begrüßenswerte Sympathie für autokratische Systeme. Deutschland ist weder ein Zentralstaat, noch eine Kommandowirtschaft oder gar ein autokratisches System wo ein Präsidialamt einfach mal einen Systemwechsel anordnet und die Untergeben wenigstens so tun, als ob sie es umsetzen. Deutschland ist ein föderales System in dem viele Glieder eine sehr große Unabhängigkeit genießen. Dies gilt natürlich auch für die IT Strukturen.

Das bedeutet ganz konkret, dass nicht nur Bund und Länder als vergleichsweise große Verwaltungseinheiten ihre eigenen Strukturen haben, sondern viele nachgeordnete Behörden und Einrichtungen ebenfalls viele Freiheiten genießen. Innerhalb dieser Einrichtungen gibt es dann teilweise noch unabhängige Substrukturen mit eigenen Anforderungen und Beschaffungsprozessen. All das fällt unter die Oberkategorie Öffentlicher Dienst bzw. Verwaltung.

Das kann man jetzt als Grundübel bezeichnen oder auch nicht. Im Grunde genommen fährt Deutschland damit sehr gut, weil zentralistische Strukturen sehr oft an den Anforderungen vorbei entscheiden. In jedem Fall sind dies die Rahmenbedingungen mit denen man in Deutschland umgehen muss.

Das überwiegend proprietäre System harmoniert da nahezu perfekt. Nun kann man hier die Henne/Ei Frage stellen. Funktioniert das System perfekt weil sich der Staat darauf eingestellt hat oder haben die Entwicklungsfirmen einfach ein passendes Modell für staatliche Stellen geschaffen. Gleichwohl klappt es relativ zuverlässig. Lizenzen und Supportverträge kosten zwar viel Geld, lassen sich aber in die Jahresbudgets einbeziehen. Gleichzeitig trägt man nicht die wirtschaftliche Verantwortung für das Gesamtprojekt und die zukünftige Entwicklung, sondern diese liegt beim Lizenzgeber. Funktioniert etwas nicht wechselt man schlimmstenfalls den Anbieter und bezahlt ein Migrationsprojekt mit begrenztem Umfang. Genau aus diesem Grund sind auch solche Anbieter von freier Software so erfolgreich, die sich in dieses System eingefügt haben. SUSE oder Red Hat bieten beispielsweise ein feststehendes Produkt (z. B. Linux Server) mit festen Supportverträgen, die sich über mehrere Jahre erstrecken. Die Verwaltung greift hier bereits sehr gerne auf Open Source Software zurück. Es ist also nicht so, dass der Staat FOSS gänzlich meidet, das Modell funktioniert sehr gut bei bereits bestehenden Produkten.

Anders sieht das bei den Leerstellen aus. Bei der Entwicklung für diese weißen Flecken scheitert das von Enthusiasten vorgetragene Entwicklungsmodell für freie Software. Hier wird immer pauschal gesagt, man müsste es nur entwickeln, Geld wäre schließlich ohne Lizenzgebühren genug da. Erstens ist das eine schwer zu beziffernde Rechnung, denn Lizenzgebühren über viele Jahre gegen Entwicklungskosten lassen sich nur schwer kalkulieren. Wohl stehen mehr Kontrolle und ggf. auch mehr Sicherheit auf der Positiv-Liste. Dafür könnte man theoretisch die eventuellen Mehrkosten in Kauf nehmen.

Ganz konkret in der deutschen Wirklichkeit bedeutet das aber, als Entscheidungsträger in einer Institution oder Abteilung müsste man sich dann aber erstmal deutschlandweit (oder gar europaweit) umsehen ob andere Einrichtungen etwas ähnliches brauchen und mich mit diesen vernetzen. Dann müsste man von den lokalen Anforderungen abstrahieren, etwas allgemeingültiges entwickeln lassen und dann für den lokalen Gebrauch wieder anpassen. Das ganze unter Zeitdruck, da Anforderungen selten viele Jahre im Vorfeld klar werden.

Keine Verwaltung kann dies aus den bestehenden Strukturen her leisten. Der berühmte Wasserkopf betrifft ganz sicher nicht die IT-Mitarbeiterzahlen. Dazu müsste also externe Expertise eingekauft (höre ich Beraterskandal?) werden oder die Institutionen müssten zentrale Entwicklungszentren gründen. Hier wäre wieder die Frage wie dies aus den sehr starren Finanzierungsmodellen bezahlt werden soll, da das Investitionen mit langer Laufzeit sind. Diese aber immerhin theoretisch möglichen neuen Entwicklungszentren wären naturgemäß im ÖD angesiedelt und müssten auf dem angespannten Arbeitsmarkt um Fachkräfte konkurrieren (siehe HIS im Hochschulsektor). Es ist kein sonderlicher Pessimismus von Nöten um jedes dieser Projekte zu einem kleinen BER werden zu lassen.

Das kann und wird niemals funktionieren. Da wo bestehende Open Source Produkte konkurrenzfähig sind finden sie bereits Verwendung. Es ist ja nicht so, dass momentan generalstabsmäßig Open Source Software gemieden wird. Freie Software ist auf vielen Desktoparbeitsplätzen allgegenwärtig, im Server-Bereich sowieso. In der Cloud hat Nextcloud gerade einen richtigen Clou landen können. All diese Projekte bestanden aber schon bevor staatliche Stelle sich für eine Nutzung entschieden. Neuentwicklungen in einem größeren Maßstab aus den Institutionen heraus - mit dem Ziel neue Aufgaben zu lösen oder bestehende Plattformen zu ersetzen - werden nicht funktionieren.

Nichtsdestotrotz ist es immer wieder schön, wenn einzelne Institutionen oder ganze Bundesländer wie Schleswig-Holstein sich dem Thema annehmen und zumindest Absichtserklärungen formulieren. Vielleicht entsteht daraus etwas mit Perspektive.

Bilder:
Einleitungs- und Beitragsbild von qimono via pixabay

Go ist eine Open-Source Programmiersprache, welche von Google 2009 entwickelt wurde. Die Sprache ist bei vielen Anwendungen beliebt, darunter Docker oder Kubernetes. 

Nun ist eine neue Version 1.13 erschienen, welche neben Sicherheitsfeatures in den Standardeinstellungen auf TLS 1.3 setzt.
Module welche von den Go Servern geladen werden, sind nun durch eine Checksummenprüfung abgesichert.

Weitere Neuerungen verrät das Changelog

Doch wie kommt Go überhaupt auf das eigene System?

Installation von Golang auf Ubuntu

Als erstes möchte ich die manuelle Installation betrachten.

Auf der Downloadseite muss zunächst nach der offiziellen Version gesucht werden.

wget https://dl.google.com/go/go1.13.linux-amd64.tar.gz

Nach dem Download sollte der Hashwert überprüft werden.

sha256sum go1.13.linux-amd64.tar.gz

    68a2297eb099d1a76097905a2ce334e3155004ec08cdea85f24527be3c48e856  go1.13.linux-amd64.tar.gz

Danach folgt das Entpacken, wobei ihr beim Pfad natürlich auch einen anderen verwenden könnt.

sudo tar -C /usr/local -xzf go1.13.linux-amd64.tar.gz

Nun den PATH anpassen und folgende Zeile unten anfügen.

sudo nano $HOME/.profile

    export PATH=$PATH:/usr/local/go/bin

Die neue PATH Variablen laden.

source ~/.profile

Nun kann der finale Test erfolgen, wenn alles klappt solltet ihr folgendes Ergebnis sehen.

go

Go is a tool for managing Go source code.

Usage:

        go command [arguments]

The commands are:

        build       compile packages and dependencies
        clean       remove object files and cached files
        doc         show documentation for package or symbol
        env         print Go environment information
        bug         start a bug report
        fix         update packages to use new APIs
        fmt         gofmt (reformat) package sources
        generate    generate Go files by processing source
        get         download and install packages and dependencies
        install     compile and install packages and dependencies
        list        list packages
        run         compile and run Go program
        test        test packages
        tool        run specified go tool
        version     print Go version
        vet         report likely mistakes in packages

Use "go help [command]" for more information about a command.

Installation von Go via apt auf Ubuntu

Golang kann unter Ubuntu ebenfalls über den Paketmanager installiert werden. Dazu muss zunächst ein extra Repository hinzugefügt werden.

sudo add-apt-repository ppa:longsleep/golang-backports
sudo apt update
sudo apt install golang-go

Jetzt könnt ihr euch mit Go austoben.

Im Netz findet ihr jede Menge Beispiele was damit möglich ist.
Zum Beispiel hier oder hier.

Ein eigenes Programm ist schnell geschrieben, dazu einfach folgende Schritte ausführen.

Ein neues Verzeichnis anlegen und eine erste Datei anlegen.

mkdir -p /home/user/hello

nano /home/user/hello/helloworld.go


        package main

        import "fmt"

             func main() {
                  fmt.Printf("Hello Go World \n")
             }

Datei builden und ausführen.

cd /home/user/hello

go build

./hello

    Hello Go World

Praktischerweise gibt es eine Online Spielwiese, die zum Probieren einlädt.

Es muss somit zunächst nicht zwingend auf der Kommandozeile gearbeitet werden.

PS. Natürlich kann Golang auch über die vorhandenen Ubuntu Pakete mit sudo apt install golang installiert werden, allerdings erhaltet ihr hier nicht die aktuellste Version.

Im Podcast NPP 183 stellen Matthias Kirschner und Katharina Nocun die Initiative Public Money, Public Code vor. Daneben geht es sehr viel um freie Software allgemein. Es lohnt sich in den Podcasts rein zu hören.

Inhaltlich werden folgende Aspekte behandelt:

• Die Bedeutung der vier Freiheiten freier Software für die Gesellschaft
• Prinzip "Freie Software"
• Unsicherheit der gegenwärtigen proprietären (Staats-)Infrastruktur
• Vorstellung der Initiative PMPC und ihren neuen Ansatz
• Bedeutung der stetig wachsenden IT in der Staatsverwaltung und ihre Auswirkungen auf demokratische Strukturen ("Wer kontrolliert die Geräte?")
• Lizenzmodelle unfreier Software mit stark restriktiven Bestandteilen
• Abkehr von Leuchtturmmodellen (LiMux)
• Wirtschaftsmodelle bei freier Software
• Probleme bei der Berücksichtigung in staatlichen Ausschreibungen.
• Eigentum und Urheberrecht

Kirschner und Nocun vertreten die Anliegen sehr eloquent. Einige Beispiele zur Funktionsweise von freier Software sind sehr schön und verdeutlichten die Prinzipien. Schade ist, dass der Gastgeber wenig kritisch nachfragt. Sowohl Kirschner, als auch Nocun äußern ab und an Allgemeinplätze, bei denen kritische Nachfragen angebracht gewesen wären.

Sehr kritisch fand ich im späteren Verlauf des Podcasts die Inhalte zum Urheberrecht, sowie zu kapitalistischen Wirtschaftsmodellen. Es gibt eigentlich keinen direkten Zusammenhang zwischen freien Lizenzen und dem geistigen Urheberrecht. Sowohl die GPL, als auch die Creative Commons Lizenzen bauen letztlich auf das Urheberrecht auf. Mit der zumindest unterschwellig geäußerten Forderung nach einer Abschaffung des Urheberrechts begeben sich die drei Gesprächspartner auf dünnes Eis. Das ist bedauerlich, weil die FSFE ansonsten versucht weniger radikal aufzutreten und dadurch größere Zustimmung zu erreichen. Hier sieht man vermutlich auch die Auswirkungen der Urheberrechts-Kampagne und ihre Auswirkungen auf andere Bereiche.

Bilder:
Einleitungs- und Beitragsbild von Tumisu via pixabay

Mich fragen ja häufiger mal Leute, was sich so in den letzten Git-Versionen getan hat. Das frage ich mich natürlich auch immer mal wieder und lese jedes Mal die Release-Notes und finde in der Regel nichts spannendes was mich als Endnutzer interessiert. Ja, Verbesserungen der Performance und Fehlerkorrekturen sind gut und wichtig – als „normaler“ Nutzer merkt man davon allerdings recht wenig.

Interessant ist allerdings die Neuerung in Git Version 2.23, die Mitte August veröffentlicht wurde. Es gibt nun zwei experimentelle neue Kommandos: git switch und git restore. Beide koexistieren zu dem bisherigen Kommando git checkout was den gängigen Git Nutzer bekannt sein sollte. Wie zuvor erwähnt, handelt es sich um „experimentelle“ Kommandos, das heißt, die Funktion wird zwar bleiben, die Parameter können sich allerdings noch weiter verändern und sind möglicherweise noch fehlerbehaftet.

In diesem Blogpost begutachte ich die beiden neuen Befehle und zeige die Unterschiede zu dem bisherigen Kommando auf.

Status Quo

Bevor wir uns die neuen Befehle anschauen lohnt es sich noch einmal aufzufrischen, wie der Status Quo ist und warum die neuen Befehle praktisch und sinnvoll sind.

Der Subbefehl checkout wird vielfältig in Git eingesetzt. Der wohl gängigste Einsatz ist der Wechsel von einem auf den anderen Branch:

$ git checkout master

Dieser Befehl wechselt vom aktuellen Branch auf den Branch master. Es ist auch möglich einen neuen Branch zu erstellen und direkt darauf zu wechseln:

$ git checkout -b feature/1337

Dieser Befehl nimmt den aktuellen Branch, auf dem man sich gerade befindet, und legt den Branch namens feature/1337 an und wechselt direkt da hin. Möchte man einen anderen Branch als Basis nehmen, tippt man den Namen dahinter als weiteren Parameter ein. Alternativ lässt sich mit git branch feature/1337 ebenfalls ein Branch anlegen, auf dem man nicht automatisch hin wechselt.

Checkout als Befehl zum Wechseln und Erzeugen von Branches sollte für die meisten geübten Git-Nutzern bekannt und gängig sein. Genau so lege ich immer meine Branches auf der Kommandozeile bisher an.

Der andere Modus von Checkout ist das Auschecken von Dateien aus anderen Branches, Revisionen bzw. dem Verwerfen von Änderungen aus dem Staging-Bereich und der Arbeitskopie. Dies wird durch die Nutzung von doppelten Minuszeichen -- ermöglicht.

In der bereits versionierten Datei index.html sind Änderungen vorhanden, die nicht im Staging-Bereich enthalten sind. Um die Änderungen zu verwerfen, kann folgender Befehl verwendet werden:

$ git checkout -- index.html

Somit sind die Änderungen in der Arbeitskopie verworfen und können nicht wiederhergestellt werden. Der Inhalt der Datei index.html wurde auf den Stand von HEAD – also dem aktuell ausgecheckten Commit – zurückgesetzt. Der Befehl kann auch verwendet werden, um einzelne Dateien aus einem anderen Branch auszuchecken und im aktuellen Projekt abzulegen.

Dieser Befehl würde dann wie folgt lauten:

$ git checkout feature/1337 -- index.html

Die Datei index.html aus dem Branch feature/1337 wird dann von Git im aktuellen Projektverzeichnis abgelegt. Mit einem git status wird dann auch aufgelistet, dass sich die Datei verändert hat. Dies natürlich nur unter der Voraussetzung, dass sich die Datei in beiden Branches unterscheiden. Statt eines Branches können auch andere Revisionen angegeben werden. Denn nicht vergessen: ein Branch sind letztendlich auch nur Zeiger auf einen bestimmten Commit, der stetig aktualisiert wird.

Status Futurus

Mit den neuen Kommandos switch und restore wird alles besser! Na gut, zumindest wird deutlich einfacher zu verstehen, was diese tun. Mit beiden Befehlen werden alte Zöpfe nach und nach abgeschnitten und die Befehle klarer und besser zu nutzen.

Git-Nutzer wissen vermutlich, dass viele Befehle nicht so offensichtlich sind und es nicht unbedingt auf Anhieb nachvollziehbar ist, was welcher Befehl tut. Das gute Beispiel ist eben git checkout womit man sowohl Branches wechseln kann, als auch Dateien aus anderen Revisionen holen kann.

git switch

Für das Wechseln von Branches gibt es jetzt den Befehl git switch. Mit diesem lassen sich ebenfalls neue Branches anlegen. Das Wechseln von einem Branch funktioniert wie äquivalent:

$ git switch feature/1337

Für das Erstellen eines neuen Branches existiert der Parameter -c:

$ git switch -c feature/1337

Dies ist äquivalent zu git checkout -b feature/1337. Interessant ist auch der Parameter -C, der mit einem großem C geschrieben wird. Dies ist effektiv ein forciertes Anlegen eines neuen Branches, da der Zielbranch hart überschrieben wird. Hier gilt es also aufzupassen.

git restore

Der zweite Befehl ist git restore. Wie der Name schon verrät, lassen sich Dateien wiederherstellen.

Die erste Nutzungsmöglichkeit ist bereits, wenn man eine neue Datei anlegt und diese zum Staging-Bereich hinzufügt.

$ echo "Hallo" > hallo.txt
$ git add hallo.txt
$ git status
Auf Branch master
Zum Commit vorgemerkte Änderungen:
  (benutzen Sie "git restore --staged <Datei>..." zum Entfernen aus der Staging-Area)
        neue Datei:     hallo.txt

Git zeigt schon ab der neuen Version 2.23 an, dass man git restore verwenden soll und kann. In diesem Fall lässt sich mit dem Befehl die Datei aus dem Staging-Bereich wieder herausnehmen. Restore lässt sich natürlich auch dafür verwenden eine Datei aus einem anderen Commit zu holen. Als zusätzlicher Parameter wird --source benötigt:

$ git restore --source feature/1337 index.html

Dies holt die Datei in das Arbeitsverzeichnis rein. Mit dem zusätzlichen Parameter --staged wird die Änderung hingegen direkt in den Staging-Bereich geschoben.

Sowohl git restore als auch git switch besitzen ein paar mehr Parameter. Meiner Meinung nach sind beide sinnvolle Ergänzungen und machen die Nutzung von Git deutlich angenehmer. Schwierig ist für den geübten Git-Nutzer nur sich die neuen Befehle einzuprägen. Bei mir sind die bisherigen Befehle schon länger in Fleisch und Blut übergangen, sodass ich jetzt erstmal umlernen muss.

Mozilla hat Firefox 69 veröffentlicht. Dieser Artikel fasst die wichtigsten Neuerungen zusammen – wie immer auf diesem Blog weit ausführlicher als auf anderen Websites.

Download Mozilla Firefox für Microsoft Windows, Apple macOS und Linux

Mehr Sicherheit für Firefox-Nutzer

Geschlossene Sicherheitslücken

Auch in Firefox 69 hat Mozilla wieder zahlreiche Sicherheitslücken geschlossen, worunter auch einige sind, welche von Mozilla als besonders schwerwiegend eingestuft werden. Alleine aus Gründen der Sicherheit ist ein Update auf Firefox 69 daher für alle Nutzer dringend empfohlen.

Adobe Flash Player kann nicht länger dauerhaft aktiviert werden

Der Adobe Flash Player ist das letzte verbliebene NPAPI-Plugin, welches von Firefox noch unterstützt wird, nachdem andere NPAPI-Plugins wie Oracle Java oder Microsoft Silverlight bereits seit Firefox 52 nicht mehr unterstützt werden. NPAPI-Plugins waren für viele Jahre ein wichtiger Teil der Webplattform. In den letzten Jahren hat deren Bedeutung aber immer stärker abgenommen. Praktisch alles, was früher ausschließlich mittels NPAPI-Plugin umsetzbar war, wird heute, dank entsprechender Weiterentwicklung von Webstandards, nativ durch die Browser unterstützt. Heute gelten NPAPI-Plugins vor allem aus einer Sicherheits-Perspektive als problematisch.

Bereits im Juli 2017 hatte Adobe angekündigt, den Adobe Flash Player mit Ende 2020 zu beerdigen. Zeitgleich hatte Mozilla angekündigt, die Unterstützung für den Adobe Flash Player in Firefox Anfang 2020 für Privatanwender sowie Ende 2020 für Enterprise-Nutzer einzustellen.

Entsprechend der Roadmap hat Mozilla die Option aus Firefox 69 entfernt, den Adobe Flash Player dauerhaft aktiviert zu haben. Damit bleiben nur noch die Optionen, auf jeder Website mit Flash-Inhalten nachzufragen, ob der Adobe Flash Player aktiviert werden soll, oder diesen komplett deaktiviert zu lassen.

Windows 10: HmacSecret für Windows Hello

Firefox unterstützt bereits seit Version 66 eine passwortlose Authentifizierung via Windows Hello. Das Mai 2019-Update für Windows 10 vorausgesetzt unterstützt Firefox ab Version 69 auch die HmacSecret-Erweiterung, welche beispielsweise für Azure Active Directory benötigt wird und auch von Microsoft Edge unterstützt wird. Gerade im Unternehmensumfeld kann dies eine wichtige Anforderung sein, darum hat Mozilla diese Neuerung auch in Firefox ESR 68.1 implementiert.

Verbesserungen der Privatsphäre

Tracking-Cookies standardmäßig blockiert

Mit Firefox 67.0.1 hat Mozilla die Standard-Konfiguration für neue Nutzer geändert, um Drittanbieter-Cookies von mehr als 1.000 Tracking-Domains standardmäßig zu blockieren. Mit Firefox 69 hat Mozilla das Blockieren der Tracking-Cookies auch für bestehende Nutzer standardmäßig aktiviert.

Cryptomining-Blocker standardmäßig aktiviert

In Firefox 67 hat Mozilla seinen integrierten Content-Blocker optional um die Möglichkeit erweitert, Cryptomining– sowie Fingerprinting-Scripts zu blockieren. Ab Firefox 68 sind beide neue Schutz-Optionen Teil der strengen Konfiguration und nicht mehr nur über die Option „Benutzerdefiniert“ auswählbar. Der Cryptomining-Schutz ist ab Firefox 69 sogar Teil der Standard-Konfiguration und damit für alle Nutzer aktiv – sofern der Schutz vom Nutzer nicht ausdrücklich abgeschaltet wird.

Architektur-Information aus User-Agent entfernt

Mit dem bevorstehenden Ende des Adobe Flash Players besteht nicht länger eine Notwendigkeit, speziell Nutzer einer 32-Bit-Version von Firefox auf einem 64-Bit-Betriebssystem zu erkennen. Ab sofort unterscheidet Firefox nur noch einfach zwischen 32-Bit und 64-Bit-Version und reduziert damit den digitalen Fingerabdruck.

Geschwindigkeits-Verbesserungen

Retained Display Lists für Firefox-Oberfläche

Das Display List Building bezeichnet den Prozess, in welchem die Elemente wie Ränder, Hintergründe usw. gesammelt werden, welche auf dem Bildschirm angezeigt werden sollen und dann gemäß der CSS Painting-Regeln sortiert werden. Bislang musste die sogenannte Display List jedes Mal neu berechnet werden, wenn eine Änderung der Anzeige erfolgte. Dieser Vorgang kann langsam sein, insbesondere mit den immer komplexer werdenden Webseiten sowie den immer größeren Bildschirmen, welche von den Nutzern eingesetzt werden. Retained Display Lists ermöglichen es, dass nur die Teile neu berechnet werden müssen, die sich auch tatsächlich geändert haben. In einem Test konnte die Häufigkeit langsamer Ausführungen um 30 Prozent reduziert werden.

Mit Firefox 61 hat Mozilla die Retained Display Lists für Web-Content aktiviert, ab Firefox 69 sind diese auch für die Firefox-Oberfläche selbst aktiv.

Sonstige Geschwindigkeits-Verbesserungen

Auf Windows gibt Firefox dem Betriebssystem nun Hinweise, um die Priorität der Content-Prozesse optimal zu setzen, so dass mehr Prozessorzeit für Aufgaben zur Verfügung steht, an denen der Nutzer aktiv arbeitet, und weniger Prozessorzeit für Dinge, die im Hintergrund passieren – natürlich mit Ausnahme von Video- und Audio-Wiedergabe im Hintergrund.

Bessere Akkuleistung für Nutzer von Apple macOS

Auf Geräten mit Apple macOS als Betriebssystem und zwei Grafikkarten (wie einem MacBook Pro) versucht Firefox für WebGL-Content nun verstärkt, zur Energie-effizienteren GPU zu greifen. Umgekehrt versucht Firefox verstärkt, den Wechsel zur leistungsstärkeren Grafikkarte für einzelne Nutzungen von WebGL zu vermeiden. Davon soll vor allem die Akkuleistung profitieren.

Gespannt dürfen Nutzer von Apple macOS aber auf Firefox 70 sein. Mit Firefox 70 erhält Mozillas Browser nämlich signifikante Verbesserugen der Architektur, welche zu einem extrem reduzierten Energie-Verbrauch führen werden.

Verbesserter Autoplay-Blocker

Das Feature, um die automatische Wiedergabe von Medien zu blockieren, wurde dahingehend erweitert, dass nicht länger nur Medien blockiert werden können, welche Töne von sich geben, sondern optional auch sämtliche Videos, einschließlich derer ohne Audio-Spur.

Anpassung von Apple MacBook Pro Touch Bar

Mit der Touch Bar besitzt das MacBook Pro von Apple eine berührungsempfindliche Leiste, über welche ein Schnellzugriff auf anwendungsspezifische Funktionen möglich ist. Firefox bietet seit Version 66 Unterstützung für die Apple Touch Bar.

Während bisher eine Anpassung via about:config möglich war, sofern man die entsprechenden Schlüsselwörter kannte, ist diese Möglichkeit mit Firefox 69 zugunsten einer visuellen Anpassungsoberfläche weggefallen, welche über die normale Anpassen-Oberfläche von Firefox erreicht werden kann.

Änderung für Nutzer von userContent.css und userChrome.css

Wird im Profilverzeichnis von Firefox ein Unterverzeichnis mit der Bezeichnung „chrome“ und darin eine Datei „userContent.css“ abgelegt, sind darüber alle denkbaren CSS-Anpassungen für jede beliebige Webseite umsetzbar – ganz ohne Erweiterung. Nach dem gleichen Prinzip können über die Datei „userChrome.css“ beliebige Design-Anpassungen an der Firefox-Oberfläche vorgenommen werden.

Um die Startgeschwindigkeit von Firefox weiter zu optimieren, muss ab Firefox 69 ein Schalter in about:config aktiv sein, damit diese beiden Dateien weiterhin eingelesen werden. Denn das Überprüfen auf die Existenz zweier Dateien dauert länger als das Überprüfen einer Firefox-Option und am Ende zahlen ausnahmslos alle Nutzer den Performance-Preis, obwohl von diesem mächtigen Feature kaum ein Nutzer Gebrauch macht.

Nutzer, welche die Datei userContent.css oder userChrome.css bereits in Firefox 68 im Einsatz hatten, müssen überhaupt nichts tun. In Firefox 68 wurde die Einstellung automatisch für alle Nutzer mit einer dieser beiden Dateien gesetzt. Nur Nutzer von Firefox 69 und neuer, welche diese Form der Anpassung bislang nicht nutzen, müssen über about:config den Schalter toolkit.legacyUserProfileCustomizations.stylesheets auf true setzen, damit die Anpassungen weiterhin funktionieren.

Verbesserungen für Firefox-Erweiterungen (WebExtensions)

Natürlich gab es auch in Firefox 69 wieder einige Neuerungen für Entwickler von Firefox-Erweiterungen, unter anderem Verbesserungen der topSites-API.

Eine Übersicht über diese und weitere Neuerungen für Erweiterungs-Entwickler gibt es hier.

Verbesserungen der Webplattform

Auch für Webentwickler hält Firefox 69 viele spannende Neuerungen parat. Die neue Resize Observer API erlaubt es beispielsweise, auf Größenänderungen von Elementen zu reagieren.

JavaScript-Klassen unterstützen nun öffentliche Instanz-Felder. Was CSS betrifft, so unterstützt die @supports-Regel jetzt auch Selektoren, außerdem werden neue Eigenschaften wie overflow-block, overflow-inline, user-select, line-break und contain unterstützt.

navigator.mediaDevices ist nur noch in einem sicheren Kontext verfügbar. Vereinfacht gesagt bedeutet dies: nur noch über HTTPS, nicht länger über HTTP.

Durch die Unterstützung für den Empfang mehrerer Video-Codecs werden WebRTC-Konferenzen erleichtert, bei denen die Nutzer unterschiedliche Clients nutzen.

Dies war nur eine kleine Auswahl an Änderungen der Webplattform. Weitere Informationen zu Verbesserungen der Webplattform in Firefox 68 finden sich in den MDN web docs.

Neuerungen bei den Entwickler-Werkzeugen

Neues about:debugging mit Remote-Debugging

Die Seite about:debugging wurde komplett erneuert und beinhaltet nun auch die Fähigkeit für sogenanntes Remote Debugging via USB oder Netzwerk, um beispielsweise Websites in Firefox oder Firefox Preview für Android über den Desktop-Computer untersuchen zu können.

Dies war zuvor bereits über das Werkzeug WebIDE möglich, welche mit einem der nächsten Updates entfernt werden wird, nachdem about:debugging diese Funktion nun hat.

Debugger: Event-Breakpoints und weitere Verbesserungen

Der Debugger wurde um die Möglichkeit erweitert, Event-Breakpoints zu setzen. Damit lässt sich die Script-Ausführung pausieren, sobald ein bestimmtes Ereignis ausgelöst wird.

Scripts können über das Kontextmenü der Quellen-Ansicht im Debugger jetzt auch heruntergeladen werden. Erweiterungen werden hier nun mit ihrem Namen statt der UUID angezeigt. Und der Debugger lädt nun wesentlich schneller.

Weitere Verbesserungen der Entwicklerwerkzeuge

Die Netzwerkanalyse kennzeichnet jetzt wegen Mixed Content oder durch CSP blockierte Ressourcen. Außerdem gibt es hier optional ab sofort auch eine Spalte für die vollständige Adresse einer Ressource.

Nachdem Firefox über das Werkzeug für Barrierefreiheit bereits die Möglichkeit besitzt, das Kontrastverhältnis aller Elemente einer Seite zu prüfen, gibt es hier nun eine weitere Prüfung, um die Textbeschriftungen zu überprüfen.

Die Webkonsole gruppiert ähnliche Meldungen ab sofort und wird dadurch übersichtlicher. Die Browserkonsole erlaubt jetzt auch das Ausblenden aller Content-Meldungen.

Außerdem wurde die Standard-Reihenfolge der Werkzeuge geändert, um der realen Nutzung gerechter zu werden. Natürlich kann weiterhin jeder die Reihenfolge selbst beliebig durch Verschieben der Reiter verändern.

Weitere Informationen zu Verbesserungen für Webentwickler in Firefox 69 finden sich in den MDN web docs.

Enterprise Features

PKG installer für Apple macOS

Ähnlich zu MSI-Installern für Windows stellt Mozilla ab sofort auch PKG-Installer für Apple macOS zur Verfügung, um die Verteilung von Firefox im Unternehmen zu erleichtern.

Optionale Features

Passwort-Generator

Wird über about:config der Schalter signon.generation.available auf true gesetzt, steht in den Firefox-Einstellungen eine neue Checkbox zur Verfügung, um einen simplen Passwort-Generator zu aktivieren.

Wird dieses Feature aktiviert, dann schlägt Firefox auf Webseiten, welche das Attribut autocomplete=“new-password“ für ein Passwort-Feld gesetzt haben, automatisch ein Passwort vor. Für alle anderen Passwort-Felder kann ein Passwort via Kontextmenü generiert werden.

Passwörter von anderen Subdomains

Wird signon.includeOtherSubdomainsInLookup auf true gesetzt, schlägt der Passwort-Manager von Firefox auch Passwörter anderer Subdomains der gleichen Domain vor. Wird außerdem noch signon.showAutoCompleteOrigins auf true gesetzt, zeigt Firefox bei vorgeschlagenen Passwörtern die jeweilige Domain unterhalb der jeweiligen Zeile an.

Sonstige Neuerungen in Firefox 69

Für Nutzer der US-Version von Firefox hat Mozilla die Standard-Startseite von Firefox überarbeitet, um die Inhalte von Mozillas Pocket-Dienst mehr in den Vordergrund zu stellen.

Lädt der Nutzer eine Datei herunter, zeigt Firefox auf Apple macOS im Finder jetzt auch bei der Datei, welche gerade heruntergeladen wird, den entsprechenden Download-Fortschritt an.

Seit Firefox 68 wird für neue Nutzer von Windows 10 bei Installation von Firefox eine Verknüpfung in der Taskleiste angelegt. Mit Firefox 69 geschieht dies auch für bestehende Nutzer.

Die JavaScript-Engine wurde für bessere Performance um JIT-Unterstützung für ARM64-Geräte erweitert.

Auf about:performance kann nun nach beliebigen Spalten sortiert werden. Die Seite about:support zeigt jetzt auch den Installationspfad von Firefox an.

Außerdem hat Mozilla einen Fehler in Zusammenhang mit Scroll Anchoring behoben, welcher dafür sorgte, dass auf manchen Webseiten die Scroll-Position etwas verschoben war, wenn die Seite neu geladen worden ist.

Der Beitrag Mozilla veröffentlicht Firefox 69 erschien zuerst auf soeren-hentzschel.at.