[archimedes] Re: NetFetch 5.50 (inc Hermes 5.50) released

  • From: Alexander Ausserstorfer <bavariasound@xxxxxxxxxxxxxxx>
  • To: archimedes@xxxxxxxxxxxxx
  • Date: Sun, 05 May 2019 15:46:10 +0100

In message <bf6845af57.Thomas@tms_netz.vodafonemail.de>
          Thomas Milius <Thomas-Milius@xxxxxxxxxxxxxxx> wrote:

In message <84d246af57.Alex@xxxxxxxxxx>
         Alexander Ausserstorfer <bavariasound@xxxxxxxxxxxxxxx> wrote:

In message <0c1d46af57.Alex@xxxxxxxxxx>
          Alexander Ausserstorfer <bavariasound@xxxxxxxxxxxxxxx> wrote:

[Geringe Dateigröße von AcornSSL]

Woher kommt dieser gewaltige Unterschied? Vielleicht hat man bei
AcornSSL viel altes fallen gelassen. Kann ich mir aber nicht recht
vorstellen, weil damit die Kompatibilität eingeschränkt wäre.

Ja, ist so:

https://de.wikipedia.org/wiki/Mbed_TLS

Ich hätte gleich nachschauen sollen.

Die Bibliothek baut scheinbar auf keine anderen Bibliotheken auf und ist
deshalb auch so einfach portierbar. Bei z. B. GnuTLS hat man das
Problem, dass die Bibliothek GnuTLS  auf vielen weiteren Bibliotheken
aufbaut, also diese einbindet, weshalb eine Portierung von Hand auch
sehr, sehr aufwändig wird. Einen Mechanismus, der sowas automatisch
macht, gibt es scheinbar leider nicht - zumindest nicht für ein
RISC-OS-Modul. Ich war bisher jedenfalls nicht dazu in der Lage.

Klar hast Du recht, da man die diversen Altentwicklungen gekappt hat, da
sie auch sonst nicht mehr unterstützt werden, ist das Ganze deutlich
geworden.

Allerdings solltest Du nicht vergessen, daß der Norcroft C/C++ meinen
Erfahrungen nach einen deutlichen kompakteren Code erzeugt als GNU C/C++.
GNU C/C++ ist letztlich ein Intel X86 optimierter Compiler an die anderen
Architekturen drangeflanscht wurden.

Kann durchaus sein. Ich habe mich oft über die Größe von C-Programmen
gewundert. Vielleicht liegt es auch daran. Ich sollte wohl die beiden
Compiler hier bei mir mal direkt miteinander vergleichen.

Was Portierung angeht, so wird das immer ein Problem bleiben, allerdings
könnte man evt. das eine oder andere tun, um einmal erfolgte Portierungen
bei Aktualisierungen der Quelle deutlich zu erleichtern. Ein anderer aber
auch nicht unproblematischer Weg ist es natürlich die ganzen
Basisbibliotheken für RISC OS zu portieren. Da erleichtert die Portierungen
immens, aber man bekommt an anderer Stelle Probleme.

Das war auch der Grund, warum ich irgendwann damit aufgehört habe. Weil
einfach alles Mist ist. Es bleibt 'ne Bastlerei, die zwar 'mal
kurzfristig gehen mag, aber was Gescheites wird das ned. Allenfalls kann
man noch kleine Anpassungen machen.

Der GCC (Compiler) müsste halt in der Lage sein, aus komplexen
C-Bibliotheken RISC-OS-Module zu machen. Aber genau das funktioniert
halt leider nicht.

Bei Webbrowsern bleibt bei Portierungen z. B. das Problem der
Oberfläche: Die Funktionalität der Oberfläche von RISC OS kann man nicht
mitportieren, weil die auf anderen Systemen so ja gar nicht vorhanden
ist. Und auch die Verzahnung der Programme wie unter RISC OS
normalerweise üblich (Datenaustausch per Drag & Drop usw.) dürfte mit
einer einfachen Portierung kaum machbar sein. Das wird also nichts
Gescheites werden.

Zumal es auf anderen Systemen inzwischen ja auch nicht mehr gescheit
funktioniert. Gestern ist mir beim Arbeiten mit Firefox mein Eee PC
unter Windows 7 gleich dermaßen abgestürzt, dass ich ihn reseten durfte.
Da ging nix mehr.

Auf dem Gemini-PDA gibt es das Problem des quergestellen Bildschirms.
Bei einigen Webseiten kommt man unter Umständen nicht mehr an die
Bedienelemente ran, weil die nicht mehr auf dem Schirm sind. So ist das
halt, wenn etwas aus der Reihe tanzt.

Die Webbrowser sind zudem untereinander nicht unbedingt kompatibel. Die
eine Seite funktioniert dann zwar unter Webbrowser A ordentlich, aber
nicht unter Webbrowser B. (Microsoft versucht eh ständig, eigene
Standards zu kreiirren, damit es ja nur noch auf "ihrem" System läuft
und damit die Anwender an sich bindet, also Abhängigkeiten schafft.)

Es macht auch keinen Spaß, mit der Maus eine Oberfläche bedienen zu
müssen, die für einen Touchscreen gemacht worden ist. Im letzteren Fall
wird nämlich unheimlich Fläche verbraten. Anders herum gilt das aber
natürlich genauso. Das ist einfach alles Murks.

Stellt sich mir noch die Frage, unter welchem Copyright das
AcornSSL-Modul eigentlich liegt. rComp verkauft "ihr" Update mit 15 GBP.
Und angesichts der deutlich eingeschränkten Funktionalität gegenüber z.
B. GnuTLS bin ich da ehrlich gesagt schon entsetzt. Nur eine andere
Routine aufzurufen, nämlich die von AcornSSL und nicht mehr die von
SecureSockets - das kann es doch wohl nicht sein?

Im Übrigen sehe ich es heute so, dass die Firmen gar nichts Gescheites
mehr an Software liefern wollen. Eine anständige Oberfläche zu
programmieren, mit der ein Anwender wirklich effektiv arbeiten könnte,
kostet ja schließlich Mühe, Zeit und Geld. Und einwandfrei funktionieren
soll die Software ja schließlich auch nicht. Viel lieber verkaufen die
irgendeinen komplizierten, umständlichen Mist und sahnen dann noch
zusätzlich mit "Support" und Schulungen ab. Und die Leute fallen drauf
rein, weil sie keine Ahnung haben. Jedenfalls glauben sie anscheinend
diesen ganzen Mist.

Aber daran kann man wohl nichts ändern.

Acorn jedenfalls war seinerzeit sehr innovativ, als sie darangingen und
quasi aus dem nichts ein völlig neues System schufen (eigener Prozessor,
eigenes Betriebssystem). Nur übriggeblieben ist davon halt nichts, wie
wir alle wissen.

Ciao,

Alex

-- 
http://home.chiemgau-net.de/ausserstorfer/
Menschen machen Fehler. Computer auch.


Other related posts: