Archiv des Autors: PemoAdmin

Das ewige Problem mit vollen Festplatten und eine einfache Lösung (von Victor Bäsik)

Festplatten sind immer zu klein, daran hat sich seit meiner ersten 10 MB-Festplatte aus dem Jahr 1986 nichts geändert (wobei, wenn ich noch einmal darüber nachdenke, 10 MByte erscheinen aus heutiger Sicht natürlich wie ein Witz, aber zu voll war sie eigentlich nicht – klar, damals gab es noch kein Windows bzw. Windows war lediglich ein GUI-Aufsatz, den man nicht verwendet hatte).

Ich erinnere mich auch noch an eine Diskussion über die Frage, wozu um alles in der Welt jemand eine 200 MB-Festplatte benötigen könnte. Ich hatte keine Antwort auf die Frage. Damals gab es noch kein Internet bzw. über das Internet wurden keine 10 GB großen Dateien übertragen.

Heute, im Zeitalter der 16 TB großen Festplatten, sollte es eigentlich kein Platzproblem mehr geben. Mit 2 Ausnahmen: Man spart bei der SSD und man weiß nicht, was man auf der Festplatte alles installiert hat.

Nachdem für mein Laufwerk C: tatsächlich 0 Byte freier Platz angezeigt wurde, muss ich mir etwas einfallen lassen. Der Kauf einer neuen SSD war keine Option, also musste ich aufräumen. Doch wo anfangen?

Ein genialer Helfer ist für mich seit vielen Jahren TreeSize Pro von Jam Software (www.jam-software.de). Da meine Lizenz abgelaufen war (die Free-Version hätte für meine Zwecke auch genügt), war zuerst ein Update für ca. 15€ fällig (das Geld ist gut investiert und ich schätze es sehr, dass es noch Softwarefirmen gibt, deren Geschäftsmodell ausschließlich auf dem Verkauf von Lizenzen basiert).

Dank TreeSize wußte ich ein paar Sekunden später was der Grund für meine Speicherknappheit war. Da gab es ein paar 5 GB (!) große Dateien, die u.a. von meiner Ocolus VR und von Cinema 4D belegt wurden. Dateien gelöscht, Problem gelöst. So einfach kann es manchmal sein.

Abb. Dank TreeSize von Jam Software ist das Aufspüren von Speicherfressern zum Glück sehr einfach

Ein Buch über eine (!) Zeile BASIC-Code

Per Zufall bin ich auf ein absolut originelles Buch gestoßen.

In 10 PRINT CHR$(205.5+RND(1)); : GOTO 10 geht es allen Ernstes nur um diese eine Zeile. Und das auf 309 Seiten. Auch wenn der Befehl, der ein endloses „Labyrinth“ auf dem Bildschirm ausgibt zugegeben faszinierend ist, für die Erklärung sollte man nicht über 300 Seiten benötigen.

Der Hintergrund ist, dass (natürlich) nicht diese eine Zeile beschrieben wird, sondern die Philosophie dahinter. Und das von insgesamt acht Autoren. Das Buch ist im seriösen MIT-Press-Verlag erschienen und die Bewertungen bei Amazon sind alle sehr positiv.

Bei Amazon war mir das Buch aber doch etwas teuer, bei booklooker.de gab es es deutlich günstiger über eine Versandbuchhandlung in Bremen.

Mehr zu dem Buch an dieser Stelle zu einem späteren Zeitpunkt. Dieser Eintrag ist daher auch eher eine „Note to myself“.

Es gibt auch eine Webseite, die dem Buch gewidmet ist: https://10print.org/

PowerShell versus Python – es kommt auf die Community an

Im Mai habe ich sowohl an der PowerShell DevOps-Konferenz und an der PyCon 2021 teilgenommen. Beide fanden natürlich online statt und die Teilnahmegebühr war deutlich niedriger als es bei einer „In-Person-Konferenz“ der Fall gewesen wäre. Die Teilnahme am PowerShell DevOps Summit kostet 300 USD, die Teilnahme an der PyCon kostete zwischen 50 und 150 USD (je nach „Status“, also Student, Einzelperson und Firma), die Teilnahme an den zahlreich angebotenen Tutorials kostete noch einmal 50 USD.

