UNIXwork

Tags

c unix dav shell linux xattr solaris links x11 java rant webdav fun gnome apple sync wtf oracle ldap network xnedit windows analytics macos benchmark curl apache bsd graalvm mac virtualbox arm zfs rhel microsoft tomcat freebsd hardware sparc

gdb unter macOS installieren und signieren

15. Dezember 2017

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.

TrueOS 17.12 veröffentlicht

14. Dezember 2017

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

iMac Pro - Kernschmelze vorprogrammiert

13. Dezember 2017

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.

dav 1.1.1 veröffentlicht

12. Dezember 2017

Ein kleines dav Update, welches nur einen Bug fixt, der nur unter Windows auftritt. Der Fehler verursachte, dass die Befehle get und list nicht mit der -R Option funktionierten.

Die Änderungen betreffen nur die Windows-Version, durch ein #ifdef sind diese auf anderen Plattformen nicht aktiv. Als Nicht-Windows-User kann man sich das Update also sparen. Ich schätze, ich muss wohl ober übel in Zukunft mehr unter Windows testen.

dav Projektseite SourceForge Projektseite

dav copy und move mit verschlüsselten Dateien

11. Dezember 2017

Die integrierte Verschlüsselung von dav ist für den Benutzer weitestgehend transparent, bis auf in den Befehlen copy und move in der aktuellen Version 1.1. Bisher sind diese Befehle nur low level WebDAV, das heißt, es wird wirlich nur ein WebDAV COPY oder MOVE ausgeführt. Schauen wir uns dav copy und dav move erstmal an:

dav copy [-pcO] [-L <lock>] <url> <url>
dav move [-pcO] [-L <lock>] <url> <url>

Beide Befehle sind von der Benutzung her gleich, nur dass copy eine Kopie erstellt und move eine Ressource verschiebt. Wie man sieht, haben beide Befehle die Flags -p und -c, mit denen Verschlüsselung aktiviert und deaktiviert werden kann. Dies bezieht sich jedoch nur auf die Pfad-Auflösung.

Das Positive ist schon mal, dass mit aktivierter Verschlüsselung die Ziel-URL (das letzte Argument) auch randomisiert wird. Bei verschlüsselten Ressourcen ist der Dateiname, den der Server sieht, nur ein zufälliger String, während der Name, den dav verwendet, verschlüsselt in den Properties gespeichert wird. Das Problem ist, dass copy/move nicht diese Property anpassen, sondern nur die Properties der Source-URL kopieren, wie es von WebDAV COPY/MOVE gefordert ist. Das hat zur Folge, dass der Dateiname, den dav verwendet, bei verschlüsselten Ressourcen sich nicht durch dav copy/move ändert.

$ dav list -l cryptrepo
-c    32 bytes  Dec 11 19:54  test.txt
$ dav move secrepo/test.txt cryptrepo/newname.txt
$ dav list -l cryptrepo
-c    32 bytes  Dec 11 19:54  test.txt

Schlimmer wird es noch mit copy, wenn die Ziel-URL die selbe Collection ist:

$ dav copy cryptrepo/test.txt cryptrepo/copy.txt
$ dav list -l cryptrepo
-c    32 bytes  Dec 11 20:10  test.txt
-c    32 bytes  Dec 11 19:54  test.txt

Wer sich jetzt fragt, wie man die richtige Datei löschen kann: mit deaktivierter Verschlüsselung sieht man die echten Dateinamen und anhand des lastmodified-Datums kann man die richtige Datei identifizieren.

Möchte man eine verschlüsselte Datei umbenennen, also den verschlüsselten Namen ändern, gibt es einen einfachen Workaround.

Als erstes erstellt man mit dav put eine neue Datei mit dem gewünschten Namen.

$ dav put cryptrepo/newfile.txt -
^D

Dann holt man sich den Inhalt der crypto-name Property.

$ dav get-property cryptrepo/newfile.txt idav:crypto-name
z7qDCHM65EuUSooCt22yaI2d2zwKDdPDlgte23ATkUo=

Die Datei kann dann wieder gelöscht werden.

$ dav rm cryptrepo/newfile.txt

Die verschlüsselte Datei, die man umbenennen möchte, bekommt jetzt den Inhalt der crypto-name Property.

$ dav set-property cryptrepo/test.txt idav:crypto-name z7qDCHM65EuUSooCt22yaI2d2zwKDdPDlgte23ATkUo=

Und schon denkt dav, dass die Datei newfile.txt heißt.

Zurück Weiter