#!/bin/blog

May 4, 2019

3 Monate Alienware m15

Filed under: Uncategorized — martin @ 12:59 pm

Nachdem mein Macbook Pro auch schon wieder mehr als 4 Jahre auf dem Buckel hatte, musste ich langsam akzeptieren, dass das nächste kein Macbook mehr sein konnte. Ungelöste Mechanikprobleme an den aktuellen Tastaturen, fehlende Esc-Taste, und das ganze, da es ein dedizierter Grafikchipsatz sein sollte, ausschließlich zu abenteuerlichen Preisen um 3000 Euro. Da musste Apple leider mal draußen bleiben.

Nach qualvoller Evaluierung der Optionen entschied ich mich für das neue Dell Alienware m15 mit US-Tastatur, mattem 15.6″ Full-HD-Bildschirm mit 144Hz, Intel Core i7-8750H (6 Core, 12 Threads), 16 GB Arbeitsspeicher, Nvidia Geforce GTX 1060 und 3 Jahren Next-Day vor-Ort-Service. Die gewählte Konfiguration hat keine 2,5″-SATA-Festplatte mehr, sondern einen entsprechend von 60Wh auf 90Wh vergrößerten Akku.

Als Massenspeicher hatte ich das NVMe-Modul mit 256GB gewählt, das ich sofort nach Lieferung durch eines von Samsung mit 1TB getauscht habe. Bemerkenswert ist, dass noch ein zweiter NVMe-Slot frei ist, so dass man sich auch eine schicke und schnelle RAID-Konfiguration bauen könnte.

Das Gehäuse des m15 ist das flachste, das Alienware bisher angeboten hat. In Relation zum Display hat es aber einen auffallend großen Fußabdruck und hat ein 4:3-Format. Die sehr breiten schwarzen Ränder ober- und speziell unterhalb des Display habe ich zu Anfang als sehr störend empfunden. Ich nehme den ca. 5cm breiten unteren Rand aber aktuell als ergonomisch äußerst vorteilhaft wahr, da er das Display auf eine bessere Betrachtungsposition anhebt.

Tastatur und Verarbeitung gefallen mir sehr gut. Das Gehäuse sieht zwar sogar dort, wo es hochwertig aussehen soll, äußerst plastikhaft aus, ist aber tatsächlich aus Metall und gibt nirgends nach. Störend ist lediglich die geriffelte Fläche oberhalb der Tastatur, die Staub magisch anzieht. Um- und Aufrüstungen am m15 sind sehr einfach möglich, indem eine Handvoll Phillips-Schrauben rausgedreht werden und die untere Gehäusehälfte rundum mit einer einschlägigen Plastikkarte ausgeclipst wird. Danach liegen die NVMe- und RAM-Slots direkt frei. Hat man sich einmal an die sehr gute Tastatur des m15 gewöhnt und bekommt wieder eine Macbook-Tastatur unter die Finger, ist die Macbook-Tastatur mit ihrem widerwilligen Druckpunkt merklich schlechter.

Mit dem vorinstallierten Windows 10 hatte ich unglaublich viele Probleme vor allem im Bereich irgendwelcher Systemdateien, deren Ownership nicht stimmte. Das Diagnose-Tool von Samsung konnte nicht auf die SSD zugreifen, weil die NVMe-Slots im BIOS als “RAID” konfiguriert waren, was ich durchaus als unangenehme Schräglage empfand. Nach einer kompletten Windows-Neuinstallation macht das System keinerlei Probleme mehr und wirkt nicht mehr, als stamme es von einem besonders lieblos geklonten Image ab.

Erwartungsgemäß können die Lüfter des Notebook auch bei mäßigem Gebrauch immer mal wieder hörbar werden, etwa bei abenteuerlichen Workloads wie dem Betrachten eines Twitter-Feed mit einem eingebetteten animierten GIF. Die mitgelieferten Tools von Alienware sind erwartungsgemäß zu wenig zu gebrauchen, unter anderem auch nicht zum Heruntertakten des Prozessors. Mit dem einschlägig bekannten Tool ThrottleStop lässt sich der Takt aber soweit einschränken, dass das Gerät praktisch lautlos bleibt und man es bedenkenlos auf Knien oder Sofakissen benutzen kann. Wo man gerade dabei ist, erledigt man am besten auch die Belegung der Macro-Tasten über ein externes Tool. Mit Sharp Keys kann man sie etwa zu den Funktionstasten F13-F16 erklären, das ganze in die Registry schreiben (so dass Sharp Keys auch gleich wieder weg kann, vorzugsweise nachdem man auch CapsLock deaktiviert hat) und die neuen F-Tasten nach Geschmack mit Funktionen belegen. Ich schalte mit Macro 1 und Macro 2 zwischen dem mit ThrottleStop konfigurierten “Silent-/Batterie-Modus” und voller Leistung um.

