Zockertown: Nerten News

Ich freue mich wie ein kleines Kind!

Wenn es soweit ist, muß ich unbedingt mal wieder eine Lan Party machen.

Zum Appetit holen, ein Blick auf die neuen Spiel Typen: new-game-types-for-world-of-padman/

worldofpadman.net/news/world-of-padman-1-7-in-development/

ich habe mir ein weiteres Script für Nautilus gestrickt.

Ab- und zu braucht man mal die Namen einer Anzahl von Dateien, zur Weiterverwendung z.B. Dokumentation o.ä.

Das script macht das einfach, es kopiert die Dateinamen in das Clipboard und als Addon auch mit den Pfaden der Dateinamen.

Nach dem starten vom Script copy-filenames.sh

erscheint das Ergebnis augenblicklich im clipboard

Das Script:

#!/bin/bash
#
#  Titel: copy_filenames.sh
#  Autor: Bed [@] zockertown.de
#  Web: zockertown.de/s9y/
#  Version 0.4
# $Revision: 1.2 $
#  Voraussetzung: Benötigt wird xsel 
#  Zweck: kopiert die Dateinamen als Liste zur weiteren Verarbeitung
# zum Clipboard
# eine weitere Variante enthält alle Fullpath namen in einem Rutsc

if [ ! -f /usr/bin/xsel ]
then
   echo "Bitte xsel installieren."
   exit 1
fi

TMP=/tmp/allin.txt

rm -f $TMP

 for file in $NAUTILUS_SCRIPT_SELECTED_URIS

 do

   file_name=$(echo $file | sed -e 's/file:\/\///g' -e 's/\%20/\ /g' -e 's/.*\///g')
   file_folder=$(echo $file | sed -e 's/file:\/\///g' -e 's/\%20/\ /g' -e "s/$file_name//g")
   echo "$file_name"|xsel -ib
   echo "$file_folder$file_name ">>$TMP
   # sleep ist notwendig, weil ohne Verzögerung werden Einträge unterschlagen
   sleep 0.1
done

cat $TMP|xsel -ib

rm $TMP

Dreh- und Angelpunkt ist das cmdline tool xsel. Es kann Einträge zum Clipboard hinzufügen.

Macht man zuviele Einträge hintereinander unterschlägt es einzelne Einträge, deshalb habe ich sleep 0.1 in der Schleife eingebaut.

Yunohost habe ich mal ein paar Monate ausprobiert. Die Fülle von vorkonfigurierten Anwendung ist enorm, alleine mal ein Dutzend ausprobrieren zu können ist schon eine Wonne. 

An sich ist der Ansatz von Yunohost (You no Host?) einen exposed Host per dyn dns erreichbar zu haben, um sich einen ausgewachsenen Server zu sparen.

Ich betreibe mit Freunden einen Rootserver, so ist yunohost eigentlich nicht für mich interessant. Aber wie bereits geschrieben sind die installierbaren Plugins überwältigend. Zum Beispiel werde ich shaarli behalten.

Den exposed Host habe ich mittlerweile wieder entfernt, ist also nicht mehr aus dem Internet aufrufbar.

Ich brauche es einfach nicht.

Doch dieser Blog Artikel beschäftigt sich mit dem als plugin verfügbaren Pi-Hole. 

Yunohost habe ich auf einen ausgedienten Lenovo T200 Laptop installliert und die Einstellungen so verbogen, dass auch bei zugeklappten Deckel der Rechner läuft. Stromaufnahme ist ca. 11 Watt. Ungefähr das Doppelte eines Raspberry, dafür ist das Teil auch etwas flinker und hängt auch nicht von schnell sterbenden sd-cards ab :=)

Pi-Hole ist im wesentlichen ein DNS Server, der aufgerufene Seiten die bestimmten Kriterien genügenWerbung, als Hochrisiko eingestufte Webseiten, ..., blockiert.

Als wesentlichen Vorteile dieser Lösung gegenüber Addons für einzelne Browser sehe ich:

Netzwerkweiten Schutz
Pi-hole an einer Stelle und mein gesamtes Netzwerk ist geschützt. Also auch mein Smartphone, die Spiele Konsole, das smart-TV, u.a.

Dadurch, dass die Werbung gar nicht mehr geladen wird, ist die Performance beim Seitenaufbau besser, weil der Traffik geringer ist.

Damit der neue DNS Server auch benutzt wird, muß das der Fritz.box auch mitgeteilt werden. IP V6 ist auch zu empfehlen, einige Devices nutzen das im Heimat Netz, sonst sind die nicht mit geschützt und das wäre schade.

Die ip V6 Adresse, die in der Fritz.box eingetragen werden muß zeigt auf dem yunohost ip

ip -6 address show wls1
3: wls1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 state UP qlen 1000
    inet6 2003:xx:xxxx:xxx:xx:xxxx:xxxx:5616/64 scope global dynamic noprefixroute 
       valid_lft 7120sec preferred_lft 1268sec
    inet6 fe80::xxxx:xxxx:xxxx:xxx/64 scope link noprefixroute 
       valid_lft forever preferred_lft forever

Wenn man in yunohost Pi-hole installiert, verlangt die Installationsroutine zwingend einen DNS Namen. Wenn man nach der Installation keinen exposed Host mehr benutzt möchte der via Dyn DNS angesprochen wird, kann man dies einfach umgehen in dem man auf seinem Rechner, mit dem man auf die Oberfläche von PI-Hole zugreifen möchte, einen Eintrag in /etc/hosts anlegt.

z.B. bei mir 

# lokale_IP_pihole (dns.fritzbox ist vom dhcp server der Fritzbox vergeben) 
#bed.ddns.net ist der dyn dns Name, der bei der Installation vergeben worden ist.
192.168.178.50 dns.fritz.box bed.ddns.net

Damit in den Statistiken die Clients besser identifiziert werden können, muss man Pi-Hole dazu bringen die Namen aufzulösen.

Deshalb muss in der Fritzbox in den Einstellungen die Ip-Adresse von Pi-Hole als Lokaler DNS Server eingetragen werden.

Finetuning war für die Xbox-One notwendig, die wollte (konnte) sich nicht mehr anmelden. 

Zusätzlich habe ich das live.login whitelisted.

Momentan ist das Setup noch in der Erprobungsphase.

Wenn ich etwas ändere/verbessere/optimere/... werde ich das hier ergänzen.