Sowohl bei der PowerShell- als auch bei der PyCon-Konferenz gab es daher viele Teilnehmer*Innen, die zum ersten Mal dabei waren und im Chatfenster darauf hinwiesen, dass sie ohne Corona so schnell nicht an einer solchen Konferenz hätten teilnehmen können.

Ich möchte im Folgenden nicht beide Konferenzen gegenüberstellen, sondern lediglich stichwortartig auf ein paar Punkte hinweisen, die mir aufgefallen sind. Bereits vorweg, die Teilnahme hat sich in beiden Fällen definitiv gelohnt und es hat zudem auch Spaß gemacht, auch wenn die komplette Konferenz im Browser stattfand. Auf der PowerShell-Konferenz war die Stimmung (wie immer) gut und sogar etwas euphorisch (bezogen auf die Kommentare im Chat-Fenster), auf der PyCon ging es etwas „seriöser“ zu, was aber für mich in erster Linie ein Generationsthema ist. Gefühlt sind die Teilnehmer*Innen auf der PyCon etwas jünger. Alle daraus gezogenen Rückschlüsse sind natürlich rein subjektiv;)

Die PyCon ist eine richtig große Konferenz. Nicht nur, was die Länge angeht (früher hatte ich mich oft gefragt, wie eine Konferenz über 9 Tage gehen kann, wenn in ersten Tagen aber lediglich Workshops zu teilweise recht speziellen Themen stattfinden und die eigentliche Hauptkonferenz nur 3 Tage umfasst, rückt das die Größenordnung wieder etwas zurecht), sondern auch die Anzahl der Teilnehmer. Auf dem PowerShell Summit waren es geschätzt ca. 300 Teilnehmer (überwiegend männlich;), auf der PyCon waren offiziell 2-636 Teilnehmer*Innen virtuell anwesend, es gab eine beindruckene Zahl von über 100 Speakern, die über 100 Sessions durchgeführt haben. Die Anzahl der Besucher wurde am Ende mit ca. 23.000 angeben. Die Anzahl der Besucher in den 49 (!) virtuellen Austellungsboxen sogar mit ca. 24.000. Klingt nach viel und ist es wahrscheinlich auch.