Das Zusammenspiel zwischen CPU-Grafik und Nvidia-Grafik entpuppt sich dank irgendwelcher automatischer “Optimierungen”, die Alienware und der Nvidia-Treiber glauben vornehmen zu müssen, als größeres Gewurste, als erwartet. Läuft mein Spiel nun mit 60 FPS, weil irgendein Optimierungsquatsch das für ausreichend hält (wohlgemerkt auf einem 144Hz-Display, für das ich Aufpreis bezahlt habe), oder läuft es vielleicht auf der CPU statt auf dem Nvidia-Chipsatz? Diese Optimierungen sollen der Geräusch- und Wärmebegrenzung sowie der Verlängerung der Batterielaufzeit dienen, aber ernsthaft, wenn ich auf meinem 144Hz-Laptop ein Spiel starte, dann sitze ich mit Netzteil an der Steckdose, und sonst nirgends. Leider habe ich es aufgrund dieser Probleme noch nicht geschafft, Doom 2016 in einer Qualität laufen zu lassen, die an die Nvidia Geforce GTX 960 im einige Jahre alten stationären PC heranreicht. Counterstrike: Global Offensive geht dafür sehr gut. Immerhin.

Mit gedrosseltem Prozessor, auf 60Hz gedrosseltem Bildschirm (diese Drosselung muss man natürlich auch wieder mit einem externen Tool freischalten) und einfachen Workloads liegt die Batterielaufzeit oberhalb von 5 Stunden, womit sich auch längere Meetings problemlos bestreiten lassen.

Vom integrierten Ethernet-Port hatte ich mir einiges versprochen, aber die Warnungen, die mich diesbezüglich erreicht hatten, waren leider zutreffend und die Einbauposition sorgt bei besser verarbeiteten RJ45-Steckern wie dem Hirose TM31 dafür, dass diese sich von selbst entriegeln und das Kabel aus dem Port flutscht. Zuhause benutze ich also hauptsächlich einen USB-Ethernet-Adapter, den ich im Zweifelsfall zwecks Zugentlastung auf der jeweils anderen Gehäuseseite einstecken kann.

Der Umstieg vom Macbook zum Windows-Notebook war nicht wirklich schmerzhaft. Das einzige störende Element ist, dass man Windows immer in den Tiefschlaf schicken muss, da man bei Nutzung des normalen Ruhemodus wie unter MacOS praktisch täglich einen brüllend heißen Rechner aus der Tasche holt, der im zugeklappten Zustand aufgewacht ist.

Meine UNIX-Shell unter Windows habe ich per Cygwin abgebildet, und ansonsten sind die wichtigsten Tools (LibreOffice, Firefox, Thunderbird, GIMP) identisch mit denen, die ich auch unter MacOS oder Linux benutzen würde. Die “großen” kommerziellen Softwarepakete (in meinem Fall Adobe CC und DxO PhotoLab) sind heutzutage alle doppelt für MacOS und Windows lizensiert, so dass es hier zu keinen Überraschungen kam.

Da der Rechner nicht primär als Spiele-PC benutzt wird, hätte ich auf 144Hz zugunsten der besseren Farbtreue des 60Hz-Display verzichten oder sogar die Variante mit der höheren Auflösung wählen können. Davon abgesehen, bin ich mit dem Gerät sehr zufrieden und kann unter der Voraussetzung, dass nicht versucht wird, das vorinstallierte Windows zu benutzen, für das Alienware m15 eine klare Empfehlung aussprechen.

Advertisements

July 29, 2017

Debian /boot old kernel images

Filed under: Uncategorized, UNIX/Linux/BSD — Tags: , — martin @ 10:59 am

So I was looking at yet another failed apt-get upgrade because /boot was full.

After my initial whining on Twitter, I immediately received a hint towards /etc/apt/apt.conf.d/01autoremove-kernels, which gets generated from /etc/kernel/postinst.d/apt-auto-removal after the installation of new kernel images. The file contains a list of kernels that the package manager considers vital at this time. In theory, all kernels not covered by this list should be able to be autoremoved by running apt-get autoremove.

