Posts by mgroeber

    Übrigens: ich habe unter https://mgroeber9110.github.io/just-the-docs-test/ eine Testversion für Verbesserungen an der Dokumentation aufgesetzt. Im Moment sieht es noch ziemlich ähnlich aus, verwendet intern aber schon die aktuellen Versionen von jekyll und just-the-docs für die Konvertierung. Mein Plan ist, da erst mal Verbesserungen zu testen und dann in wenigen PRs zu sammeln.

    Der Inhalt ist evtl. veraltet, weil ich einen früheren Schnappschuss der Markdown-Files verwende - es geht hier nur um das Format der Webseite, Suchfunktion usw. Ein paar Sachen, die mir aufgefallen sind und die ich mir gerade ansehe:

    • Das Laden großer Seiten friert bei mir für eine Sekunden ein, wenn man zu schnell scrollt, weil im Hintergrund erst mal die Suchfunktion den Index aufbaut. Leider passiert das bei jeder Seite neu. Dafür habe ich auch schon ein Issue bei just-the-docs geschrieben: https://github.com/just-the-docs/just-the-docs/issues/1396
    • Suche nach Stichworten führt immer zum Anfang des Dokuments, anstatt zur Zwischenüberschrift des Kapitels mit dem Begriff.
    • Sortierreihenfolge in der Übersicht stimmt nicht für alle Kapitel, weil lexikalisch und nicht numerisch sortiert wird (1, 10, 11, 2).

    Ich sehe das auch so, dass auf die Dauer nur eine Version der Doku "von Hand" gepflegt werden sollte (vermutlich am besten Markdown), und die HTML-Doku dann regelmäßig automatisch daraus erzeugt wird. Bevor wir sie überschreiben, sollten wir aber vielleicht noch mal vergleichen, was drinsteht. Dass man die HTML-Variante sogar direkt in Geos lesen kann, ist natürlich ein Argument dafür, das Format beizubehalten (mit minimalem CSS).

    Die Text-Version ist m.E. vermutlich auf Dauer ganz obsolet (weil MD ja sogar im Editor fast so gut lesbar ist wie plain text, bis auf ein paar Sonderzeichen) - wenn wir auch sicher sein können, dass es dort nicht noch Infos gibt, die wir nicht in Markdown haben.

    Ich habe jetzt erst mal ein Issue bei just-the-docs geschrieben, da der Fehler wohl auch in der aktuellen 0.10 noch drin ist: https://github.com/just-the-docs/just-the-docs/issues/1634 - mal sehen, was die schreiben, oder ob da vielleicht sogar eine Idee dahinter steckt (h4 wird in Großbuchstaben umgewandelt, daher könnte jemand eine etwas kleine Schrift durchaus für typographisch sinnvoll gehalten haben...). Ich find's aber auch zu klein.

    Das Problem mit den Unterstrichen ist vermutlich eine Regression von diesem Fix: https://github.com/bluewaysw/pcgeos/pull/756

    Da hatte ich die HTML-Aufzählungen so geändert, dass die Zahl (oder der Punkt) genau die gleichen Zeichenattribute verwendet wie der Rest des Eintrags. Das ist vermutlich bei Farben, Fettdruck, Schriftart auch ganz sinnvoll, aber vermutlich sollte man Unterstreichungen da abschalten. wenn es andere Browser auch so machen.

    Ich habe neulich mal in den Source geguckt und festgestellt dass die über große Strecken "malloc" genutzt haben, die Speicherverwaltung ist nur so halbherzig auf GEOS angpeasst. Da wäre also noch Luft nach oben....

    Ein Kandidat wäre https://github.com/bluewaysw/pcgeos/issues/757 - die Inflate-komprimierten Streams (Zip-Kompression) stattdessen per zlib zu implementieren, wo du ja schon ein paar Verbesserungen an der Speicherverwaltung gemacht hast. Es gibt natürlich noch eine Menge anderer mallox-Sachen (z.B. ein großes Array von Font -Informationen, wenn ich mich richtig erinnere), aber eine einheitliche Library für das Auspacken wäre schon mal was.

    Mal so ein Gedanke: wie wäre es, wenn wir im Standard-Paket von Ensemble nicht die Blueway-Seite direkt als Homepage einstellen, sondern stattdessen auf eine lokale Datei verweisen, die dann Links zu Blueway, Infobase und vielleicht ein paar anderen Seiten liefert, die gut mit dem Browser funktionieren?

    Außerdem könnte die Seite vielleicht ein paar Browser-Features unaufdringlich demonstrieren, z.B. eine Grafik laden und ein Tabellenlayout mit verschiedenen Schriften, Aufzählungen usw.

    Damit hätte ein Nutzer auch ein kleines Erfolgserlebnis, wenn die Verbindung zum Internet noch nicht hergestellt ist.

    Die Seite müsste natürlich auch übersetzt werden.

    ciao marcus

    Aber zunächst sollte die Programmoberfläche vernünftig eingedeutscht werden.

    Da wäre die interessante Frage, wie viel da überhaupt an der deutschen Übersetzung geändert werden muss, und wie weit ResEdit die Objekte immer noch findet, so lange sie ihre Namen behalten haben - ich vermute, die meisten Texte dürften ja ziemlich ähnlich sein, und nur die Verteilung auf die Resourcen ist vielleicht etwas anders geworden. So wie ich mich dunkel erinnere, müsste ResEdit da eigentlich relativ robust sein.

    Soweit ich das auf die Schnelle bei https://mgroeber.de/geos-live_d.html sehe, sind die meisten Übersetzungen wohl schon vorhanden, bis auf das Optionen-Menü, sowie eigenartigerweise der Titel des "Page Setup"-Dialogs und "HTML > Save Source Code".

    Die Datei gehört nicht ins Build, weil sie bei jeder Änderung von Strings im Code neu erzeugt werden muß, damit alles richtig funktioniert. Das würde implizit einen GEOS-Boot im Buildprozeß erfordern.

    Ich dachte, dass wir den sowieso schon haben, um die übersetzten (deutschen) Resourcen in die compilierten .geo-Files zu integrieren. Oder habe ich das falsch in Erinnerung, und das geht auch mit der Kommandozeile unter Windows/Linux?

    Im Prinzip wäre ein Build-Prozess, der GEOS nutzen kann, natürlich eine feine Sache, weil wir damit die Möglichkeit hätten, komplexe plattformspezifische Dateiformate viel leichter dynamisch zu erzeugen (sagen wir mal, übersetzte Hilfedateien aus einem textbasierten Quellformat, das sich viel leichter in git verwalten ließe als die aktuellen Binärdateien).

    Ich muss leider für das Treffen am Wochenende absagen. Ich hab mir eine Erkältung eingefangen (oder Corona?) und bin wohl nicht fit genug für die Anreise. Außerdem möchte ich ja keinen anstecken...

    Ich habe morgen aber Urlaub genommen, dann kann ich vielleicht live bei dem einen oder anderen Vortrag dabei ein, und auch ein bisschen weiter am Browser programmieren (eigentlich hätte ich ja Lust auf PNG und SVG, aber ich weiß nicht, wie weit ich da komme). Discord behalte ich natürlich auch im Auge.

    Allen die kommen: viel Spaß!

    Der Admin erscheint wieder. Da werde ich wohl doch noch einen weiteren Schadcode irgendwo haben. Mist.

    Ärgerlich. Ich habe hier noch einen Tip gefunden, nach dem es wohl möglich ist, Plugins in WP zu verstecken (und auch von der Umleitung per WP Lite genutzt wird): https://wordpress.org/support/topic/wpcode-hidden/

    Angeblich soll es möglich sein, durch Anhängen von ?wpcode-safe-mode=1 an die Admin-URL alle Plugins zeitweise auszuschalten und dadurch das Verstecken verhindern. Vielleicht sieht man dann mehr...

    Was genau sollte ich jetzt machen? Ein neues anderes CMS installieren?

    Theoretisch könnte man versuchen, mal die Schritte bei https://blog.sucuri.net/2022/02/how-to…irect-hack.html durchzugehen und zu sehen, ob man ob den Konfigurationsdateien oder im Thema die Infektion findet.

    Ich bin kein WP-Admin-Spezialist, aber ich würde vermuten, dass irgendeine WP-Komponente veraltet ist und eine Sicherheitslücke enthält, durch die der Angreifer ein Skript auf dem Server einfügen konnte, vielleicht sogar durch anlegen eines eigenen Admin-Accounts. Dass es gleichzeitig mit dem Zertifikatsproblem angefangen hat, kann ich mir im Moment auch nicht so ganz erklären.

    Vermutlich müsste man da mal sämtliche Updates machen, oder notfalls das WP komplett neu und aktuell aufspielen.

    Firefox:

    Ich habe den "kleinen Roboter" auf http://www.rockytrails.top gerade auch bekommen, als ich https://moellerjaner.de/ aufgerufen habe - aber jetzt beim zweiten Mal kommt die Seite von Johannes. Ich hatte die Seite vorher lange nicht besucht, daher ist die alte Version ziemlich sicher nicht aus meinem Cache gekommen.

    Auf den ersten Blick sieht der Quellcode der Webseite selbst "sauber" aus (also nicht einfach ein eingefügtes JavaScript in der Seite selbst).

    Auch nach dem Löschen aktueller Cookies komme ich ganz normal auf Johannes' Seite.

    Firefox (privates Fenster):

    Sofort originale Seite von Johannes.

    Edge:

    Sofort originale Seite von Johannes.

    Chrome:

    Sofort originale Seite von Johannes.

    Firefox vom Handy (über Mobilfunknetz):

    1. Versuch: kleiner Roboter

    2. Versuch: Seite von Johannes

    Mein Verdacht ist, dass es eine Infektion auf der Serverseite ist, wobei sich der Schadcode die IP-Adressen merkt, so dass jeder Anwender normalerweise die umgeleitetete Seite nur einmal sieht.

    Auf den ersten Blick sieht es ungefähr so aus wie hier beschrieben: https://blog.sucuri.net/2022/02/how-to…irect-hack.html

    Have I got right? Is it possible to install WebOne in the host computee, for example a Windows, Mac, or Linux PC, and then run Geos in Basebox, and utilize the WebOne proxy in Geos, when browsing the internet?

    Yes, this works. I just tried it - add 127.0.0.1:8080 as proxy server in WebMagick (needs a restart), run WebOne in the background, and things like UTF-8 get transparently converted.

    I think I had to add

    OnHeader=.* WebMagick

    to the [Edit] section for the PNG->GIF conversion of the webone.conf file in order to get graphics fixed.

    I found that using WebOne needs this commit to FreeGEOS to properly deal with "304 not modified" cache responses, otherwise many pages will try to download (as files) rather than display because of an incorrect mime type. This is not yet merged to the current web development branch.

    Meinst du damit, dass es sinnvoll wäre, WebMagick mit einem Modus zu versehen, der Seiten grundsätzlich aus der Wayback Machine holt, soweit verfügbar, so dass man mit einem Internet von, sage wir, 2001 browsen kann? Das würde ein realistisches Bild vom Verhalten auf typischen Seiten von "damals" erlauben.

    Ich glaube WebOne Proxy hat auch so ein Feature. Aber wenn es der Browser nativ unterstützt, könnte man es direkt auf originaler Hardware nutzen.