Während bei PowerShell die Community aus meiner Sicht etwas stagniert (PowerShell-MVP Mark Kraus hatte vor einiger Zeit seinen Frust über den Umstand, dass im PowerShell Commitee, welches das Open Source-Projekt steuert, nur Mitarbeiter von Microsoft vertreten sind, in einem 12 teiligen Twitter-Serie zum Ausdruck gebracht, und dabei auch ein wenig Microsoft dafür kritisiert, dass sie das Potential der PowerShell nicht wirklich einsetzen zu wenig für die Community tun (was ich auch bestätigen kann):

https://twitter.com/markekraus/status/1390695893188288514

Offenbar als Reaktion auf die „Misstände“, die per Twitter beklagt, haben er und ein paar Mitstreiter das P#-Projekt ins Leben gerufen (zum Glück war der Buchstabe noch frei;):

https://github.com/markekraus/psharp

Es würde vom Thema zu stark abweichen, darauf einzugehen, zumal das ganze Projekt zur Zeit (Stand: Mai 2021) nur aus einer Absichtserklärung besteht. Im Gunde geht es um eine alternative PowerShell, die nicht unter der (ausschließlichen) Kontrolle von Microsoft entwickelt wird.

Die Themenliste zur PyCon 2021 gibt es hier:

https://us.pycon.org/2021/schedule/tutorials/

Zum Abschluss noch zwei „Live-Aufnahmen“ von den Konferenzen. Da ich alle Protagonisten auch schon live erlebt hatte (Jeffrey und Joey waren schon mindestens einmal bei der PowerShell-Konferenz in Hannover dabei gewesen, Mariatta war bei der PyCon 2019 in Berlin zu Gast), war die Begegnung im Browser dann doch etwas persönlicher.

Abbildung 1: Powershell-Erfinder Jeffrey Snover und PowerShell-Projektleiter Joey Aiello beim State of the-Talk 2021
Abbildung 2: Python Code-Maintainerin Mariatta beim restructuredText-Workshop mit Teilnehmern

Flexibles Replace dank MatchEvaluator

Eine simple Anforderung soll (unbedingt;) per Regex gelöst werden: Der Ersatz einer Umgebungsvariablen in der alten Schreibweise aus einer Pfadangabe.

Beispiel:

Aus einem %temp%\test123 soll %temp% durch den Pfad des temp-Verzeichns im Benutzerprofil ersetzt werden.

Das Problem: Der Replace-Operator ermöglicht keine Ausdrücke in dem Einsetzwert.

Der folgende Befehl ersetzt lediglich %temp% durch temp:

"%temp%\test1234.dat" -replace "%(\w+)%", '$1'

Statt „temp“ soll z.B. [Environment]::GetEnvironment(Variable($1) eingesetzt werden.

Auch wenn ich einiges ausprobiert hatte, der zweite Wert darf nur aus $1, $S2 usw. bestehen. Ein Ausdruck, bei dem $1 als Operand vorkommt, ist nicht erlaubt.

Zum Glück gibt es eine flexible Alternative. Diese besteht darin, die statische Replace-Methode der Regex-Klasse zu verwenden beim Aufruf einen MatchEvaluator zu übergeben, der bei der PowerShell lediglich aus einem ScriptBlock besteht, dem der Match als Parameterwert übergeben wird:

$t = "%temp%\Test1234.dat" $m = "%(\w+)%" $MatchEval = { param($match) [Environment]::GetEnvironmentVariable($match.groups[1].value) } [Regex]::Replace($t, $m, $MatchEval)

PowerShell DevOps Global Summit 2021

Heute (29.4.2021) ist der letzte Tag des PowerShell DevOps Global Summit 2021, an dem ich dieses Mal virtuell teilnehme (auch wenn es natürlich sehr viel schöner gewesen wäre, im sehr schönen Meydenbauer Center in Bellevue/WA an der Konferenz teilzunehmen – vor allem die Happy Hour am Abend ist sehr gut;).

Es war eher ein spontaner Entschluss – die Konferenzteilnahme kostet 300 USD, was absolut in Ordnung ist.

Mein Zwischenfazit ist, dass alle Vorträge bislang sehr gut waren. Auch wenn es in einigen Vorträgen eher um die „Basics“ ging (etwa SQL Server-Konfiguration per DSC oder die API der PowerShell), waren die Vorträge eine sehr gute Mischung aus etwas Theorie und sehr viel Praxis. Und darauf kommt es am Ende immer an. Auch die Sprecher selber sind alle sehr gut.

Nicht ganz so inspirierend wie früher war die Keynote mit Jeffrey Snover und Joey Aiello. Erster ist bekanntlich der Erfinder der PowerShell, Letzter der Leiter des Entwicklerteams (beide waren auch bereits bei einer der letzten European PowerShell Conferences in Hannover dabei, so dass sie viele PowerShell-Fans inzwischen auch persönlich kennen dürften – zum Smalltalk gibt es auf der Konferenz stets viele Gelegenheiten). Es ging wieder einmal in erster Linie um einen Rückblick und über die Abrufzahlen von der Projektwebseite (Windows holt auf) und was mit PowerShell 7.2 kommen könnte. Zum einen ist das normal für ein größeres Open Source-Projekt. Zum anderen macht sich bei Menschen, die täglich in einem halben Dutzend Videokonferenzen sein dürften, irgendwann auch einmal die „Zoom-Müdigkeit“ bemerkbar. Immerhin haben die Konferenzveranstalter nicht Ms Teams verwendet, sondern eine kleine Plattform, die speziell für Online-Konferenzen gedacht ist, und die insgesamt sehr gut funktioniert hat.

Es war auch nett, einige der aus der PowerShell Community bekannten Namen zu lesen. Auch wenn der Austausch meistens nur im Chat-Fenster stattfand, kam doch etwas „Konferenz-Feeling“ auf.

Die Adresse des PowerShell Summits noch zum Schluss: https://events.devopscollective.org/event/powershell-devops-global-summit-2021/

Abb. Dieses Mal nur virtuell – der „State of the Union“-Vortrag 2021 zum aktuellen Stand der PowerShell mit PowerShell-Erfinder Jeffrey Snover und PowerShell-Chef-Projektleiter Joey Aiello

Neue PowerShell-Bücher

Gleich vorweg, diesen Eintrag wollte ich bereits im August 2020 schreiben, bin aber offenbar nicht dazu gekommen, ihn fertig zustellen – wie die Zeit vergeht…

Es gibt sie noch, die PowerShell-Bücher, in denen auch für erfahrene PowerShell-Anwender etwas Neues drin steht. Man findet sie allerdings weniger bei den Fachverlagen, diese Bücher werden schon seit längerem durch die Autoren direkt herausgegeben und über eBook-Plattformen wie lulu.com oder leanpub.com angeboten.

Das erste Buch von zwei Büchern, das ich kurz vorstellen möchte, ist allerdings nicht per Print on Demand erhältlich, das wäre aufgrund des Umfangs wahrscheinlich technisch gar nicht möglich. Es ist „das“ Standardwerk zur PowerShell im deutschsprachigen Raum von Holger Schwichtenberg, das ich vor ein paar Wochen vom Hanser Verlag erhalten habe (vielen Dank noch einmal an dieser Stelle – ich hätte es mir aber auch nicht gekauft, davon gleich mehr).

Es gibt sie noch, die dicken Wälzer, die im Buchregal nicht zu übersehen sind
Abb. Es gibt sie noch, die dicken Wälzer, die im Buchregal nicht zu übersehen sind

PowerShell 5/7 ist ein Buch, in dem praktisch alles drin steht was man als Anwender, aber auch als Entwickler zur PowerShell wissen muss und wissen könnte – natürlich gibt es immer noch Randbereiche, die auch in diesem Buch nicht behandelt werden, mir fehlt z.B. das Thema Release-Pipeline für PowerShell-Module oder mehr Informationen zum Script Analyzer, aber das sind wie gesagt Randbereiche, in die sich jeder erfahrene Anwender über das Know-how auf den entsprechenden Webseiten selber einarbeiten kann.

Zwei eher kuriose Details zu dem Buch:

  1. Mit 1.386 Seiten ist es glaube ich mein dickstes Buch im Regal (ein paar Seiten mehr als „Windows Server 2008“ von Eric Tierling) und mit Sicherheit ein paar Seiten mehr als „Krieg und Frieden“ von Tolstoy.
  2. Es dürfte das weltweit einzige IT-Buch sein, bei dem zwei nicht zusammenhängende Versionsnummern im Titel stehen.

Das zweite Buch geht in die entgegengesetzte Richtung. Anstatt ein zusammenhängendes Thema zu beschreiben, enthält es viele Themen, die lediglich den fortgeschrittenen Einsatz der PowerShell zum Thema haben. Es ist das PowerShell Conference Book, Volume 3, das von den Organisatoren des jährlich stattfindenden DevOps Summit herausgegeben wird.

https://leanpub.com/psconfbook3

Mit einem Minimum-Preis von 49.99 USD ist es nicht gerade günstig (ich hatte es gleich zum „Einführungspreis“ von 20 USD gekauft), aber es enthält das sprichwörtlich „geballte Wissen“, das man normaleweise nur durch Teilnahme an einer solchen Konferenz erhält und die ist bekanntlich deutlich kostspieliger (ähnliche Überlegungen dürften auch die Herausgeber angestellt haben). Laut Webseite verdienen die Autoren an dem Buch nichts, der Gewinn fließt komplett an eine Stiftung (https://events.devopscollective.org/onramp/scholarship/).

Abb. Geballtes Wissen einer Fachkonferenz

EIne weitere Buchempfehlung betrifft ein Buch, das ich bislang weder gekauft noch gelesen habe, sondern nur das kostenlose Probekapitel kenne. In „Shell of an Idea“ beschreibt PowerShell Guru Don Jones ausführlich die Anfänge des PowerShell-Projekts bei Microsoft und dabei vor allem über die Widrigkeiten, denen das kleine Team von Anfang ausgesetzt war (es hätte nicht viel gefehlt und wir hätten anstelle der PowerShell einen 1:1 Port einer gewöhnlichen Unix-Shell erhalten). Das Vorwort ist natürlich von Jeffrey Snover, dem geistigen Vater der PowerShell. Auch wenn das Buch bestimmt sehr interessant ist und ich es natürlich auch irgendwann in naher Zukunft lesen werde, es ist nur etwas für die paar Tausend „Hardcore PowerShell Fans“ auf der ganzen Welt, die aus erster Hand erfahren wollen wie alles anfing (vieles hat Jeffrey Snover in den letzten Jahren in zahlreichen Interviews und in seinen Vorträgen, die es fast alle auf YouTube gibt, bereits erzählt).

StackOverflow führt offenbar ein Click-Limit ein – droht dem Copy&Paste-Coding damit das Aus?

Ausgerechnet zum 1. April führt StackOverflow (S0) eine Neuerung ein, die vielen Entwicklern, die ohne SO nicht mehr produktiv entwickeln können, nicht gefallen wird und vielleicht sogar dazu könnte, dass das Know how für die tägliche Programmierung (etwa „wie führe ich einen SQL-Join durch?“, „Wie sortiere ich eine Hashtable per LINQ?“ oder „Welche Alternativen gibt es zu JavaScript?“) wieder aus klassischen Quellen (etwa einem Fachbuch) bezogen werden muss.

In Zukunft soll es offenbar eine Begrenzung der Copy-Shortcuts pro Session geben, wenngleich nicht klar ist, auf welchen Zeitraum sich die Begrenzung bezieht. Eventuell gilt das Limit von 3 Copy-Shortcuts pro Tag, es könnte aber auch an die IP-Adresse gekoppelt sein. Dann würde es lebenslänglich gelten.

Bild: In Zukunft kein Copy-Paste-Coding mehr möglich?

Kostenlos sind 3 Copy-Shortcuts, weitere Copy-Aktionen sind dann nur noch über ein spezielles Keyboard möglich, das exlusiv von StackOverflow vertrieben wird.

Bild: Wer StackOverflow in Zukunft uneingeschränkt für Copy&Paste-Coding nutzen möchte, benätigt dafür eine proprietäre Hardware-Erweiterung

Auch wenn klar ist, dass StackOverflow irgendwann auch einmal Geld verdienen muss, für mich ist das der falsche Ansatz. Entwickler zu irgendetwas zwingen zu wollen, hat noch nie etwas gebracht (sonst gäbe es schon längst fehlerfreien Code).

Ich werde mir das Keyboard definitiv nicht anschaffen und in Zukunft einfach andere Quellen nutzen. Dass ich aber offizielle Dokumentationen durchforsten werde, kann ich mir nur schwer vorstellen. Im Grunde läuft es auf die simple Frage hinaus, wie Software-Entwicklung vor der Erfindung von StackOverflow überhaupt möglich war. Die Frage können vielleicht EDV-Historiker beantworten.

Unterschied zwischen PowerShell und Python – kurz, knapp und sehr eindrucksvoll

Der Vergleich zwischen Programmiersprache A und Programmiersprache B ist im Allgemeinen wie der sprichwörtliche Vergleich zwischen Äpfel und Birnen. Zwei Programmiersprachen lassen sich einfach nicht objektiv vergleichen. Der folgende „Vergleich“ zwischen PowerShell und Python ist daher auch nicht ganz ernst gemeint.

Eine Stärke von Python ist, dass es keine echte Limitierung für die Größe von ganzen Zahlen gibt.

Der folgende Ausdruck liefert in Python eine Zahl, die in einem typischen Konsolenfenster ganze 245 Zeilen (!) umfasst.

Bei der PowerShell besteht das Ergebnis dagegen aus nur einem einzigen Zeichen. Mathematisch korrekt sind beide;)

Die PowerShellv erwendete für sehr große Zahlen eine praktische Abkürzung;)

Tipp des Tages: Source-Abfrage bei Get-WinEvent

Bei PowerShell 7 gibt es bekanntlich kein Get-EventLog-Cmdlet mehr, statt dessen gibt es das universelle Get-WinEvent-Cmdlet, das es bereits bei der Windows PowerShell gab. Das Cmdlet ist zwar insgesamt leistungsfähiger, aber auch nicht ganz so pflegeleicht, da Filterparameter entweder über eine Hashtable oder einen XPath-Ausdruck angegeben werden müssen.

Ich habe ein wenig suchen müssen, um das Pendant für den Source-Parameter von Get-Eventlog für Get-WinEvent ausfindig zu machen. Es ist in beiden Fällen die Angabe „Providername“ innerhalb des Suchausdrucks.

Die beiden folgenden Befehle geben die letzten 10 Einträge aus dem System-Eventlog zurück, die vom Service Control Manager geschrieben wurden.

[code language=“powershell“] Get-WinEvent -FilterHashtable @{Logname=“System“;Providername=’Service Control Manager‘} -MaxEvents 10 [/code]

und

[code language=“powershell“] Get-WinEvent -FilterXPath „Event/System/Provider[@Name=’Service Control Manager‘]“ -LogName System -MaxEvents 10 [/code]