However it turns out that apt-get autoremove would not remove any kernels at all, at least not on this system. After a bit of peeking around on Stackexchange, it turns out that this still somewhat newish concept seems to be ridden by a few bugs, especially concerning kernels that are (Wrongfully? Rightfully? I just don’t know.) marked as manually-installed in the APT database: “Why doesn’t apt-get autoremove remove my old kernels?”

The solution, as suggested by an answer to the linked question, is to mark all kernel packages as autoinstalled before running apt-get autoremove:

apt-mark showmanual | 
 grep -E "^linux-([[:alpha:]]+-)+[[:digit:].]+-[^-]+(|-.+)$" | 
 xargs -n 1 apt-mark auto

I’m not an APT expert, but I’m posting this because the post-install hook that prevents the current kernel from being autoremoved makes the procedure appear “safe enough”. As always, reader discretion is advised. And there’s also the hope that it will get sorted out fully in the future.

July 7, 2017

How expiration dates in the shadow file really work

Filed under: Uncategorized, UNIX & Linux — Tags: , , , , — martin @ 6:24 pm

tl;dr: Accounts expire as soon as UTC reaches the expiration date.

In today‘s installment of my classic shame-inducing series “UNIX basics for UNIX professionals”, I want to talk about account (and password) expiration in /etc/shadow on Linux.

The expiration time is specified as days since january 1st, 1970. In the case of account expiration, the according value can be found in the second to last field in /etc/shadow.

Account expiration can be configured using the option „-E“ to the „chage“ tool. In this case, I want the user „games“, which I‘ll be using for demonstration purposes, to expire on the 31st of december, 2017:

# chage -E 2017-12-31 games

Using the „-l“ option, I can now list the expiration date of the user:

# chage -l games
[…]
Account expires : Dec 31, 2017
[…]

The first thing to be taken away here is that, as I can only use a number of days, I can not let a user expire at any given time of day. In /etc/shadow, I have now:

# getent shadow | awk -F: '/^games:/{print $8}'
17531

This of course can to be converted to a readable date:

# date --date='1970-01-01 00:00:00 UTC 17531 days'
Sun Dec 31 01:00:00 CET 2017

So, will the account still be usable on december 31st? Let‘s change it‘s expiration to today (the 7th of July, 2017) to see what happens:

# date
Fri Jul 7 12:58:32 CEST 2017
# chage -E today games
# chage -l games
[…]
Account expires : Jul 07, 2017
[…]
# su - games
Your account has expired; please contact your system administrator
[…]

I’m now only left with the question whether this expiration day is aligned on UTC or local time.

# getent shadow | awk -F: '/^games:/{print $8}'
17354
# date --date='1970-01-01 00:00:00 UTC 17354 days'
Fri Jul 7 02:00:00 CEST 2017

I‘ll stop my NTP daemon, manually set the date to 00:30 today and see if the games user has already expired:

# date --set 00:30:00
Fri Jul 7 00:30:00 CEST 2017
# su - games
This account is currently not available.

This is the output from /usr/sbin/nologin, meaning that the account is not expired yet, so I know for sure that the expiration date is not according to local time but to UTC.

Let‘s move closer to our expected threshold:

# date --set 01:30:00
Fri Jul 7 01:30:00 CEST 2017
# su - games
This account is currently not available.

Still not expired. And after 02:00:

# date --set 02:30:00
Fri Jul 7 02:30:00 CEST 2017
# su - games
Your account has expired; please contact your system administrator

So, in order to tell from a script whether an account has expired, I simply need to get the number of days since 1970-01-01. If this number is greater or equal to the value in /etc/shadow, the user has expired.

DAYSSINCE=$(( $(date +%s) / 86400 )) # This is days till now as per UTC.
EXPIREDAY=$(getent shadow | awk -F: '/^games:/{print $8}')
if [[ $DAYSSINCE -ge $EXPIREDAY ]] # Greater or equal
then
    EXPIRED=true
fi

One last thought: We’ve looked at a time zone with a small offset from UTC. What about timezones with larger offsets, in the other direction?

  • If we move the timezone to the east, further into the positive from UTC, it will behave the same as here in CEST and the account will expire sometime during the specified day, when UTC hits the same date.
  • If we move the timezone far to the west, like e.g. PST, and an absolute date is given to “chage -E“, the account will probably expire early, the day before scheduled expiration. I was not able to find anything useful on the web and even my oldest UNIX books from the 1990s mention password expiration only casually, without any detail. Active use of password expiration based on /etc/shadow seems to be uncommon. The code that seems to do the checking is here and it does not appear to care about time zones at all.
  • Any comments that clarify the behaviour in negative offsets from UTC will be appreciated.

