WAGO USB Service Cable unter Linux in einer Virtualbox benutzen

Um mit SPS-Komponenten zu kommunizieren gibt es verschiedene Wege und fast alle führen zum Ziel. Bei bestimmten Einstellungsarbeiten oder Firmware-Updates ist es aber sinnvoll, die meistens vorhandene Service-Schnittstelle der Controller zu nutzen.

Jeder Hersteller bietet Service-Kabel an, die zu den eigenen Schnittstellen passen, die Kabel sind natürlich immer unterschiedlich.
Auch WAGO bietet ein „WAGO USB Service Cable“ an. Für Windows gibt es einen speziellen Treiber für dieses Kabel, für Linux nicht. Ich bin mir ziemlich sicher, dass dieser Artikel auch auf Siemens S7 und LOGO, sowie auf die meisten anderen SPS-Hersteller anwendbar ist, davon habe ich allerdings keine Altgeräte zum Basteln da.

Ich bin mir sicher, außer mir gibt es noch viele andere SPS-Menschen, die Zuhause Linux nutzen und zum Herumprobieren eine Virtuelle Maschine mit Windows laufen haben, in der die Entwicklungsumgebung läuft. Das Kommunikationskabel läuft allerdings in z.B. Virtualbox nicht ohne nachzuhelfen, wobei es sich wirklich um eine Kleinigkeit handelt.
Denn: Auch wenn jeder Hersteller ziemlich teure Kommunikationskabel in verschiedenen Ausführungen anbietet, eines haben sie gemeinsam: Es sind ziemlich stinknormale USB (oder RS232) auf TTL Konverter, die unter Debian als ttyUSB erkannt werden. Es muss lediglich der Virtualbox-Benutzer in die Gruppe dialout aufgenommen werden, damit er es benutzen darf:

usermod -aG dialout BENUTZERNAME

In der Virtualbox erscheint es bei installiertem Windows-Treiber dann ganz normal in der USB-Geräte-Auswahl:

WAGO USB Service Cable in den USB-Geräten von Virtualbox
WAGO USB Service Cable in den USB-Geräten von Virtualbox

Aktiviert man es dort, kann man es beispielsweise in den WAGO Ethernet Settings als Kommunikationsschnittstelle nutzen:

Virtualbox: WAGO USB Service Cable in den Ethernet Settings
Virtualbox: WAGO USB Service Cable in den Ethernet Settings

Temperatursensor DS18B20 unter Linux per Pythonscript abfragen

Vor ein paar Tagen habe ich eine kurze Übersicht über die Benutzung der OneWire-Schnittstelle in CODESYS 3.5 auf dem Raspberry Pi veröffentlicht. Inzwischen habe ich per Mail von mehreren Lesern die Frage nach einer funktionierenden Lösung mit Python bekommen, daher möchte ich das noch schnell hinterher schieben.

Aufbau

Um das ganze noch ein kleines Bisschen spannender zu machen, sind dieses Mal drei Sensoren gleichzeitig angeschlossen. Auf dem Breadboard sieht das so aus:

Drei Temperatursensoren DS18B20 parallel an einer "Sensorleitung"
Drei Temperatursensoren DS18B20 parallel an einer „Sensorleitung“

Schnell in gEDA abgezeichnet sieht es so aus:

Drei DS18B20 parallel als Schaltbild
Drei DS18B20 parallel als Schaltbild

Man sieht also, die Sensoren können parallel geschaltet werden, der Widerstand wird nur ein Mal benötigt.

Wenn, wie im oben bereits verlinkten Artikel die Kernelmodule über den Device Tree geladen sind (/boot/config.txt), sollten die drei Sensoren danach im Verzeichnis /sys/bus/w1/devices/ sichtbar sein, hier gibt es wieder für jeden Sensor einen Ordner, der mit seiner eindeutigen ID benannt ist:

Die Ordner der drei Sensoren, benannt nach der jeweiligen ID
Die Ordner der drei Sensoren, benannt nach der jeweiligen ID

Wie schon im ersten Artikel können auch hier die Werte mit der Datei w1_slave ausgegeben werden:

root@raspberrypi:/sys/bus/w1/devices/28-0216009b68ff# cat w1_slave 
2f 01 4b 46 7f ff 0c 10 a7 : crc=a7 YES
2f 01 4b 46 7f ff 0c 10 a7 t=18937

So weit waren wir beim letzten Mal auch schon, jetzt gehts ans Python-Script.

Programm erstellen

Zuerst müssen wir die bis dahin ja noch nicht existente Datei mit dem Editor unserer Wahl öffnen. Ich mag nano, öffne die Datei also mit

nano temp.py

Um das Programm später mit dem richtigen Interpreter direkt ausführen zu können, müssen wir jetzt im Shebang python als ebendiesen nennen, danach legen wir fest, welche Bibliotheken geladen werden sollen:

#!/usr/bin/env python
import os, time, sys

Um Fehlern aus dem Wege zu gehen, laden wir nun noch die Kernelmodule, die wir nutzen möchten:

os.system('modprobe w1-gpio')
os.system('modprobe w1-therm')

Am Anfang des Programmes legen wir nun noch ein paar Werte als Variablen fest, die wir später benutzen können. Ich habe als sensorcount die Anzahl des Sensoren angegeben, unter sensors die Kennung der drei Sensoren als Array, unter sensorpath den Pfad zu den Geräteverzeichnissen als String und unter sensorfile den Namen der Datei ebenfalls als String:

sensorcount = 3
sensors = ['28-0216009b68ff', '28-021600b769ff', '28-021600bb4dff'];

sensorpath = '/sys/bus/w1/devices/'
sensorfile = '/w1_slave'

Nun erstellen wir die Funktion, die die Sensordaten abfragt und verarbeitet:

def callsensor(sensor):
  f = open(sensorpath + sensor + sensorfile, 'r')
  lines = f.readlines()
  f.close()
  if lines[0].strip() [-3:] != 'YES':
    sys.exit('Fehler bei Sensor ' + sensor)
  temp_line = lines[1].find('t=')
  if temp_line != -1:
    temp_output = lines[1].strip() [temp_line+2:]
    temp_celsius = float(temp_output) / 1000
    return temp_celsius

Die Funktion öffnet die Gerätedatei im Lesemodus, schreibt den Inhalt auf lines und schließt sie dann wieder. Die Variable sensor wird dabei später als Parameter beim Funktionsaufruf mitgegeben.
Zeile 1 wird nun auf die letzten drei Zeichen gekürzt und geprüft, ob diese „YES“ sind, also ob die Prüfsumme des Sensors okay ist. Wenn nicht, wird das Programm mit einer Fehlermeldung abgebrochen.
Nun wird der Index (also die Position) des Strings t= in der zweiten Zeile ermittelt. Ist diese nicht -1 (das gibt find zurück, wenn nichts gefunden wurde), wird Zeile 2 auf die Zeichen nach t= gekürzt (das ist der fünfstellige Temperaturwert des Sensors), der Wert wird durch 1000 geteilt und wir erhalten so den Wert in °C. Die Funktion wird dann beendet und der Temperaturwert zurückgegeben.

Nun fehlt nur noch der Teil, der die Funktion beim Aufruf des Programms ausführt und die Werte an stdout (also momentan die Konsole) zurückgibt:

for i in range(0, sensorcount):
  s = sensors[i]
  print('Sensor ' + str(i) + ': ' + str(callsensor(s)))
sys.exit()

Hier haben wir eine for-Schleife, die die Funktion callsensor für jeden Sensor einmal aufruft und die Sensor-ID aus dem Array als Parameter an callsensor übergibt. Das Ergebnis wird ausgegeben und das Programm wird beendet.

Das Programm müssen wir nun nur noch speichern. Um es ausführen zu können, müssen wir es noch ausführbar machen:

chmod +x temp.py

Wenn wir es nun in der Konsole ausführen, bekommen wir drei Ausgaben für unsere Sensoren:

root@raspberrypi:~/tutorials/temperatur# ./temp.py
Sensor 0: 18.437
Sensor 1: 19.937
Sensor 2: 20.062

Zum Schluss hänge ich die Programmdatei (übrigens kommentiert) hier an: Python-Programm temp.py

ISPConfig: Zertifikate von Let’s Encrypt automatisch erstellen

Let’s Encrypt ist eine neue CA (Zertifizierungsstelle), die seit kurzem im Produktivbetrieb kostenlose TLS-Zertifikate vergibt.

Das ganze läuft automatisiert, die CA stellt dafür ein Script zur Verfügung, welches sämtliche Kommunikation mit den Servern von Let’s Encrypt regelt. Das Anfordern und erneuern von Zertifikaten ist also sehr einfach und mit einem Befehl über die Kommandozeile zu erledigen.

Für Hosting-Anbieter (oder Selbsthoster) ist Let’s Encrypt natürlich eine tolle Möglichkeit, die Webseiten schnell und kostenlos mit einem validen Zertifikat zu versehen. Für Anbieter mit dem Control Panel ISPConfig gibt es inzwischen eine externe Lösung, um die Zertifikatanforderung nahtlos in die Weboberfläche zu integrieren. Die externe Erweiterung soll eventuell in den nächsten Versionen von ISPConfig fester Teil der Software werden, bisher ist das aber noch nicht der Fall, das Panel muss also gepatcht werden.

Die Erweiterung von alexalouit ist auf github zu finden und kann unter Debian leicht installiert werden. Vorher muss allerdings das Script von Let’s Encrypt installiert werden, ebenfalls von github:

cd /tmp
git clone https://github.com/letsencrypt/letsencrypt
cd letsencrypt
./letsencrypt-auto

Der Installer kann abgebrochen werden, bevor er beim Anfordern von Zertifikaten hilft, das wollen wir schließlich über ISPConfig erledigen.

Nun wird „ISPConfig-letsencrypt“ geklont:

cd /tmp
git clone https://github.com/alexalouit/ISPConfig-letsencrypt.git
cd ISPConfig-letsencrypt

Auch hier gibt es einen automatischen Installer, der die Erweiterung installiert und ISPConfig patcht (Dateien verschieben, Datenbank aktualisieren und Konfiguration anpassen):

root@helium:/tmp/ISPConfig-letsencrypt# php -q install.php
Create backup on /var/backup/ directory
/bin/tar: Entferne führende „/“ von Elementnamen
Backup finished
Copy Let's Encrypt configuration.
Start MySQL update..
Configure Apache and reload it.
Create backup cronjob on /var/backup/ directory
Add a cronjob for renewal certs
And finally, update ISPConfig.
Done my job. Enjoy!

Ist dies erledigt, erscheint in ISPConfig in den Einstellungen einer Website neben dem bisher vorhandenen Kontrollkästchen „SSL“ auch das Kontrollkästchen „Let’s Encrypt“:

ISPConfig: Website-Einstellungen mit Kontrollkästchen für Let's Encrypt
ISPConfig: Website-Einstellungen mit Kontrollkästchen für Let’s Encrypt

Setzt man diesen Haken (der Haken bei SSL setzt sich dann automatisch), wird bei der Aktion „Zertifikat Erstellen“ im Tab „SSL“ nicht mehr ein selbstsigniertes Zertifikat auf dem Server generiert, sondern es wird eines bei Let’s Encrypt angefordert. wird automatisch ein Zertifikat von Let’s Encrypt angefordert und die Seite damit ausgestattet. Im SSL-Tab muss und darf nichts weiter getan werden.

Mehr ist gar nicht notwendig, nach kurzer Zeit ist das Zertifikat im Ordner von Let’s Encrypt hinterlegt und wird in den SSL-Ordner der Seite gelinkt. Auch die Änderungen in den vhosts werden automatisch vorgenommen. Die Seite ist nun über https abrufbar und das Zertifikat wird von den meisten vernünftigen Browsern als vertrauenswürdig angezeigt:

Website mit dem über ISPConfig abgerufenen Let's Encrypt Zertifikat
Website mit dem über ISPConfig abgerufenen Let’s Encrypt Zertifikat

Festplattentyp von dynamisch auf fixe Größe ändern in VirtualBox unter Debian

Das besonders unter Linuxnutzern beliebte Virtualisierungsprogramm VirtualBox bringt zwei „eigene“ virtuelle Festplattentypen mit, die beide unter „Virtual Disk Image“ (VDI) zusammengefasst werden: Die Festplattendatei mit fixer Größe und die Datei mit dynamischer Größe.

Der Hintergrund: Weist man dem Gastsystem eine 50GB-Festplatte zu und wählt die fixe Größe, wird eine 50GB große Datei auf dem Wirtsystem erstellt. Wählt man für die 50GB-Festplatte die dynamische Größe, wird eine sehr kleine Datei erstellt, die dann erst mit der Benutzung wächst (die Sektoren werden erst erstellt, wenn sie auch zum ersten Mal beschrieben werden).

Hat man sich für die dynamische Größe entschieden, wird man eventuell irgendwann feststellen, dass das virtuelle System oft langsam läuft. Schreibvorgänge auf die Festplatte sind in diesem Fall eben keine normalen Schreibvorgänge, es wird mehr Rechenleistung benötigt, um die Festplattensektoren zu erstellen.

Es ist aber möglich, eine Festplatte mit dynamischer Größe in eine ebensolche mit fixer Größe zu wandeln, VirtualBox bringt dazu auch alle Werkzeuge gleich mit. Das Umwandeln geht recht einfach über die Konsole.

Zuerst sollte man die bisher genutzte Festplatte sichern. Welche Festplattendatei für die entsprechende virtuelle Maschine genutzt wird und wo im Dateisystem diese angelegt wurde, lässt sich leicht in der Oberfläche leicht nachvollziehen. Hier wird auch der Typ angezeigt. Diese Datei wird nun unter einem eindeutigen Namen kopiert und kann später gelöscht werden, wenn alles funktioniert.

Nun wird die bisherige Festplatte geklont, hierfür wird das Programm vboxmanage genutzt:

VirtualBox: Festplatte klonen mit clonehd
VirtualBox: Festplatte klonen mit clonehd

Die Anwendung ist einfach:

vboxmanage clonehd /Pfad/zur/Quelldatei.vdi /Pfad/zur/Zieldatei.vdi --variant fixed

Dies klont die vorhandene Festplatte in eine neue Datei mit fixer Größe.

Nun muss die vorhandene Festplatte im VirtualBox Manager (also der GUI) aus dem Controller entfernt werden. Dafür wird einfach die betroffene VM ausgewählt und im „Ändern“-Menü unter „Massenspeicher“ die bisherige Festplatte entfernt.

In der Konsole wird nun mit

vboxmanage list hdds

eine Liste aller registrierten VirtualBox-Festplatten ausgegeben. Die UUID der bisher verwendeten Platte wird kopiert.

VirtualBox: Festplatte schließen und löschen mit closemedium
VirtualBox: Festplatte schließen und löschen mit closemedium

Nun wird ebenfalls in der Konsole die bisherige Festplatte geschlossen und gelöscht. Dies geschieht mittels

vboxmanage closemedium disk UUID –delete

Sollte dabei die Fehlermeldung auftauchen, dass die Festplatte noch zu einer virtuellen Maschine gehört (Medium cannot be closed because it is still attached to 1 virtual machines), wurde sie vorher entweder nicht aus dem Controller gelöscht, oder das Fenster wurde danach nicht geschlossen. Ansonsten sollte die Festplatte damit gelöscht sein.

Anschließend muss die geklonte Festplatte den Dateinamen der nun gelöschten Festplatte bekommen, danach kann sie wieder im Manager dem Controller hinzugefügt werden.

VirtualBox: Neue Festplatte dem Controller hinzufügen
VirtualBox: Neue Festplatte dem Controller hinzufügen