Seit 1-2 Jahren benutze ich zim als Desktop Wiki aus dem Debian Repository. Mal mehr oder weniger intensiv.

Da ich nun alle Rechner zu Hause auf Bullseye umgestellt habe und ich bei fast allen eine Neuinstallation vorgenommen habe, fehlt mir nun ein Rechner übergreifendes Wiki.

Vor der Umstellung hatte ich es nur auf einem Rechner, dem Tuxedo. Ich habe es auf owncloud syncronisiert.

Da es damit momentan unter Bullseye noch Probleme gibt, habe ich mich nach einer Alternative umgesehen.

Da ich Kunde der Telekom bin, habe ich auch ein kleines Kontingent in der MagentaCloud.

Warum also nicht das mal nutzen?

Meine Idee ist, dass ich von allen Rechnern auf ein- und dasselbe Notizbuch zugreifen kann.

Die "echten" Collabrationstools wie z.B. QOwnNotes erschlagen mich mit den Features und sind in diesen Fall außerdem mit der QT Library, was ich ja eigentlich sonst nicht benötige, also weiterhin zim.

Nun denn, ans Werk.

MagentaCloud stellt einem den Dienst via WEBDAV zur Verfügung, man muß im account-manager

nur ein Password bei WebDAV-Passwort vergeben und sich den Benutzernamen dazu merken.

Nun gibt es mehrere Möglichkeiten, wie man WEBDAV in Linux einbindet, am rundesten finde ich, wenn man es mountet und allen Usern zur Verfügung stellt.  Aus der Beschreibung von davfs: "davfs2 ist so konzipiert, dass es sich vollständig in die Dateisystem-Semantik von  Unix-ähnlichen Systemen (mount, umount, etc.) einfügt. davfs2 macht Einhängen durch unprivilegierte Benutzer so einfach und sicher wie möglich. Das erschließt  die Möglichkeit, auf solche Ressourcen wie auf ein  typisches Dateisystem zuzugreifen, was die Verwendung durch Standardanwendungen ohne eingebaute Unterstützung für WebDAV erlaubt."

Auf seinem Rechner installiert man mit apt install davfs2 die Unterstützung.

Damit es als Drive im Verzeichnis der User auftaucht, muß folgende Zeile in der /etc/fstab hinzugefügt werden:

URL zum WEBDAV                  Mount Verzeichnis      Filesystem Optionen
https://webdav.magentacloud.de /home/bed/MagentaCloud/ davfs uid=1000,users,rw,_netdev 0 0

Für bed natürlich den eigenen Login Namen einsetzen, das Verzeichnis kann natürlich beliebig genannt werden, Hauptsache es ist vorhanden und man hat im Hinterkopf, dass es ein Remote Verzeichnis ist, deshalb finde ich den Namen ganz passend. Das _netdev sorgt dafür, dass das Verzeichnis nur gemountet wird, wenn das Netz aktiv ist und man keine Hänger beim booten oder im Flugzeugmode hat.  

Jetzt noch denselben Verzeichnisnamen im Home Directory anlegen: mkdir /home/bed/MagentaCloud/

Jetzt empfehle ich einen probe mount, um zu sehen ob Benutzername und password richtig sind.

# mount /home/bed/MagentaCloud/
Gib bitte den Benutzernamen für den Server https://webdav.magentacloud.de an; wenn du keinen angeben willst, drücke Return.
  Benutzername: xxx@xx.xx
Gib bitte das Passwort von xxx@xx.xx für den Server https://webdav.magentacloud.de
an; wenn du keines angeben willst, drücke Return.
  Passwort: 

Ist das erfolgreich, dann erscheint bei df -h

u.a. dieser Eintrag.# df

Dateisystem                     1K-Blöcke   Benutzt Verfügbar Verw% Eingehängt auf



https://webdav.magentacloud.de 1333333332 800000000 533333332   61% /home/bed/MagentaCloud

sieht gut aus? 

Ok, dann können die Einstellungen auch permanent gemacht werden, damit der unprivelegierte User das Password nicht mehr eingeben muß.

cat /etc/davfs2/secrets

https://webdav.magentacloud.de xx@xx.xx Geheimes_P@ssw0rd

Update: ab 2022 ist Magentacloud offenbar auf owncloud Instanzen. Deshalb:

https://magentacloud.de/remote.php/webdav xx@xx.xx passw-word-geheim-hihi-haha

Hinweis: WEBDAV und damit auch davfs ist kein vollwertiger Ersatz für ein anständiges Network Filesystem, wie NFS, sondern auf eine https aufbauende Krücke.

In der FAQ ist auch erläutert, warum man unter Umständen lange auf ein unmounten warten muß, z.B. auch beim Runterfahren des Rechners. Siehe  zless /usr/share/doc/davfs2/FAQ.gz 

Mit meinen Worten kurz zusammen gefasst: Beim hochladen von Dateien wird erst lokal eine Kopie angelegt und dann Häppchenweise die Datei hochgeladen. Das ist also lange noch nicht zu Ende, auch wenn der cp Befehl schon lange beendet ist.

Ein ls -l im Zielverzeichnis kommt auch dann erst zurück, wenn das kopieren wirklich beendet ist.

Das kann man schön verfolgen, wenn man parallel per Browser in der MagentaCloud verfolgt, was passiert. Erst nach vollständigem Transfer erscheint der Dateiname korrekt und mit richtigen Angaben zur Größe.

Mein Versuch zeigt bei mir (34Mit upload) doch knapp 6 Minuten für 720 MB. Also nix für Ungeduldige

Hier habe ich inzwischen gelernt, dass man tunlichst die Größe des Buffers im Auge behalten sollte.

Siehe hier

Dann ist die Geschwindigkeit erheblich besser.

Doch nun zum eigentlichen Thema. 

Zim

Ich hatte ja bereits eine weile zim benutzt, ich habe das einfach komplett an den neuen Ort kopiert und dann wie im Screenshot zu sehen, als neues Notizbuch hinzugefügt und das alte kann man dann entfernen.

Falls sich das plugin Quellcode Ansicht nicht aktivieren lässt, also nicht wie rechts GtkSourceView - OK steht. Dann bitte überprüfen, ob die Libbraries installiert sind.

ii  libgtksourceview-3.0-1:amd64           3.24.11-2                       amd64        shared libraries for the GTK+ syntax highlighting widget
ii  libgtksourceview-3.0-common            3.24.11-2                       all          common files for the GTK+ syntax highlighting widget
ii  libgtksourceview-4-0:amd64             4.8.0-1                         amd64        shared libraries for the GTK+ syntax highlighting widget
ii  libgtksourceview-4-common              4.8.0-1                         all          common files for the GTK+ syntax highlighting widget

Sollte nach einem Neustart von zim immer noch kein aktivieren möglich sein, dann hilft ein Reboot. Jedenfalls bei mir. Eigentlich peinlich, aber da ich wegen eines Kernelupdates eh booten mußte, hatte sich das gleich mit erledigt.

Im Handling ist es nun überhaupt kein Unterschied mehr, wo und was ich mit zim mache. Ich bin momentan mit dieser Lösung sehr zufrieden.

Aber bitt beachtet die Kommentare, man kann das natütlich auch anders lösen.

Denn diese Lösung ist nämlich von einer funktionierenden Internetverbindung und der MagentaCloud abhängig. Großer Mist, wenn man es eilig hat, aber man nicht an sein Wiki kommt

Apropos Netz und Zuverlässigkeit.

Ich habe mal unterschiedliche Sachen mit der MagentaCloud und dem davfs probiert. Es ist doch ziemlich robust, Gewaltsames unmounten, oder reboot richten so direkt keinen Schaden an. Ich habe ja bereits angemerkt, dass der davfs2 daemon mit einer lokalen Kopie arbeitet. Wenn die Transaktion, also das kopieren einer Datei fehl schlägt, dann bleibt die alte Kopie im cache erhalten. Wie man auf dem Screenshot sieht.

Wird der Kopiervorgang nun erneut angestoßen, wird mit einer neuen Kopie im Cache gearbeitet, zu erkennen am Timestamp und der zufälligen Extension am Namen.

Wie ich bereits schrieb, ist das zurück kehren des Prompts beim kopieren nicht das Signal, dass der Kopiervorgang abgeschlossen ist, was man hier auch schön verfolgen kann, wie lange das ls -ltr (mein Alias ltr) gebraucht hat.

Die runden 3 GIB habe knapp 60 Minuten benötigt. Da nun der Kopiervorgang erfolgreich war, befindet sich nun im Cache nur noch die Leiche des ersten durch reboot unterbrochenen Kopierversuchs.

Außerdem weiß ich nun auch, dass MagentaCloud mit 3 GB Dateien umgehen kann und das Protokoll nicht bei 2GB schlapp macht, wie es teilweise heißt. Die Grenze wird bei 4GB liegen, vermute ich. (Hinweise darauf fand ich bei der Telekom)

Um den Fass die Krone aufzusetzen:

Update: Mit owncloud geht es genauso Happy I am

... und da wird bei df -h auch der per quota mir zugeordnete Speicher korrekt angezeigt. Nicht wie bei MagentaCloud, wo nur merkwüdige Werte angezeigt werden.

Vorbemerkungen.

Thunderbird ist mein langjähriger Email Client. Da fast niemand in meinen Bekanntenkreis Enigma benutzte (das Plugin zur Verschlüsselung von E-Mails auf Basis von OpenPGP) habe ich das auch nicht verwendet. Außer dass ich es mal ausprobiert hatte.... Schande über mich.

Seit 78.2 hat Mozilla im Thunderbird nun den Support vom Enigma aufgegeben und es selbst implementiert. Nicht ohne heftige kontroverse Diskussionen in der Debian Community (und auch anders wo) auszulösen.

Seit dem ich auf Bullseye umgestiegen bin, läuft hier der Thunderbird 78.5, deshalb habe ich mich nun entschlossen das integrierte OpenPGP zu verwenden. Dabei ist diese detailierte Anleitung  (jedenfalls für meine Verhältnisse) raus gepurzelt.

Anleitung für denjenigen der vorher überhaupt noch keine E-Mail Verschlüsselung verwendet hat.

Los gehts:

Auf Einstellungen/Extras klicken.

Hier auf OpenPGP Schlüssel verwalten klicken

Jetzt ein neues Schlüsselpaar generieren.

Man sollte sich Gedanken machen, für welchen Zeitraum der Schlüssel gelten soll. Man kann einen Schlüssel auch später mal verlängern, oder sogar eine unbegrenzte Laufzeit wählen.

Die Entscheidung über die Schlüsselgröße ist dagegen später nicht mehr anpassbar, ich habe 3072 gewählt. 3072 dürfte die nächsten ein paar Jahre  noch ausreichen. Es spricht aber absolut nichts dagegen auch 4096 zu wählen.

Hier ist mein Sonderfall beschrieben, wer den oberen Schritt gemacht hat, sollte diese Importschritte überspringen.

Ich habe zuerst den Schlüssel auf meinem Tuxedo XC1506 generiert, auf meinem Zweit-Laptop den Lenovo T500, mache ich das nun auch und generiere hier die Screenshots. Weil es aber keinen Sinn macht, dass ich für ein- und dieselbe Email Adresse zwei Schlüsselpaare verwalte, was auch zur heftigen Verwirrung der email Partner führen dürfte, wenn ich abwechselnd mal den einen und den anderen verwenden würde, habe ich mit dem Import meines geheimen Schlüssels, (der den öffentlichen inkludiert) auf beiden Installationen nun dasselbe Paar.

Der exportierte Schlüssel wurde mit einem Password geschützt, das habe ich jetzt hier eingegeben.

Als Resultat ist nun derselbe Schlüssel in beiden Installationen vorhanden. Wichtig ist noch die Bemerkung am Schluß.

Importvorgang abschließen.

Damit ist der Sonderfall, Import eines vorhanden Schlüsselpaares abgeschlossen.

Hier geht es nun weiter.

Bitte wieder OpenPGP Schlüssel verwalten öffnen.

Die Dialoge wie gezeigt auswählen.  Der Screenhot rechts zeigt die obere Hälte, der untere auch weichtige Bereich kommt im nächsten Absatz, links.

Diese Einstellungen sind nicht zwingend, empfehle ich aber.

So, nun könnte man eigentlich eine verschlüsselte Nachricht senden. Dazu auf Sicherheit klicken und verschlüsselte Nachricht auswählen. Hier mal als Beispiel links gezeigt. Thunderbird beschwert sich dann aber, dass es für diesen Adressaten keinen öffentlichen Schlüssel besitzt, senden in verschlüsselter Form geht also nicht.

Also muß man sich den öffentlichen Schlüssel des Adressaten importieren.

Den Felix habe ich jetzt extra als Beispiel gewählt, weil der sehr bekannt ist und allerlei merkwürdige Personen, Spammer u.a. auf den Keyservern Fake Einträge angelegt haben. Felix selbst kann die nicht löschen, die bleiben auf Ewig dort drin. Seine und meine Lösung ist, da

ss man seinen öffentlichen Key auf seinen eigenen gehosteten Webspace zum Download anbietet.

Sollte man schon einmal mit dem Adressaten Emails ausgetauscht haben, ist die Chance relativ groß, dass man den öffentlichen Schlüssel auch bereit als Signatur mitgesendet erhalten hat. Denn kann man natürlich auch verwenden.

Die Web Adresse für meinen öffentlichen Schlüssel ist naheliegenderweise hier: https://daucity.de

Nicht verwirren lassen. Hier wurde Felix' Schlüssel importiert. Meinen eigenen kann ich schlecht akzeptieren, weil der schon drin ist. Aber ich denke man kommt schon klar, ist ja kein Hexenwerk. Beachtet auch den unteren "Akzeptanz anschauen". Das ist wichtig, kann aber wie gleich gezeigt auch noch nachgeholt werden, sollte man nicht daran denken.

So sieht das dann also aus.

 Wenn man nun versucht an den neu importierten Adressaten eine verschlüsselte Email zu senden kann unter Umständen das rechte Bild erscheinen. Denn ein importierter Schlüssel muß auch akzeptiert werden.

Hier sieht man links den Fall, dass der importierte Schlüssel noch nicht akzeptiert wurde.

Und rechts, wie man es akzeptiert.

So sieht es dann aus, wenn man einen Public key akzeptiert hat.

Damit ist diese Einführung beendet.

Eigentlich nimmt man heutzutage GIT.

Ich nicht, da ich auch nur meine eigenen Spielereien etwas sichern und den Überblick behalten möchte, verwende ich CVS.

Braucht keiner nachmachen, ich schreibs halt hier mal auf, damit ich es wiederfinde, wie ich es aufgesetzt habe.

Schönere Anleitungen gibt es im Netz, hier die Variante, die bei mir werkelt.

Mein Repository liegt auf dem Rootserver.

CVSROOT=/var/CVS

Zugriff kann lokal oder über ssh erfolgen.

Dafür habe ich

export CVSROOT=:extssh:IP-adresse:/var/CVS

in der .bashrc des Client.

Damit das Ganze funktioniert muss der lokale user auch auf dem Server existieren und den sshkey im authorized_key hinterlegt haben.

Jetzt kann auf dem Client z.B. ein Verzeichnis importiert werden.

cvs import Elektronik bed start

Elektronik ist der Ordner Name und bed ist der user.

Selbstredend sollte der Ordner Elektronik frei von unnötigem Zeug sein, sonst wird das auch versioninert. Einige wenige Dateien werden allerdings auch per default ignoriert.

Es öffnet sich nano und fragt nach einem Kommentar. Mit -m "bla fasel" könnte man das umgehen, mache ich gewöhnlich aber nicht.

Jetzt sollte eine Liste von "N Dateinamen" erscheinen, damit ist das importieren erfolgreich.

Danach kann man mit cvs co Elektronik das Verzeichnis ausschecken und so zum bearbeiten vorbereiten.

Ps: Nicht vergessen, 

 /var/CVS 

mit im Backup Script aufzunehmen.

Keywörter: "$Revision$", "$Date$" und "$Log$" 

Nützliche Seite, um die Erinnerung an die Syntax aufzufrischen:

https://gki.informatik.uni-freiburg.de/lehre/ss03/sopra/cvs.html#REVISIONSNUMMERN

Diese Frage hat mich heute Morgen beschäftigt, als mich Gnome mit einer Notiz "wichtige Aktualisierungen sind verfügbar" (leider keinen Screenshot gemacht) darauf aufmerksam machte und mir die Wahl zwischen "nicht jetzt" und "Ja, aktualisieren" ließ.

Na klar, wollte ich das mal ausprobieren, also auf "Ja" geklickt.

Dann kam der Hinweis, das dazu der Rechner rebootet werden muss.

WTF? Das hat mich dermaßen geschockt, dass ich erneut den Screenhot vergaß.

Also habe ich gesagt, "OK".

Was dann kam hat mich doch sehr überrascht. Es wurde sofort der Shutdown eingeleitet auf halben Wege  wurden dann die Pakete installiert und danach fuhr der Rechner  weiter mit dem Reboot fort.

Jetzt gab es auf dem Desktop diese Nachricht.

Hiervon habe ich einen Screenshot gemacht.

Es war ja schon lange in der internen Diskussion bei Debian, über das Für und Wider von automatischen Installationen.

Aus Sicht eines einfachen, evtl. von Windows migrierten Anwenders vielleicht gar nicht die schlechteste Idee.

Abschalten oder einfach ignorieren, bis man es dann selber macht kann man es ja trotzdem.

Doch ich bin besonders verblüfft über die Art und Weise. Ist der Reboot nun obligatorisch? Hoffentlich nicht, das wäre dann wirklich eine Verschlechterung. Bisher war das meiner Meinung nach eins der wichtigsten Argumente Linux anstelle Windows für die tägliche Arbeit zu benutzen. Wenn ich sehe wie häufig Windows Systeme wegen einer Software Aktualisierung reboot werden müssen....

Ps: ich suche nochmal die Pakete raus, die aktualisiert wurden,  es war vermutlich etwas dabei, das einen Reboot erfordert.

Nachtrag: Ja, diese Pakete waren betroffen. U.a. der Kernel.