May 4, 2008

Swap im Reality Check

Filed under: Uncategorized — martin @ 10:02 pm

Swap unter Linux scheint so eine Sache zu sein, um die sich reichlich Mythen und Legenden ranken. Deshalb schreibe ich heute mal auf, was ich so von der Sache halte.

Wie wir alle wissen, wird der Swap-Bereich zusammen mit dem realen Arbeitsspeicher (RAM) zum sogenannten Virtual Memory (VM) zusammengefaßt. Auf einem System mit 2 GB RAM und 2 GB Swap steht also ein für Appikationen nutzbares VM von 4 GB zur Verfügung. Die Hälfte davon befindet sich als Swap auf Festplatte. Zugriffe darauf sind sehr viel langsamer als Zugriffe auf den normalen Arbeitsspeicher.

Mythos: “Jedes UNIX-System braucht Swap!”

Swap ist nicht mehr als eine sehr, sehr langsame Speichererweiterung. Ist der Arbeitsspeicher voll, werden Speichersegmente auf Festplatte ausgelagert. Dadurch, daß diese Auslagerung deutlich langsamer als normale RAM-Aktiviät geschieht, wird das System in aller Regel extrem langsam. Diese Auslagerungsaktivität kann im Rahmen einer Überwachung erkannt werden. Idealerweise wird auch die Problemquelle identifiziert und der entsprechende Prozeß von Hand beendet, so daß das System weiterlaufen kann.

Daraus folgt im Prinzip nichts anderes, als daß Swap nichts weiter bringt, als einen gefühlten Zeitgewinn für das Beenden von Speicherfressern.

Auf der Hand liegt andererseits auch, daß man z.B. ein Flash-basiertes (und damit read-only)-System ohne Swap betreiben können muß. Folglich gilt, daß ein Linux-System ohne Swap problemlos laufen kann, solange der Arbeitsspeicher für den gesamten Speicherbedarf aller zu benutzenden Applikationen ausreichend dimensioniert ist.

Mythos: “Swap muß immer auf einer eigenen Partition liegen!”

Unter Linux (und vermutlich auch den meisten anderen UNIX-Systemen) ist es problemlos möglich, anstelle einer Swap-Partiton ein Swapfile zu verwenden. Die Vorgehensweise dazu ist dort in der Manpage von mkswap beschrieben. Da ein swappendes System ohnehin ein schweres Problem mit der Performance von Speicherzugriffen hat, kann man den marginalen zusätzlichen Performanceverlust durch die Dateisystemebene praktisch vernachlässigen. (Eine Ausnahme gilt, die erwähne ich im übernächsten Absatz.)

Mythos: “Es muß immer doppelt soviel Swap vorhanden sein, wie Arbeitsspeicher!”

Das ist so eine ganz alte Daumenregel, deren historischer Hintergrund schwer durchschaubar ist. Sie ist vermutlich teilweise darin begründet, daß es UNIX-Systeme gegeben haben soll, bei denen der Arbeitsspeicher auf Swap gespiegelt wurde. Um also eine wirksame Vergrößerung des VM durch Swap zu haben, war also wesentlich mehr Swap als Arbeitsspeicher erforderlich.

Eine Mindestgröße für Swap ergibt sich bei tragbaren Systemen, die für die Hibernation ihren Arbeitsspeicher auf Swap auslagern. Dies ist meines Wissens die einzige Situation, in der nicht nur eine wirkliche Mindestgröße für Swap vorliegt, sondern in der es sich auch tatsächlich um eine Swap-Partition handeln muß.

Generell gilt, daß es über die altbekannte Daumenregel hinaus keine feststehende Regel für die Swap-Größe gibt. Wer sich an der alten Regel festhalten will, darf das gern tun. Man sollte sich aber durchaus fragen, welche Dinge man von einem System mit 8, 16 oder 32 GB Swap zu erwarten glaubt.

Mythos: “Aber tmpfs braucht Swap!”

Nur um dem unvermeidlichen Kommentar vorzubeugen: Das tmpfs-Dateisystem, z.B. unter Solaris und Linux, braucht nicht Swap, sondern Virtual Memory. Es wird also bei ausreichenden Platzverhältnissen im Arbeitsspeicher gehalten, kann aber von Applikationen auf Swap verdrängt werden. Es stellt sich die Frage, inwieweit ein dediziertes Filesystem für /tmp überhaupt eine Berechtigung hat, wenn seine Schreib- und Leseperformance im Prinzip unvorhersagbar sind.

Blog at WordPress.com.