[Eisfair] languagetool-Server auf eis

[Kay Martinen]

Am 16.03.26 um 22:03 schrieb Marcus Röckrath:
> Hallo Kay,
> 
> Kay Martinen wrote:
> 
>> ... darf ich hier; bevor das ausufert; erst mal freundlichst auf die
>> m.E. absolute Sinnlosigkeit hinweisen eine Rechtsschreib- und
>> Grammatikprüfung von solch Monströser Größe überhaupt zu benutzen?
> 
> Was spricht gegen ein gestandenes Tool zur Rechtschreib- und
> Grammatikkontrolle?

Ich wäre der erste der dafür plädierte Privates nicht an eine Blackbox 
eines Cloud/internet-dienstes aus zu lagern. Und es wäre vielleicht auch 
gut wenn man neben Libreoffice, Thunderbird o.a. Programmen die manuelle 
Freitext eingabe bieten (welche sonst bräuchte man denn noch?) über eine 
einheitliche API (gibt es die denn - für die o.g.?) im Lokalen Netz zur 
Prüfung und korrektur(vorschläge?) von allen hosts gemeinsam nutzen 
könnte. So wie man ja auch einen datenbank-server einrichten könnte auf 
dem alles läge oder einen spam- und antiviren-server, falls man mehrere 
Mailserver oder hosts hätte die sich damit verbinden könnten.

Das meine Rechtsschreibe nicht immer gut ist weiß ich. Aber die in TB 
integrierte Korrektur finde ich so schlecht nun auch nicht. Da müsste 
ein Dritt-dienst schon mehr bieten um das sinnvoll zu machen.


>> Ich meine: Bei der Gewichtigkeit müßte das "tool" wenigstens 200% Besser
>> sein als ALLES was man sonst so; z.b. in Thunderbird o.a.; dafür findet
>> und noch besser wenn es den Weltfrieden durch umfassende 100%-ige
>> Verständlichkeit sicherte. ;-)
> 
> Es geht doch schlicht darum, statt - teils in Anwendungen voreingestellter
> - externer Prüfung über languagetool.org, diesen lokal zu betreiben, um die
> Datenabwanderung - muss jedes persönliche Geschreibsel für andere lesbar
> sein - zu vermeiden.

Sicher. Datenabwanderung ist ein Problem das man durch Vermeidung und 
Datensparsame Verhalten eindämmen sollte. In So fern sinnvoll einen 
lokalen Dienst zu haben. Auch auf EISFAIR wenn möglich. Offenbar ist 
aber genau das wg. der Größe nicht möglich.

Aber welche Anwendungen kennst du die das o.g. tool einbinden - und die 
ich vermutlich nicht kenne oder aus o.g. erwägungen oder Prinzipiellen 
Bedenken nicht nutze oder nicht mal kenne. ???


> Hier geht es um Machtbarbeit!

Gut. Dann ist es ein Experiment, wie ich am Ende meines Posts ja mutmaßte.

Aber, schriebst du nicht auch das es wg. der größe(n) auf EIS eben nicht 
möglich sein wird? Die Machbarkeit für EIS sehe ich dann nicht gegeben.

Ob hier noch ein Paket sinnvoll wäre das sich wesentliche Komponenten 
für die Funktion erst aus externer Quelle nach laden muß wirst du dann 
bei deinem Experiment vielleicht noch raus finden.


> Es ist dir unbenommen, das für Quatsch zu halten, aber das sagt nichts
> darüber aus, ob das jemand anderes dauch anders sieht.

Ich bin mehr erschreckt über die Dimensionen. 2-10 GB für einen 
DE/EN-textkorrektur-dienst klingt für mich nach BLOAT oder einem 
<unbekannten Agenten> und damit wenig vertrauenswürdig. Weißt du denn 
was alles drin steckt? Oder findest du es noch raus?

>> Da du hier java erwähnst und im folgenden Post erwähnst das E-1 (32bit)
>> nicht ginge... Sollte Java nicht PLATTFORM-unabhängig sein - oder ist
>> die implementation in java selbst nur 64-bittig?
> 
> Man liest das so, es würde aber auch nichts Böses passieren, wenn man es auf
> 32bit probiert - mehr als nicht laufen, passiert bestimmt nicht.

100% Denial of Service ist nichts böses? Wenn es nicht läuft dann ist 
schon die installation auf einem E-1 sinnlos.

Leider bin ich nicht bewandert mit Java runtimes oder den Programmen die 
drauf laufen sollten/könnten. Ob ein java-programm also auch eine 
runtime mit gleicher bitbreite erfordern mag kann ich nicht wirklich 
sagen. Ich las nur mal was von just-in-time compilern, bytecodes und das 
es eben plattform-unabhängig sein sollte.

Aber es ist ja auch egal ob ein neueres java-programm nun eine 64-bit 
jre oder eine bestimmte neuere jre-version erfordert (die's vielleicht 
nur in 64-bit gibt). Dann funktioniert es eben nicht auf einer alten 
oder 32-bittigen jre.

So wie meine alten Cisco Catalyst eine jre 1.3 oder 1.4 erforderten (im 
browser) aber die alten HP ILO eine davon "leicht" abweichende Version 
brauchten um volle Funktionalität zu erreichen. Nur das es dort neben 
dem Webdienst auch noch andere (CLI) Zugänge gibt für die eine 
java-version egal ist. Dafür ggf. eher die veralteten Crypto-methoden - 
wenn man nicht gleich auf telnet zurück fallen will.

Noch so'ne Fortschritts-getriebene Obsoleszenz -katastrophe.

Ich benutze hier nur ein Java-Programm regelmäßig und andauernd mit laufend.

-snip-
System: Linux 5.10.0-38-amd64 amd64 UTF-8
Java: OpenJDK Runtime Environment 11.0.30 /usr/lib/jvm/java-11-openjdk-amd64
TV-Browser: 4.2.7 /usr/share/tvbrowser
-snap-

aber ich kann dir nicht (ohne suchen und graben) sagen ob das nun 
64-bittig wäre oder das bräuchte. Es lief früher auch auf 32-bit und 
Windows - aber heute ist ja vieles anders, nicht unbedingt besser.

Bye/
   /Kay

-- 
Posted via Leafnode