Start-Date: 2019-08-14  08:38:35
Commandline: packagekit role='update-packages'
Upgrade: libpangoft2-1.0-0:amd64 (1.42.4-6, 1.42.4-7~deb10u1), libpangoft2-1.0-0:i386 (1.42.4-6, 1.42.4-7~deb10u1), linux-libc-dev:amd64 (4.19.37-5+deb10u1, 4.19.37-5+deb10u2), 
chrome-remote-desktop:amd64 (76.0.3809.21, 76.0.3809.117), libgs9:amd64 (9.27~dfsg-2, 9.27~dfsg-2+deb10u1), linux-image-4.19.0-5-amd64:amd64 (4.19.37-5+deb10u1, 4.19.37-5+deb10u2), 
chromium:amd64 (73.0.3683.75-1, 76.0.3809.100-1~deb10u1), gir1.2-pango-1.0:amd64 (1.42.4-6, 1.42.4-7~deb10u1), linux-compiler-gcc-8-x86:amd64 (4.19.37-5+deb10u1, 4.19.37-5+deb10u2), 
chromium-sandbox:amd64 (73.0.3683.75-1, 76.0.3809.100-1~deb10u1), chromium-common:amd64 (73.0.3683.75-1, 76.0.3809.100-1~deb10u1), pango1.0-tools:amd64 (1.42.4-6, 1.42.4-7~deb10u1), 
libpangoxft-1.0-0:amd64 (1.42.4-6, 1.42.4-7~deb10u1), libpango1.0-dev:amd64 (1.42.4-6, 1.42.4-7~deb10u1), libpangocairo-1.0-0:amd64 (1.42.4-6, 1.42.4-7~deb10u1), 
libpangocairo-1.0-0:i386 (1.42.4-6, 1.42.4-7~deb10u1), ghostscript:amd64 (9.27~dfsg-2, 9.27~dfsg-2+deb10u1), linux-headers-4.19.0-5-amd64:amd64 (4.19.37-5+deb10u1, 
4.19.37-5+deb10u2), libgs9-common:amd64 (9.27~dfsg-2, 9.27~dfsg-2+deb10u1), linux-kbuild-4.19:amd64 (4.19.37-5+deb10u1, 4.19.37-5+deb10u2), 
linux-headers-4.19.0-5-common:amd64 (4.19.37-5+deb10u1, 4.19.37-5+deb10u2), libpango-1.0-0:amd64 (1.42.4-6, 1.42.4-7~deb10u1), libpango-1.0-0:i386 (1.42.4-6, 1.42.4-7~deb10u1)
End-Date: 2019-08-14  08:39:21

Die alte Variante gefiel mir besser, es wurde einfach eine Marker Datei " /var/run/reboot-required" angelegt.

Bei einem Server ist es vermutlich immer noch so, aber auch so mancher Entwickler wird sich ärgern, wenn er durch ein leichtfertiges "Ja" seine gesamte Palette an gestarteten Programmen schwinden sieht und er alles wieder einzeln öffnen muss.

Nun Gut, das passiert nur ihm sicher nicht nochmal... 

Zum nachlesen 

https://anarc.at/blog/2016-12-22-debian-considering-automated-upgrades/

https://www.pro-linux.de/news/1/24312/debian-diskutiert-%C3%83%C2%BCber-automatische-aktualisierung-als-standard.html

Nachtrag 18.8.2019:

So, wieder wird mir von gnome eine notwendige Betriebssystem Aktualisierung angezeigt.

Auch hier blau hervorgehoben, im Hintergrund noch gerade erkennbar wird von Neustart geredet.

Diesmal ist kein Kernel Update und auch die Libs sehen für mich nicht so auss, als wäre ein Neustart notwendig.

Also kurzerhand in der Console apt update und full-upgrade gemacht.

Es wird kein /var/run/reboot-required  angelegt, also ist kein Reboot aus Sicht des Packagemanagers notwendig, dennoch wurde der Anwender von der Notwendigkeit, (siehe links) infomiert.

Erschwehrend kommt ja noch hinzu, dass man, wenn man ok gesagt hat ja den Neustart nicht mehr aufhälten kann. Das macht Windows besser (Oh Gott, dass ich das mal sage ..), denn dort wird installiert und man bekommt die Option den Neustart später zu machen.

Fazit für mich, ich inoriere die GUI Benachrichtigung und mache es weiterhin in der Console, wenn es mir passt.

Great Cow BASIC v0.98.03 ist erschienen.

Der BASIC Compiler hat erhebliche Änderungen erfahren, die man anhand der kleinen Suffix Erhöhung auf 03 gar nicht vermuten würde.

Das Komplettpaket enthält Demos und sieben Mikroprozessor-Programmierer.

(einschließlich der Kommandozeilen- und GUI-Tools für den Microchip Pickit 2 & 3) für Mikrochip- und AVR-Mikroprozessoren.)

Die Version enthält den oben gezeigten vollständigen Build, einen minimalen Build, einen Core-Build, einen GCGB-Build, MacOS, BSD Linux und einen Standard-Linux-Build.
 

Diese Version führt viele neue Funktionen wie folgt ein, lest  die Release-Information für detailierte komplette Beschreibungen, da es fast 50 Änderungen in dieser Version gibt.

Compiler
- Weitere Leistungssteigerungen - der Compiler ist schneller. (Auf meinem Linux Rechner ziemlich genau doppelt so schnell)
- Verbesserte Oszillatorunterstützung
- Korrekturen und Änderungen zur Verbesserung der Stabilität

Gerätedateien
- Neue Device Treiber hinzugefügt
- Alle Geräte Libraries wurden aktualisiert, um neue Funktionen zu unterstützen: HEFSAF, ADC und Speicher

Hilfe
- Aktualisiert für neue Fähigkeiten und Verbesserungen

GLCD
- Nextionsunterstützung
- ILI9326 Unterstützung

PWM
- Neuer flexibler Ansatz für CCP/PWM

LCD
- Neue 3-Dreileiter-Lösung

USB
- Neue USB-Funktionen eingeführt

RTCC
- Verbesserte Microchip RTCC-Unterstützung

Speicher
- HEF- und SAF-Unterstützung

Unterstützung von Betriebssystemen hinzugefügt
- Mac OS
- FreeBSD

Programmierer
- CuriousLoader hinzugefügt
- Verbesserte Benutzerfreundlichkeit

Bibliotheken
- Neue PCA9685
- Aktualisiert MCP 23017

CLC Designer
- Verbessert für die Unterstützung von mehr Geräten

PPSTool
- Erhebliche Verbesserung zur Unterstützung von 18FxxK42 I2C
- Farbkennzeichnung für den verwendeten Port
- Neuestes Gerät XML v1.75

Tipps und Tricks
Die bisherigen Tipps und Tricks sind noch sehr gut. Siehe https://sourceforge.net/p/gcbasic/discussion/579125/thread/7fae77a3/

Viel Erfolg mit der neuen Great Cow BASIC Version!

Bitte beachten:

Bitte keine Dateien aus dem Release v0.98.03 mit einer anderen Version von Great Cow BASIC vor v0.98.03 selektiv verwenden.

