[archimedes] Re: Evt. Hackproblem
- From: Alexander Ausserstorfer <bavariasound@xxxxxxxxxxxxxxx>
- To: archimedes@xxxxxxxxxxxxx
- Date: Tue, 28 May 2019 17:44:19 +0200
In message <588386658.522011.1559040508695@xxxxxxxxxxxxxxxxxxxxxx>
Steffen Huber <steffen@xxxxxxxxxxxx> wrote:
Alexander Ausserstorfer <bavariasound@xxxxxxxxxxxxxxx> hat am 27. Mai
2019 um 19:20 geschrieben:
Vor allem aber editiere ich viele Nachrichten nachträglich nochmals
mittels StrongEd. Kann StrongEd Unicode? Ich denke nicht. Jedenfalls
habe ich hier dann die komischten Zeichen auf dem Schirm. Könnte man
StrongEd ohne weiteres Unicode beibringen? Ich habe mich mit dem noch
nicht näher beschäftigt.
StrongEd ist nicht Unicde-fähig. Das Feature steht nicht mal auf der
offiziellen Wish List. Und es wäre ziemlich komplex, das dazuzubauen,
wenn ich eine Diskussion mit Fred richtig erinnere. Vor allem hat man
natürlich auch das übliche Font-Problem - man müsste sich auf die
"üblichen" ISO8859-Zeichen beschränken, und dann kann man gleich mit
diesem Encoding arbeiten.
Was ich bisher von den Unicode-"Fähigkeiten" von Messenger gehört
habe, muss zwingend der integrierte Editor verwendet werden.
Ich hatte zwar Unicode bei MessengerPro 8 abgeschaltet. Wenn ich die
bereits von MessengerPro "abgeschickten", also in der Schlange
befindlichen Nachrichten nochmals mittels !StrongEd nacharbeite, sind im
Nachrichtentext leider wieder jeweils zwei komische Zeichen statt der
Umlaute und dem scharfen S zu sehen (StrongEd_ohne_UTF8.jpg).
Wenn ich Unicode anschalte, sind beim Nacheditieren mittels StrongEd
zwar die Umlaute im Nachrichtentext sehbar. Dafür stimmen aber die
Zeichen in der Betreffzeile (Subject:) nicht.
Mit dem internen Editor ist es jedoch nur wenig besser:
Ist Unicode angeschaltet, scheint alles in Ordnung zu sein
(Edit_mit_UTF8/jpg). Ist Unicode abgeschaltet, werden jedoch die Umlaute
in der Betreffzeile falsch angezeigt (Edit_ohne_UTF8/jpg).
Ich weiß auch nicht, wie das gelöst worden ist. Vielleicht ist es so:
Der Editor, egal ob StrongEd oder der interne, erzeugen normale Umlaute
nach irgendeinem erweiterten ASCII-Standard. Nach dem "Absenden"
übersetzt MessengerPro dann die Sonderzeichen ins Unicode.
Wenn man jetzt die E-Mail nochmal nacharbeiten möchte, nachdem sie
bereits von MessengerPro für !Hermes, !POPStar usw. zum Verschicken
abgelegt wurde, hat man natürlich ein Problem. Das ist so blöd.
Auf jeden Fall funktioniert es nicht.
Ich für meinen Teil bin daher wieder zu MessengerPro 6 zurückgegangen.
Eigentlich wollte ich wie vorher auf dem RPI MessengerPro 5.13
verwenden. Dies hatte hier auf dem Titanium jedoch Probleme gemacht.
Nicht umsonst verwende ich seit langem einen schäbigen Webmailer,
um dieser Misere zu entgehen.
Das kann es wohl auch nicht sein. Insbesondere, weil man dann wohl
Javascript bräuchte und online arbeiten muss und solch ein Scheiß. Dann
braucht man wegen dem Webbrowser ein Fremdsystem. Und was können die
Webmailer schon großartig? Deine E-Mails müssen dann alle auf einem
fremden Computer bleiben, der ständig am Netz hängt. Würde ich so nicht
wollen. Und Unicode braucht eh kein Mensch.
Natürlich hat !MessengerPro auch so seine Probleme. Insbesondere mit der
richtigen Zeichenkodierung (nach Standards). Aber insgesamt gesehen
empfinde ich das Programm noch immer als eines der besten. Insbesondere
bei dieser kleinen Größe von gerade mal einigen MB. Damit lässt sich
effektiv arbeiten.
Da sind z. B. die E-Mail-Programme unter Android wesentlich größer. Und
dann kann man mit denen nicht einmal offline arbeiten. Fast immer kann
man nur online die E-Mails abrufen und beantworten. Das System speichert
die E-Mails aber nicht dauerhaft auf dem Gerät. Sowas ist ein Witz. Ein
totaler Rückschritt. Da konnte Messenger auf unserem System vor 20
Jahren schon wesentlich mehr.
Mit Thunderbird am Usenet teilzunehmen, das war hier auch so ein Thema.
Thunderbird lädt normalerweise immer nur den Kopf einer News herunter.
Wenn man dann die Nachricht lesen möchte, versucht das Programm ein
jedes Mal eine Verbindung zum Newsserver aufzubauen, um den Rest der
Nachricht herunterzuladen.
Das ist natürlich schlecht, wenn man nicht online ist. Und außerdem ist
es bei vielen frei verfügbaren Usenet-Servern so, dass sie nur einige
wenige Verbindungen pro Tag und Anwender zulassen. Man hat nur seine
Probleme damit. Die News unter Thunderbird alle in einem Rutsch komplett
herunterzuladen, das ist möglich, aber sehr umständlich. Und das ein
jedes Mal wieder. Das funktioniert hier unter RISC OS alles wesentlich
besser.
Jedenfalls liegt man nicht richtig, wenn man meint, dass woanders alles
besser ist als unter RISC OS. Das ist meiner Erfahrung nach leider
überhaupt nicht der Fall. Dort zwickt und zwackt es oft genauso. Wenn
auch anders. Man kann es sich also sparen.
WeiÃ? jemand, wie ich GPG wieder zum Laufen kriege? Die SharedUnixLibrary
scheint hier auf dem Titanium nicht mehr zu funktionieren (V1.14) oder
Probleme zu bereiten.
Die aktuelle SharedUnixLibrary macht nach meinem Kenntnisstand
nirgendwo Probleme. Wie äußern die sich bei Dir?
Der Fehler kommt von GnuPG:
*gpg -h
gpg (GnuPG) 1.4.9-sb1
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <
http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Home: ADFS::HardDisc4.$.!BOOT.Resources.!GnuPGUser
Supported algorithms:
Pubkey: RSA, RSA-E, RSA-S, ELG-E, DSA
Cipher: 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH
gpg: signal 11 caught ... exiting
UnixLib detected recursion of signal SIGSEGV. Exiting.
*
Es ist immer diese letzte Zeile bei GnuPG. Egal wo. Keine Ahnung, was
das bedeutet.
Ich denke, dass der Weg unter RISC OS eigentlich nur über den Anwender
ist. Wenn man keine Dienste am Laufen hat. Oder wie soll denn unter
RISC OS sonst jemand über das Netzwerk in den Computer "reinkommen"?
RISC OS macht von sich selbst aus ja schließlich nichts.
Sobald Du mit dem Internet verbunden bist, ist RISC OS höchst
verwundbar. Der IP-Stack stammt von einer uralten BSD-Version mit
vermutlich tausenden von bekannten Verwundbarkeiten. Sobald Pakete
übertragen werden, ist es aus mit der Sicherheit. Zumal unter
RISC OS ja jeder User automatisch Root-Rechte hat und auf der Maschine
alles darf.
Die Frage ist, was passieren kann. Der Rechner kann nur Daten senden und
empfangen. Ein Angriff kann nur über die empfangenen Daten geschehen.
Inwiefern können die bei RISC OS etwas auslösen, was gefährlich wäre?
Das wäre interessant zu wissen. Soweit ich weiß, gibt es keine
Fernsteuerung oder einen Mechanismus unter RISC OS, der empfangene Daten
automatisch startet. Zumindest von Haus aus. Aber ich habe mich bisher
nicht näher damit beschäftigt.
Ciao,
Alex
--
ARM Cortex A15 (Titanium), RISC OS 5.24
http://home.chiemgau-net.de/ausserstorfer/
Attachment:
Edit_mit_UTF8.jpg
Description: JPEG image
Attachment:
Edit_ohne_UTF8.jpg
Description: JPEG image
Attachment:
GnuPG.jpg
Description: JPEG image
Attachment:
StrongEd_mit_UTF8.jpg
Description: JPEG image
Attachment:
StrongEd_ohne_UTF8.jpg
Description: JPEG image
Other related posts:
