UNIXwork

Eine tar-Datei besteht immer aus 512 Bytes großen Blöcken. Jede Datei im Archiv hat einen Header-Block gefolgt von weiteren Blöcken für den Dateiinhalt. Verzeichnisse oder Links haben logischerweise keine Content-Blöcke sondern nur den Header-Block. Am Ende des Archivs werden dann zwei 512 Bytes Blöcke mit Null-Bytes angehängt, die das Ende markieren.

Der Header besteht fast nur aus Plain-Text, nur ein paar Null-Bytes kommen vor. Integer-Werte werden als Oktal-Strings gespeichert. Auch sind alle Felder des Headers an fixen Adressen, was das parsen vereinfacht. Eine Beschreibung des Headers findet sich auf der Open Group Webseite.

Da der Header nur begrenzt viel Platz hat, hat das Original UStar-Format (Unix Standard TAR) ein paar Limitierungen. Z.B. können Dateinamen oder Pfade nicht beliebig lang sein. Auch die Größe einzelner Dateien ist durch die spezielle Kodierung auf 8 Gb begrenzt. Erweiterungen dieses Formats, wie das neue POSIX Format pax oder auch GNU tar und star, haben diese Begrenzung nicht.

Wer tar-Dateien im alten UStar-Format in seinem eigenen Programm erstellen will, für den habe ich dieses Beispielprogramm, welches als Argument ein oder mehrere Dateipfade erwartet und dann eine tar-Datei daraus erstellt, die auf stdout ausgegeben wird.

Es ist manchmal ein Trauerspiel mit Linux. Viel zu oft hab ich schon nerviges Tearing erlebt, mit verschiedenen Ursachen. Aktuell mit Intel iGPU und der Gnome Shell. Ich bin mir nicht sicher, ob das Problem auch mit anderen GPUs auftritt. Sicher bin ich mir dabei, dass bei mir die Gnome Shell der Schuldige ist.

Daher hier ein (temporärer) Fix für eins der vielen Tearing-Probleme.

1. Öffnen des Gnome Shell Debugger (Looking Glass): Drücke Alt-F2 und gib lg ein

2. Dort muss folgender Befehl eingegeben werden:

   Meta.disable_unredirect_for_screen(global.screen)

Eine Alternative ist diese Gnome Extension.

Wer unter macOS den Debugger gdb benötigt, muss ein paar Hindernisse überwinden. Zur Zeit meiner ersten Bekanntschaft mit OS X war gdb noch bei Xcode dabei, dieser wurde dort jedoch durch lldb ersetzt.

Installieren kann man gdb am einfachsten mit Homebrew.

$ brew install gdb

Das Sicherheitssystem in macOS erlaubt es gdb jedoch nicht, seine Aufgabe zu erfüllen, daher muss man gdb erst noch signieren und die System Integrity Protection muss deaktiviert werden.

Da ich nicht einfach die Anleitung, die ich selber befolgt habe, klauen möchte, verlinke ich einfach darauf.

Eine neue stabile Version von TrueOS, einem FreeBSD-basierenden Betriebsystem, wurde veröffentlicht.

Ursprünglich war TrueOS ein etwas nutzerfreundliches FreeBSD, mit einem einfacheren Installer, der ein benutzbares Desktop-OS installiert und grafische Tools für die Paketverwaltung bereitstellt. Die Entwickler haben aber daran gearbeitet, sich durch besondere Features von FreeBSD hervorzuheben. So kommt im Unterschied zu FreeBSD das OpenRC Init-System zum Einsatz. TrueOS hat auch seinen eigenen auf Qt basierten Desktop, nämlich Lumina. Zu den weiteren besonderen TrueOS Features zählen ein überarbeitetes Package-Management und die eigene SysAdm Remote Management API.

Zu den Neuerungen von 17.12 zählen:

• Basiert auf FreeBSD 12.0-CURRENT
• Verbesserung der OpenRC-Integration mit über 1100 OpenRC Services für 3rd-party Pakete
• Update des Lumina-Desktops
• Automounter-Service um entfernbare Geräte zu verwalten
• Unterstützung von bhyve, dem BSD Hypervisor
• Separate Installations-Images für Desktop und Server

Offizielle Release-Ankündigung

Ab morgen, dem 14. Dezember, verkauft Apple den iMac Pro. Dieser soll ihre Pro-Kundschaft zufrieden stellen, da Apple sonst keine aktuelle und auch keine brauchbare Hardware im Angebot hat.

Im Vergleich mit dem gewöhnlichen iMac hat die Pro-Variante deutlich mehr Rechenleistung. Statt den Mittelklasse-CPUs wie dem i5 oder i7 verbaut Apple im iMac Pro den neuen Xeon W. Als GPU kommt eine Vega 56 zum Einsatz, die sicherlich auch mehr Leistung bringt.

Generell sehen die Specs beeindruckend aus. Ich hab da aber gewisse Bedenken, und möchte die für die Nachwelt festhalten, bevor es irgendwelche Reviews gibt.

Ich kann mir nicht vorstellen, dass Apple es schafft, diese Hardware vernünftig zu kühlen. Und ich denke das, weil Apple schon eine Weile nur noch Flüssigaluminium-Spender baut. Auch der aktuelle Mac Pro in Eimerform kann seine Abwärme nicht wegtransportieren. Die Folge ist, dass die Leistung gedrosselt werden muss. Eine Workstation drosselt aber nicht! Den Xeon W im iMac Pro gibts mit einer TDP bis 140W. Das Gehäuse ist viel zu kompakt um das zu kühlen. Das gleich gilt für die GPU.

Schon der normale iMac hat ein viel zu schwaches Kühlungssystem. Dieses ältere Video zeigt, wie ein iMac beim Gaming nach paar Minuten die GPU stark drosselt. Oder in diesem Forum wird über Drosselung des 2017er iMac berichtet. Da der neue iMac Pro eine deutlich höhere Leistungsaufnahme hat, kann dies auch nicht mit einem optimierten Kühlungssystem, welches Apple verspricht, gekühlt werden. Zumindestens nicht so, dass der iMac Pro längere Zeit volle Leistung bringen kann. Die einzige Frage ist nur noch, wie viele Minuten man ungedrosselt hat. Ich sage voraus, es werden 2 Minuten sein. Vielleicht auch 3.