Bitte halte also die Version in Bezug auf den Build konsistent.

Wenn du das Build für deine eigenen Bedürfnisse anpasst, dann gibt es viele Methoden, um das Build konsistent zu halten und es dir zu ermöglichen, es anzupassen - es gibt Beiträge im Forum, wie du dies erreichen kannst.

Zum Download

Kleiner Hinweis für die Unixoiden User: Ursprünglich wurde GCBASIC unter Windows entwickelt, dort ist Groß Kleinschreibung kein Thema in Pfadangaben. Im Laufe der Zeit ist die User Gemeinde, und damit auch die Zahl der Mitwirkenden aus dem Unixoiden Umfeld angestiegen, was immer mehr zu Verwirrungen bei z.B. den Includes führen konnte. Nichts, was einem nun wirklich den Nutzen von Great Cow BASIC verringern würde, aber mehr Spaß hat man nunmal ohne Mixed Case.

Deshalb wurde das Projekt in einem Kraftakt auf einheitlich Groß Kleinschreibung geändert. Daher ist die endgültige Unixoid Build Version ein paar Tage hinterher. Anfang Dezember wird die bereinigte Version für die Unixoiden fertig sein.

Ps: Unixoid meint hier Mac OS, FreeBSD und Linux als Sammelbegriff. Evtl. würde es auch für die anderen Unix Plattformen funktionieren, das ist aber nicht getestet worden

Nur mal kurz angemerkt.

Bisher war das updaten von owncloud eine Plage --, möglich, aber halt aufwändig.

Nun, mit ownCloud 10.0.9 (stable) ist das Geschichte! Den neuen Release.key musste ich noch aktualisieren und nun funktionierte es.

Unmittelbar danach sollte man seinen ownload Service besuchen und einmal klicken, dann läuft das update.

(Klar, geht auch auf der Console, hatte halt gucken wollen, ob der Service down ist, war er aber nicht )

Schön.

Nein, keine stärkere Feder, oder stärkere Akkus, sondern eine kleine elektronische Spielerei.

Eingebaut wird der Mod in ein rein mechanisches NERF Scharfschützengewehr Longshot CS-6.

Es wird die verbliebene Munition angezeigt und ein LED Blitz ausgelöst, wenn die Schaumstoff Patrone durch den Lauf geschossen wird.

Umgesetzt wurde das mit Great Cow Basic. Einem Compiler, der Basic frisst und Assembler für PIC und AVR ausspuckt.

Ich habe an anderer Stelle bereits einen Artikel über Great Cow Basic geschrieben und einen Bericht über ein damit realisiertes Projekt angekündigt. Nun, hier kommt der Bericht.

Die Anzeige erfolgt auf einem  128x32 Pixel Display (Suchbegriff I2C SDD1306 0.91 128x32 OLED)

Die Anzeige ist nur ca. 2.31 cm groß, das komplette Display hat ungefähr 3,5cm, damit eignet es sich ideal zum Einbau in das Zielfernrohr.

Funktionsbeschreibung der Software:

Die Bilder sind von einem frühen Prototyp, die Qualität der Bilder bitte ich zu entschuldigen. Von der endgültigen Version werden hoffentlich schärfere nachgereicht. Allerdings hat auch das Grenzen, denn das Display hat nur kleine Abmessungen. In Natura sieht das Display erhelbich besser aus, es ist eine Freude, dieses Display in Aktion zu sehen.

Einschalt Screen

Nach dem Initialisieren wird ein Begrüßungsbildschirm gezeigt, der die aktuelle Spannung des verwendeten Li Ion Akkus anzeigt. Basis der Berechnung ist die Betriebspannung von 5 Volt, welche konstant gehalten wird. In Abhängigleit von der Akkuspannung wird ggfs. ein anderer Text ausgegeben. Bitte beachten.

Man kann nun einfach warten, bis zur Hauptanzeige gewechselt wird, oder aber die UP Taste drücken, um direkt zur Hauptanzeige zu springen.

Main Screen

Die Hauptanzeige zeigt in großen Ziffern die Anzahl der verbliebenen Munition. Rechts daneben ist die Füllstandsanzeige der Akku Spannungsversorgung angezeigt. Wenn die Spannung unter dem Schwellwert von ca. 3V gesunken ist, wechselt der Schriftzug "UP-DOWN->Setup " mit dem Hinweis auf "charge!". Die Funktion ist noch eine Weile sichergestellt, jedoch sollte der Akku bald geladen werden. Wenn die Spannung des Akkus unter 2.5 V gefallen ist, wechselt die Anzeige zu "Alert!". Nun muss unbedingt das System ausgeschaltet und der Akku geladen werden, sonst wird der Akku beschädigt. Im Sourcecode sind die Schwellen individuell einstellbar, so dass man auch Batterien, oder einen anderen Akku Typ verwenden kann und trotzdem etwas von der Kapazitätsanzeige hat

Wenn die verbliebene Munition nur noch 3 Patronen oder weniger beträgt, beginnt die Ziffer zu blinken und die Anzeige in der Helligkeit zu pulsieren.

Nach Wechsel des Magazins (Reed Kontakt Magazin) geht die Anzeige wieder auf den Standardwert von 30.

Die Helligkeit der Anzeige kann mit dem Poti beeinflußt werden. Die Tasten UP und Down dienen zur Bedienung des Einstellmenüs.

Flashtime Screen

Beide Tasten gleichzeitig gedrückt, lassen das Einstell Menü erscheinen. Hier kann mit den Tasten der Flash Timer eingestellt werden, also die Dauer eines Lichtblitzes. Während dieses Einstellmenü gezeigt, wird, kann trotzdem der Trigger betätigt werden, man ist also nicht wehrlos! Der von Links nach Rechts immer länger werdende Balken zeigt die Restzeit an, bis das Menü automatisch verlassen wird.

Rounds Screen

Durch erneutes gleichzeitiges Drücken von UP und Down gelangt man in das Einstellmenü für die Munition

Hier kann man die Anzahl der Patronen einstellen, die beim Magazinwechsel als "Voll" geladen eingestellt werden. Der von Links nach Rechts immer länger werdende Balken zeigt die Restzeit an, bis das Menü automatisch verlassen wird. Wenn man UP und DOWN gleichzeitig drückt, wird die eingestellte Munition dauerhaft gespeichert.