Ist das alles erledigt, sollte die Virtuelle Maschine wieder starten wie zuvor, jedoch von der neuen Festplatte. Fast einfacher als ein echter Hardware-Tausch.

Übrigens: Unter Windows funktioniert das ganze quasi genau so. Dort gibt es eine VBoxManage.exe, die ebenfalls mit den genannten Parametern ausgeführt werden kann.

Weitere Artikel zum Thema:

Kodi-Menüs unter Debian anpassen

Kodi ist der neue Name des altbekannten und beliebten Xbox Media Player und später Xbox Media Center (XBMC). Da der Name nicht mehr Programm ist und die Mediacenter-Software vermutlich auf mehr Raspberrys läuft, als auf Xboxen (und wegen rechtlicher Bedenken) wurde es umbenannt und schaut man die vor- und nachweihnachtliche Berichterstattung großer Techblogs an ist Kodi wohl inzwischen populärer als die nativen Betriebssysteme der Smart-TVs.

Auch wir haben einen Raspberry Pi an unserem Fernseher, auch auf diesem ist neben Debian das Kodi Mediacenter installiert.
Aus einem gewissen Grund (nach dem „Verlassen“ von Kodi landet man nicht wieder im Desktop, sondern im nirgendwo, der XServer ist aus) wollte ich ein bestimmtes Menü von Kodi ändern, fand aber nicht so recht weiterhelfende Dokumentation. Da ich mir dann alles zusammensuchte, hier meine „Lösung“:

Die Menüs werden in XML-Dateien „formatiert“, die unter Debian mit dem Kodi-Skin Confluence in /usr/share/kodi/addons/skin.confluence/720p/ liegen. Das „Verlassen-Menü“ wird in der Datei „DialogButtonMenu.xml“ definiert, hier habe ich einfach die Buttons 2-7 auskommentiert, im Ergebnis sieht das dann so aus:

Kodi: Ausschalten Menü verändert
Kodi: Ausschalten Menü verändert

 

Autokorrektur für die Konsole: The Fuck

Klangvoller Name, praktische Erweiterung für die Konsole: thefuck schlägt Korrekturen für falsch eingegebene Befehle auf der Konsole vor und führt diese auf Wunsch auch gleich aus:

Autokorrektur für die Konsole: The Fuck
Autokorrektur für die Konsole: The Fuck

Es ist natürlich auch möglich, einen anderen Alias als „fuck“ für die gewünschte Korrektur zu nutzen, dieser wird in der .bashrc oder der jeweiligen Config-Datei der Shell hinterlegt.

Raspberry Pi als „Cloud“ oder NAS?

Es geisterte ja heute durch das gesamte Internet und somit auch an mir vorbei: Western Digital plant, eine Vielzahl von Netzwerkspeichern auf Basis einer speziellen WD-Festplatte und einem Raspberry Pi auf den Markt zu schmeißen unter dem klangvollen Namen PiDrive. Das ganze ist derzeit in der Entwicklungsphase bei WDLabs (der aktuelle Stand lässt sich wohl aber in Amerika bereits kaufen) und soll mit OwnCloud ausgeliefert werden.

Ich bin ja ein großer Fan des Raspberry Pi und habe privat einen Raspberry Pi B, B+ und seit neuestem auch einen Raspberry Pi 2 B als Mediacenter. Die Dinger machen sich echt gut, sei es als 24/7 Monitor-Device, als Bastelgerät für SPS-Spielereien oder Modbus-Erweiterung derselben für Aufgaben, die ein Linuxrechner einfach besser hin bekommt.

Allerdings fingen schon beim Lesen der Überschriften bei mir die Warnlichter an zu leuchten: Der Netzwerkadapter (10/100 MBit/s) wird vom USB 2.0-Controller bereitgestellt. USB 2.0 hat eine theoretische Bandbreite von bis zu 480MBit/s, davon bleiben vielleicht so 400MBit/s tatsächlich übrig. Insgesamt können also über LAN und USB etwa 50MByte/s übertragen werden.
Der Ethernet-Port hat eine Übertragungsrate von 100MBit/s, was etwa 12MByte/s entspricht.