Weitere Beschreibung und auch neue Fotos wie z.B. dieses, auf der englischsprachigen Seite

Nach Pfingsten wird es hoffentlich dort auch endlich ein Action Video geben, vorausgesetzt, die Waffe überlebt den F.A.T.E Con

Ist jetzt keine große Sache, dennoch möchte ich zu (selbst)dokumentarischen Zwecken aufschreiben, welche Einstellungen notwendig sind, um ein bequemes und komfortables Arbeiten zu ermöglichen.

Vorweg gesagt, man kann natürlich mit Hilfe von wine auch die mitgelieferte GCB@Syn IDE benutzen.

Bei mir allerdings führte das zu einer erheblichen (Faktor 10-11) längeren Compile- und Flashzeit. Da ich sowieso nicht der wine Fan bin, habe ich mir mit Geany, der Universal IDE eine Möglichkeit geschaffen. (Nachtrag; vermutlich einer der Gründe ist, dass die GCB@SYN IDE mehrere Tools über die Command.com Schnittstelle auffruft, auch native Windows hat da Performance Einbußen)

Damit beim Laden eines Great Cow BASIC Programmes das Syntax Hilighting aktiviert wird, wie hier gezeigt den Freebasic Eintrag ergänzen. Zur Info, die Syntax von Freebasic ist praktisch identisch zu der von Great Cow BASIC, nur die Spezial Befehle, wie z.B. #chip werden nicht hervorgehoben, aber das kann ich verschmerzen.

Damit man mit F8 und F9 direkt das Compilieren und Flashen lostreten kann, sind die folgenden Einträge notwendig. Bitte beachten, dass eine *.gcb Datei geladen ist und der Tab auch aktiv ist, denn Geany hat für jeden Datei Typ unterschiedliche Werkzeuge.

Die Dritte Zeile hatte ich als ersten Ansatz, hier musste ich immer den PIC Typ anpassen, was nerven kann, wenn man mit zwei oder mehr verschieden Modellen arbeiten will.

Das im Screenshot genannte Programm test-flash.sh habe ich gestrickt, um die #chip Zeile zu finden und dem Java Programm den PIC Typ mitzugeben. Es ist noch in einem experimentellen Stadium, scheint aber einigermassen zu funktionieren. Fehlerhinweisen werde ich natürlich möglichst zeitnah nachgehen.

Ein dritter, nicht ganz so kritischer Punkt ist das reformatieren vom Quellcode. Dafür bietet Geany eine universelle Schnittstelle nämlich das senden einer Auswahl an ein externes Programm. Ich habe mich für FBeauty entschieden. Es ist ein in Freebasic geschriebenes Programm, welches das reformatieren durchführt. Da der FreeBasic Compiler ohnehin installiert werden muss um den nativen Great Cow BASIC Compiler zu compilieren, ist der ohnehin vorhanden, also wirklich kein Ding.

Hier der Quelltext von test-flash.sh

# to set the correct Path to ipecmd.jar execute the following line:
# find /opt -name ipecmd.jar
# this will print out one or more lines, choose the one you want use
# and edit the next line
IPECMD="/opt/microchip/mplabx/v4.05/mplab_ipe/ipecmd.jar"
# simple test for Typo
if [ -e "$IPECMD" ]
then 
    # finding the filename
    BASENAME="$(basename $1)"
    GCBNAME="$(echo $BASENAME|cut -f1 -d.)"
    #echo "Basic Source=$GCBNAME.gcb"
    BASICFILE="$(dirname $1)/$GCBNAME.gcb"
    CHIPLINE="$(grep -i '#chip ' $BASICFILE)"
    TARGET="$(echo $CHIPLINE|sed 's/#chip//I' |sed 's/ \+//g'|cut -d, -f1)"
    echo "Flashing Target:$TARGET"
    echo "using java -jar $IPECMD -TPPK3 -P$TARGET -M -F\"$1\""
    java -jar $IPECMD -TPPK3 -P$TARGET -M -F"$1"
else
    echo "$IPECMD was not found"
fi

test-flash.sh (oder unter einem besser passenden namen) an eine beliebige Stelle kopieren, ausführbar machen und den Pfad wie oben gezeigt in Geany eintragen.

Wer das IPECMD in einer anderen Version und oder an einer anderen Stelle installiert hat, muß die erste Zeile natürlich anpassen.

Hör ich hier jemanden lachen und sagen: "Jetzt macht der Kerl was mit Basic, sowas unprofessionelles, kann er es ja gleich mit Arduino machen!"?

Ich gebe zu, mit Arduino noch nie in Berührung gekommen zu sein, deshalb liegt mir fern mich dazu zu äußern. Eine ähnliche Geschichte ist allerdings energia für msp430, das habe ich genutzt und mit C verglichen. energia ist schön einfach, hat aber auch Overhead, der sich direkt auf die runtime des Projektes auswirkt.

Ich bin eigentlich seit dem C64 kein Basic Fan mehr, aber unbestritten ist, dass es ähnlich wie mit Fahrrad fahren ist. Einmal gelernt, verlernt man es nicht.

Warum ausgerechnet Great Cow BASIC? Hier fiel mir beim ersten Testprogramm gleich das kleine erzeugte HEX File auf. Der Compiler vergleicht sich selbst direkt mit Assembler, nicht mit anderen Compilern, da steht dann folgendes.

Great Cow Basic hat drei Hauptziele.

• Die Notwendigkeit sich wiederholende Assembler Befehlssequenzen zu vermeiden,
• effizienten Code zu produzieren und um es einfach zu machen Code, der für einen Chip-Typ geschrieben wurde, auf einen anderen Chip-Typ auszuführen.
• Es verbirgt viele der verwirrenderen Teile der Mikrocontroller-Programmierung, so dass es für Anfänger geeignet ist und diejenigen, die Assembler nicht mögen, oder die Assembler-Sprache lernen möchten.

Zitat von Evan, einem der Entwickler:

Die Leute glauben nicht, dass BASIC optimierten Code produzieren kann.
Aber jede Sprache für einen Compiler ist die reine Digitalisierung von
Wissen und Einsichten von den Menschen, die den Compiler erschaffen.

Ich bin jedenfalls sehr positiv überrascht, über die riesige Auswahl an schlüsselfertigen Lösungen, im Great cow Basic Jargon Demos genannt.

Zusätzlich gibt es eine Top aktuelle, gut gepflegte Sammlung unter https://github.com/Anobium/Great-Cow-BASIC-Demonstration-Sources/