Das reicht natürlich. Für die Sachen, die man mit nem Raspberry Pi so macht: Webcamstream, Bastelcomputer, Mediacenter usw.
Wenn es aber darum geht, Daten im lokalen Netzwerk vorzuhalten, sind 100MBit/s nicht besonders schön. Erst recht nicht, wenn man beispielsweise das Netzlaufwerk auf einem anderen Rechner einbinden will. Da sind die Kapazitätsgrenzen schnell erreicht, vor allem, wenn eventuell zwei Rechner gleichzeitig Daten haben wollen. Wenn man Sachen aus dem Netz läd, ist sowas zu verschmerzen (da wären 100MBit/s ja fast das obere Ende), aber das will man ja eigentlich nicht auf Geräten haben, die im internen Gigabit-LAN Daten vorhalten sollen.

Klar, das Ding kostet auch nicht viel, da kann man nicht viel verlangen. Ich würde aber sagen, dass es einfach das falsche Gerät ist, um ein NAS oder eine Cloud wie OwnCloud bereitzustellen, auf der mehr als nur ein paar MP3 und Urlaubsfotos gespeichert werden (von der Datensicherheit mal abgesehen). Es gibt inzwischen viele andere Anbieter günstiger Mini-Computer, die dann auf andere Bereiche spezialisiert sind.

via: t3n, Heise

Bild: Owncloud

Geschwindigkeitstest IOCrest PCIe SATA III Controller

Ich habe seit neuestem sechs Festplatten und ein CD/DVD-Laufwerk in meinem Desktop-Computer. Mein Mainboard (ASRock H67M-GE/HT) hat allerdings nur 3 SATA II Slots und 2 SATA III Slots. Meine beiden SSDs möchte ich natürlich via SATA III betreiben, bleibt also nur noch Platz für zwei Festplatten und das CD/DVD-Laufwerk.

Aus diesem Grunde musste ein weiterer SATA-Controller her, in diesem Fall ist nun eine PCIe-Karte (X1) von IOCrest (Modell SI-PEX40064) verbaut, die laut Beschreibung SATA III mit 6Gb/S bereitstellt.

Der Controller funktioniert wunderbar und auch unter Linux out of the box (die Unterstützung für Linux steht sogar auf dem Karton).
Falls mal jemand nach einem günstigen SATA-Controller sucht, kann ich diesen also durchaus empfehlen.

Nun mal zu den Daten:

Gemessen habe ich zwei Crucial M4 SSDs. Zuerst am SATA III Port meines Mainboards:

florian@wd:~$ sudo hdparm -tT --direct /dev/sdd
/dev/sdd:
Timing O_DIRECT cached reads: 618 MB in 2.01 seconds = 308.18 MB/sec
Timing O_DIRECT disk reads: 1152 MB in 3.01 seconds = 383.31 MB/sec

florian@wd:~$ sudo hdparm -tT --direct /dev/sdc
/dev/sdc:
Timing O_DIRECT cached reads: 614 MB in 2.00 seconds = 306.79 MB/sec
Timing O_DIRECT disk reads: 1158 MB in 3.00 seconds = 385.42 MB/sec

Und am Controller:

florian@wd:~$ sudo hdparm -tT --direct /dev/sda
/dev/sda:
Timing O_DIRECT cached reads: 718 MB in 2.00 seconds = 358.90 MB/sec
Timing O_DIRECT disk reads: 1082 MB in 3.00 seconds = 360.60 MB/sec

florian@wd:~$ sudo hdparm -tT --direct /dev/sdb
/dev/sdb:
Timing O_DIRECT cached reads: 718 MB in 2.00 seconds = 358.74 MB/sec
Timing O_DIRECT disk reads: 1076 MB in 3.00 seconds = 358.59 MB/sec

Falls es wen interessiert hier noch die Werte eines Software-RAID 1 mit zwei WD Blue ATA WDC WD10EZEX-00U an besagtem Controller:

florian@wd:~$ sudo hdparm -tT --direct /dev/md1
/dev/md1:
 Timing O_DIRECT cached reads:   652 MB in  2.00 seconds = 325.69 MB/sec
 Timing O_DIRECT disk reads: 426 MB in  3.02 seconds = 141.25 MB/sec

Distributionsunabhängige Hardware mit Windows-Exklusiven Updates

Update: Der ASRock-Support hat sich zu dem Thema geäußert. Siehe unten.

Um in meinen PC einen Prozessor einer neueren Generation (Ivy Bridge) einbauen zu können, brauchte das etwas angestaubte BIOS ein Update.

Es ist jetzt auch nicht das erste Mal, dass ich so etwas mache, normalerweise gibt es ein ROM zum Download beim Hersteller des Mainboards, manchmal auch deutlich komfortablere Lösungen, die direkt im BIOS vom USB-Stick geflasht werden können. Alles kein Problem.

Anders bei meinem Mainboard. ASRock (H67M-GE/HT) stellt nämlich ausschließlich ein Update-Tool für Windows bereit, die ausführbare Datei ist dabei gleichzeitig Tool und ROM und muss aus einem nativ laufenden Windows ausgeführt werden. Einen Teil der Daten tauscht die Software bei laufendem System aus, bootet dann ins BIOS und flasht den Chip dann vollständig. Eigentlich auch sehr komfortabel. Aber eben nur für Windows. Der Hersteller bietet keinerlei Möglichkeit an, das BIOS über einen DOS-Stick oder über das automatische Update, das auch in diesem BIOS schon vorhanden ist zu flashen.

Da steht man also mit einem Rechner, auf dem nur verschiedene Linuxe laufen und versucht ein völlig distributionsunabhängiges Stück Hardware zu aktualisieren, für das es der Hersteller offensichtlich nicht für nötig erachtet, einen einigermaßen distributionsunabhängigen Update-Weg zur Verfügung zu stellen.

Ich habe letztendlich auf einer bis dato leeren Partition Windows 8 als Evaluationsversion installiert, das BIOS geflasht und die Partition wieder geplättet. Wohl dem, der einen USB-Stick mit einer guten Geschwindigkeit an seinen PC stecken kann.

Update:

Der Support hat sich gemeldet und erklärt, wieso es nur das Windows-Tool gibt, nicht aber die Dateien zum Flashen oder InstantFlash-Datei. Es gab 2011 eine Rückrufaktion von Intel, der Verbaute Chipsatz hatte wohl Probleme mit dem SATA-Controller und es wurden keine Ivy-CPUs unterstützt.
Damit sichergestellt ist, dass das Update des BIOS nicht zu diesen Problemen führt, wurde nur dieses Tool veröffentlicht, das erst prüft, ob ein Update möglich ist und dieses erst dann ausführt. Und das Tool gibt es eben in diesem Fall nur für Windows.

Der Support prüft aber offensichtlich bereitwillig, ob das jeweilige Board davon betroffen ist und sendet die InstantFlash-Datei zu, wenn alles okay ist.

Kurz notiert: Dateimanager Sunflower

Mein relativ altes Laptop (Lenovo 3000 N200) wollte gerne wiederbelebt werden und bekam von mir heute ein frisches Fedora. In diesem Zuge probierte ich den Windowmanager i3 aus und suchte dafür nach einem guten Dateimanager.

Bisher hatte ich mit diesem Thema keine großen Berührungspunkte, die meisten Desktops bringen einen Standard-Dateimanager mit, momentan nutze ich Mate mit Caja auf meinem Desktop-PC.

Nach kurzem stöbern, was denn der „beste“ Dateimanager sei, stieß ich auf „Sunflower„, einen zweispaltigen Dateimanager in Python und GTK, der sich auch in i3 super einfügt.

Es werden neben den Quellen auch fertige Downloads für verschiedene Distributionen angeboten.

Falls also gerade jemand auf der Suche nach einem neuen Dateimanager ist, der viele nette Funktionen mitbringt und neben der Vollständigkeit auch offensichtlich stabil läuft: Einfach mal ausprobieren.