Die Liste der unterstützen Hardware, also Displays, Sensoren, RTC , eeproms usw. ist hier beeindruckend. Wer sich ernsthaft mit dem Programmieren von Controllern beschäftigen möchte, sollte definitiv einen Blick auf Great Cow Basic werfen!

Für Windows gibt es eine beeindruckende IDE mit allem möglichen an integrierten tools, z.B. auch für unterschiedliche Programmer.

Es gibt einen Apple Port und natürlich ebenfalls einen Linux Build. Hier muss man sich eine eigene IDE schnappen und mal ein wenig anpassen, das ist im Falle von Geany aber wirklich einfach. Ich nutze Geany und bin damit sehr glücklich bis jetzt.

In der Vergangenheit gab es auch Portierungen der Windows Ide nach Linux, die habe ich mir jetzt nicht angesehen, weil die scheinbar nicht mehr weiter gepflegt wurden.

Meine eigenen Gehversuche habe ich übrigens mit StartPIC18 gemacht, wer das auch möchte, kann mich gerne nach einer Platine fragen, noch habe ich ein paar davon übrig.

Ich habe mit Great Cow BASIC ein erstes Projekt umgesetzt, welches ich in Kürze hier vorstelle.

Richtige Fallen gab es gar nicht, kleinere Schwierigkeiten liessen sich im Forum schnell klären, davon ab ist das Hilfesystem wirklich glänzend und immer auf dem neuesten Stand. (Im installierten Build ist ebenfalls viel an Dokumentationen enthalten.)

Das ist für ein Opensource Projekt gar nicht so selbstverständlich, oftmals leiden geniale Tools an einer aktuellen und ausführlichen Dokumentation

Für weitere kleine Projekte habe ich bereits konkrete Ideen.

Ich hoffe, ich habe bei dem Einen oder Anderen das Interesse geweckt.

Glest habe ich vor gefühlt 250 Jahren mal aus den Quellen übersetzt und ausprobiert, wenn ich mich richtig entsinne, war das damals eine arge Enttäuschung, weil das Game nicht an die Warcraft Reihe heran kam. Irgendwie habe ich es aus den Augen verloren, vielleicht gabe es zu der Zeit auch einfach andere Dinge.

Nun sind viele Jahre vergangen, Glest ist praktisch tot, aber ein Spinoff --MegaGlest-- hat seit 2012 die Bühne betreten und eine Qualität erreicht, die mich übermannt hat.

Heute (2017-01-21 19:12 ) bin ich zufällig darüber gestolpert und habe mir megaglest aus dem Debian Repository installiert und angespielt.

Ich möchte mich hier in aller Form bei den Mitwirkenden, also nicht nur den Entwicklern bedanken, dass sie am Ball geblieben sind.

Bei Wikipedia gibt es einen schönen Artikel über MegaGlest, deshalb will ich hier nicht noch ein Plagiat veröffentlichen, sondern den geneigten Leser zum Wikipedia Artikel leiten.

Für mich die ins Auge springenden Features die Zoomfähigkeit, dadurch kommen die liebevoll gemachten Animationen der Charaktere schön zur Geltung.

Ps: Warum ich das erst heute veröffentliche? Weil ich nicht bemerkt hatte, dass der Titel noch auf Entwurf stand

Vielleicht habe ich schon mal erwähnt, das ich beruflich viel mit Solaris zu tun habe? Nein? Na, macht nichts. Solaris hat im professionellen Umfeld einen guten Ruf. Nicht zu unrecht, wie ich finde. Beispielsweise ist das Filesystem ZFS sehr fortschrittlich, es hat viele features, die Linux Dateisystemen noch fehlt. ZFS selbst kann man nur mit Klimmzügen ala fuse unter Linux verwenden, nimmt es nicht Wunder, das Open Solaris mit seinem ZFS seine treue Fan Gemeinde hat. Durch die Unruhen, die seinerzeit durch den Kauf von sun durch Oracle losbrachen, wurde es stiller um Open Solaris. Nun das heißt nich, es gebe es nicht mehr. Gerade gestern bin ich über OpenIndiana gefallen und habe mir die Live Desktop Version Build 151a7 von http://openindiana.org geladen und auf einen USB Stick mit usb Header kopiert. Die Anleitung dazu ist auf der Homepage verlinkt, der Äbersicht halber hier der korrekte dd Aufruf.

cat 1G.header oi-dev-151a7-live-x86.usb |dd  bs=1024k of=/dev/sdc

OpenIndiana ist ein OpenSolaris mit einem Kernel von der Non-Profit Firma Illumos. Die Screenshots stammen vom ersten Ausprobieren auf meinem Lenovo T500. Was ich schon sehr erstaunlich finde, das so gut wie jede Hardwarekomponente ohne Probleme erkannt worden ist.Sogar die essentiellen Fn Tasten für Bildschirmhelligkeit und Leselampe gehen sofort. Ich habe jetzt nicht probiert, ob sogar suspend to Disk und to Ram gehen würde, ich denke, das ist auch unerheblich. Noch ist der vom Oktober 12 stammende Build nicht als Stable gekennzeichnet, macht aber einen sehr guten Eindruck. Zum Beispiel gefällt, dass das abgebildete Gerätetreiber Dienstprogramm eine komplette Hilfebeschreibung hat, also nicht nur leere Texthülsen mit allgemeinem Blabla.

Ich werde versuchen herauszubekommen, wie aktiv die Entwicklung ist, denn das erklärte Ziel von OpenIndiana ist die stable Version "Production ready" zu machen. Mit Security updates usw. Ich spiele mit dem Gedanken unseren Rootserver auf OpenIndiana umzustellen.

Da ein neuer Rootserver demnächst eh geplant ist, käme es auf den Versuch an.

Haben die Zockertownleser bereits Erfahrungen mit OpenSolaris Derivaten?

Auf die Gefahr hin, nicht der einzige in den Planets zu sein, will ich dennoch zum heutigen Release von Squeeze gratulieren. Noch ist es auf debian.org nicht zu lesen, auf identi.ca/debian kann man es aber live mitverfolgen.

Ich möchte mich bei den Debian Membern und der gesamten Community dafür bedanken. Es wird eine großartige Version!

Zu debian.org bräuchte ich ja wohl nicht verlinken? Aber vielleicht zu den Upgrade Hinweisen