Guten Morgen, ein Linux-Programm benutzt eine Art ini-Datei für die Einstellungen, also key=value, ASCII-Text. Die wird hauptsächlich vom Benutzer per Editor geändert. Also muss das Programm mit Tippfehlern klar kommen. Syntax-Fehler sind eher kein Problem, Fehler im value sieht der Benutzer selber wenn es Text ist, für Integer gibt es jeweils natürliche Grenzwerte. Aber wie behandelt man bei Updates einen unbekannten key? * Eine neue Programmversion findet in einer alten config einen neu eingeführten key nicht - dann sollte es gefälligst einen vernünftigen Default geben. * Ein altes Programm findet in einer neuen config einen unbekannten key - den darf es ignorieren; auch kein Problem. * Aber: Ein Programm findet einen unbekannten key und gleichzeitig fehlt einer - darf es jetzt Regel 1 und 2 anwenden oder ist das ein Tippfehler? Könnte man da mit dieser Levenshtein-Distanz etwas anfangen? Man bekommt doch nur eine Wahrscheinlichkeit, Tippfehler oder zwei gültige keys. Wie macht man das etwas benutzerfreundlicher? Und wieso finde ich keine fertige lib ;) Bisher gibt es ca. 5 Programme und 100++ verschiedene Konfigurationen aus den letzten 15 Jahren. Nur, falls jemand sagen möchte, mach' das einfach ganz anders ;)
Bauform B. schrieb: > * Aber: Ein Programm findet einen unbekannten key und gleichzeitig fehlt > einer - darf es jetzt Regel 1 und 2 anwenden oder ist das ein > Tippfehler? Sowas löst sich meist pragmatisch ganz von alleine ohne drüber nachzudenken. Der fehlende Key hat ein Default und der überschüssige Key wird ignoriert.
Moin, Kannste vielleicht jeweils eine Warnung bei beiden Faellen ausgeben? Dann muessen sich halt die User ggf. einen Reim drauf machen. Oder sind das Amoeben? Gruss WK
Bauform B. schrieb: > Könnte man da mit dieser Levenshtein-Distanz etwas anfangen? Wenn dann nur als Warnung/Hinweis, bloß nicht einen "fast korrekten" Key "Autokorrigieren", das kann gehörig schief gehen. Oder: Einen grafischen Editor bauen, der ein fixes Schema anzeigt, also ein Eingabefeld pro Key; so sind Tippfehler im Key ausgeschlossen. Die Werte kann man auch direkt prüfen.
Bauform B. schrieb: > Und wieso finde ich keine > fertige lib ;) Weil die Implementierung der libglaskugel.so ziemlich schwierig ist. Ein Programm kann nun mal nicht Hellsehen. Da helfen auch keine Heuristiken. Klar, kannst du machen. Von mir aus auch super-modern mit KI. Schlussendlich wird trotzdem nur geraten. Bleib konservativ: Grundsätzlich in allen Fällen Logeinträge. Immer, auch für die problemlos genommenen Parameter. Auch wenn zusätzlich irgendwo Warnungen oder Fehler angezeigt werden. Es ist zum Kotzen wenn man bei der Fehlersuche im Dunklen stehen gelassen wird und nur durch herumprobieren heraus finden muss was passiert ist. Die Fälle: * Was bekannt ist wird genommen. * Was unbekannt ist gibt einen Fehler oder wird ignoriert (gegebenenfalls mit einer Warnung). Ich selber bin ein großer Fan von Fehler aber viele Leute finden ignorieren ganz toll. Nur kommt daher dein Problem. * Was fehlt gibt einen Fehler oder hat eine Voreinstellung mit oder ohne Warnung. > Bisher gibt es ca. 5 Programme und 100++ verschiedene Konfigurationen > aus den letzten 15 Jahren. Nur, falls jemand sagen möchte, mach' das > einfach ganz anders ;) Spring wenigstens über deinen Schatten und führe eine Versionierung des Formates ein. Zum Beispiel ein Parameter wie configFormat=3.7 Dann kannst du auch so Dinge regeln wie geänderte Voreinstellunge, Parameter die weggefallen sind oder gar nicht mehr angegeben werden dürfen, Änderungen in der Semantik von Parametern usw.
Bauform B. schrieb: > ein Linux-Programm benutzt eine Art ini-Datei für die Einstellungen, > also key=value, ASCII-Text. Mach ein GUI-Tool zur Konfiguration, das Unsinn schon vorher abfängt. Anwender lässt man nicht .inis rumpfuschen.
Frank D. schrieb: > Mach ein GUI-Tool zur Konfiguration, das Unsinn schon vorher abfängt. Richtig, allerdings muss man dann auch das durchsetzen: > Anwender lässt man nicht .inis rumpfuschen. Und das wird schwierig, wenn die Anwender das seit 15 Jahren so machen.
Matthias S. schrieb: > Und das wird schwierig, wenn die Anwender das seit 15 Jahren so machen. Bei cleveren UI-Design sieht der Editor fast so aus wie der normale Texteditor, nur eben dass die Feldnamen fix sind. Das könnte man sogar als Expertenmodus implementieren, und für neue Nutzer gibt es einen einfacheren Editor "davorgeschnallt" Und in jeder Fehlermeldung bewirbt man die Vorzüge des Editors ("das wäre damit nicht passiert"), der natürlich auch beim Programm mitgeliefert wird
Was ich empfehle ist Labels case-insensitiv abzufragen. Außerdem sollte es eine klare Regel geben bei doppelten Einträgen. Zu empfehlen ist, immer der letzte gilt.
Alexander schrieb: > Zu empfehlen ist, immer der letzte gilt. Und dann fragt man sich warum der vorherige Eintrag nicht geht... Lieber eine Fehlermeldung bei doppelten Einträgen! Case Sensitive kann auch sinnvoll sein, um z.B. eine CamelCase Schreibweise zu erzwingen, welche u.U. besser verständlich ist. Bei solchen Inputs ist strenger oft besser. Zu versuchen, alles auf Biegen und Brechen zu akzeptieren, führt gern zu Chaos
Einfach readout an AI anbinden. ChatGPT hat da so eine API. Einfach promt geben: "Korrigiere das config file. Hier einige Beispiele: Beispiele.... Gib mir nur die nach bestem Wissen und Gewissen das hochgeskillte Config file in Textformat"
Das ist gelinde gesagt verrückt! Warum KI Abhängigkeiten einführen wo sie nicht notwendig sind?
Alexander schrieb: > Warum KI Abhängigkeiten einführen wo sie nicht notwendig sind? Damit man damit werben kann und ggf. Fördergelder bekommt.
Der Plan von OpenAI ist es, eine Generation heranwachsen zu lassen die von ChatGPT abhängig ist. Wenn dann nichts mehr ohne geht, werden die Preise erhöht.
Alexander schrieb: > Der Plan von OpenAI ist es, eine Generation heranwachsen zu lassen die > von ChatGPT abhängig ist. Wenn dann nichts mehr ohne geht, werden die > Preise erhöht. Der Plan von Bjarne Stroustrup war es eine Generation von C++ abhängig zu machen. Keiner kann mehr Assembler programmieren.
Bauform B. schrieb: > Könnte man da mit dieser Levenshtein-Distanz etwas anfangen? Für das Kernproblem eher nicht, aber für aussagekräftigere Fehler- oder Warnmeldungen. Verschiedene Softwarepakete lösen das Problem durch einen Testmodus -- think "configtest" für apachectl(8) -- oder durch einen Wrapper zum Editieren der Konfiguration, der die editierte Konfiguration vor deren Installation auf syntaktische und, wo möglich, inhaltliche Korrektheit überprüft, bevor er sie endgültig installiert. Ein Beispiel für die letztgenannte Variante ist zum Beispiel visudo(8) zum Ändern der Konfiguration von sudo(1). In beiden Fällen heißt das aber natürlich auch, daß jedliche Änderungen an der Konfiguration nicht nur im Programm selbst, sondern auch in seinem Testmodus oder dem Wrapper widergespiegelt werden müssen. Wenn das auseinander läuft, verkehrt sich die gute Idee schnell ins Gegenteil. In den beiden beschriebenen Varianten hast Du dann vermutlich eine Liste von zulässigen Schlüsseln, und kannst so jeden gefundenen Schlüssel mit dem Levenshtein- oder Damerau-Levenshtein-Algorithmus gegen diese Liste prüfen. Wenn ein gefundener Schlüssel nicht in der Liste der zulässigen Schlüssel ist, die Levenshtein-Distanz aber lediglich 1 oder 2 ist, könnte eine kluge Warn- oder Fehlermeldung so etwas schreiben wie
1 | Unbekannte Direktive "ruebennase" (Zeile 11), meinten Sie "rübennase"? |
Aus meiner Erfahrung weiß ich, daß sich Fehlermeldungen mit solchen Hinweisen nicht nur bei mir selbst großer Beliebtheit erfreuen. :-) Mittlerweile bin ich im Übrigen dazu übergegangen, anstelle eigener Formate, JSON- oder INI-Dateien für Konfigurationsdateien nurmehr YAML zu verwenden. Das ermöglicht beliebig tief geschachtelte Datenstrukturen und Kommentare, und läßt sich schnell und effizient parsen. Im typsicheren Golang werden die Typen bereits beim Einlesen (genauer: beim Aufruf von yaml.Unmarshal()) überprüft, mit dem Paket "validator" [1] können darüber hinaus weitere, fein granulierte Prüfungen erfolgen. In Python gibt es zum Prüfen von Datenstrukturen und ihren Inhalten das Paket Pydantic [2], das mit Type Hints arbeitet. Aus Spaß an der Freude habe ich ein wenig Code in Golang und Python angehängt. Wahrscheinlich nutzt Du andere Sprachen und kannst meine Beispiele deswegen nicht direkt nutzen. Trotzdem glaube ich, daß sich darin gute Ideen auch für andere Sprachen finden und sich übertragen lassen. [1] https://github.com/go-playground/validator [2] https://pydantic.dev/
Alexander schrieb: > Was ich empfehle ist Labels case-insensitiv abzufragen. Außerdem sollte > es eine klare Regel geben bei doppelten Einträgen. Zu empfehlen ist, > immer der letzte gilt. Das ist eine feine Sache, zum Beispiel PostgreSQL macht das so. Schick: man kann die ganze Konfigurationsdatei auf den Defaultsettings lassen und seine getunten Settings (pgtune, anyone?) schön übersichtlich zusammen ans Ende der Datei schreiben, die überstimmen dann die oben gesetzten Defaults.
Du solltest hier das Paradigma, "Garbage In, Garbage Out" verwenden, wenn der Typo schon in der alten Version war, hat die auch irgendwie Funktioniert, dann erwartet der Benutzer hier das Default verhalten. Einfach zu sagen passt schon ich weiß was du meinst, ist grundsätzlich gefährlich bei Konfigurationen. Wenn du ein Benutzer helfen willst, mach eine Syntax Checker für die Konfiguration. Meine Programme haben meistens die Option die aktuelle Konfiguration in eine Datei oder nach Stdout zu schreiben, die kann dann der Benutzer sich ansehen und merkt sein Fehler hoffentlich.
Ein T. schrieb: > , die überstimmen dann die oben gesetzten Defaults. Welchen Zweck haben dann die da herumoxidierenden Defaults, außer Verwirrung zu stiften? Ich würde sie auskommentieren oder verschieben...
Matthias S. schrieb: > Und das wird schwierig, wenn die Anwender das seit 15 Jahren so machen. Dann ändert man das Format: keine inis mehr sondern serialisierte Objekte, verschwurbelte Binaerdaten,...
Ein T. schrieb: > Das ist eine feine Sache, zum Beispiel PostgreSQL macht das so. Schick: > man kann die ganze Konfigurationsdatei auf den Defaultsettings lassen > und seine getunten Settings (pgtune, anyone?) schön übersichtlich > zusammen ans Ende der Datei schreiben, die überstimmen dann die oben > gesetzten Defaults. Wenn sich da nicht in den letzten Versionen etwas geändert hat, stehen die Defaults zwar drin, aber auskommentiert. Kombiniert den von Dir genannten Vorteil (hinten dranhängen) damit, dass es eben keine sich widersprechenden Config-Zeilen gibt, von denen die letzte gilt.
Faszinierend, mir fehlen die Worte, vielen Dank miteinander! Hannes J. schrieb: > Was unbekannt ist gibt einen Fehler oder wird ignoriert > (gegebenenfalls mit einer Warnung). Ich selber bin ein großer Fan von > Fehler aber viele Leute finden ignorieren ganz toll. Nur kommt daher > dein Problem. Niklas G. schrieb: > bloß nicht einen "fast korrekten" Key > "Autokorrigieren", das kann gehörig schief gehen. Ein T. schrieb: > Bauform B. schrieb: >> Könnte man da mit dieser Levenshtein-Distanz etwas anfangen? > > Für das Kernproblem eher nicht, aber für aussagekräftigere Fehler- oder > Warnmeldungen. Das sind die lehrreichsten Aussagen für mich. Bisher sind die Programme gnadenlos, bei jeder kleinen Ungereimtheit wird ein Update verweigert. Natürlich sind die Benutzer davon nicht begeistert, aber ich sehe es ein, das Prinzip ist richtig. Nur eins war übertrieben: eine neue Programmversion muss gefälligst eine korrekte alte Config akzeptieren. Ein Beispiel für eine misslungene Erweiterung: das Programm war 2-sprachig, also gab es z.B. locale1 = fr_CH und locale2 = de_DE. Später waren mehr Sprachen möglich, also gibt es locales = "fr_CH de_DE". Für sowas muss man wohl individuelle Konverter-Funktionen bauen und locale1 und locale2 bis in alle Ewigkeit akzeptieren. Hannes J. schrieb: > Grundsätzlich in allen Fällen Logeinträge. Immer, auch für die > problemlos genommenen Parameter. Auch wenn zusätzlich irgendwo Warnungen > oder Fehler angezeigt werden. Das habe ich vielleicht schon übertrieben. Jetzt muss ich hoffen, dass logrotate immer funktioniert ;) Frank D. schrieb: > Anwender lässt man nicht .inis rumpfuschen. Wenn es kein UI gibt, lässt sich das kaum vermeiden. Außerdem hat das Format den großen Vorteil, dass die Gebrauchsanweisung genau da steht, wo man sie braucht (ja, jemand muss sie schreiben, aber das machen Benutzer sogar selber). Alexander schrieb: > Was ich empfehle ist Labels case-insensitiv abzufragen. Außerdem sollte > es eine klare Regel geben bei doppelten Einträgen. Die klaren Regeln sind ganz klar: case-sensitive und doppelte sind verboten. Je eindeutiger desto eindeutig (oder so). Ein T. schrieb: > Schick: > man kann die ganze Konfigurationsdatei auf den Defaultsettings lassen > und seine getunten Settings (pgtune, anyone?) schön übersichtlich > zusammen ans Ende der Datei schreiben Bei über 1500 Zeilen kann "am Ende" ganz schön weit weg sein; lieber nicht. Niklas G. schrieb: > Bei cleveren UI-Design sieht der Editor fast so aus wie der normale > Texteditor, nur eben dass die Feldnamen fix sind. Erst dachte ich, jetzt ist er ganz falsch abgebogen, völlig utopisch das. Aber geany z.B. kennt C-Syntax, C-Keywords und ini-Syntax. Wenn man dem meine Keywords beibringen könnte... Naja, was für lange Winterabende ;)
Bauform B. schrieb: > Natürlich sind die Benutzer davon nicht begeistert Die Nutzer und der Support wären noch weniger begeistert wenn die Software ständig irgendwas unerwartetes tut weil die Konfig falsch interpretiert wurde. Bauform B. schrieb: > Für > sowas muss man wohl individuelle Konverter-Funktionen bauen und locale1 > und locale2 bis in alle Ewigkeit akzeptieren. Oder erst eine Warnung ausgeben "altes Format wird nur bis Version X unterstützt" und ab da wird der Support rausgenommen. Bauform B. schrieb: > Wenn es kein UI gibt, lässt sich das kaum vermeiden. Auch wenn das Programm selber keine GUI hat, kann man die Datei trotzdem mit einem GUI-Programm erzeugen. Die meisten Computer haben heutzutage die Möglichkeit eine GUI darzustellen... Bauform B. schrieb: > Erst dachte ich, jetzt ist er ganz falsch abgebogen, völlig utopisch > das. Aber geany z.B. kennt C-Syntax, C-Keywords und ini-Syntax. Ich meinte nicht als Texteditor mit Highlighting, sondern eher eine GUI welche z.B. eine 2-Spaltige Tabelle darstellt: Linke Spalte ist der Key, rechte der Value. Die linke Spalte ist read-only. Die rechte Spalte wird immer auf Konsistenz geprüft. Dann noch Zwischenüberschriften dazu, ein automatisch eingeblendeter Hilfstext zur aktuell ausgewählten Zeile, Dropbox-Felder oder Datums-Auswahlboxen bei entsprechenden Zeilen, und schon kann kaum noch was schief gehen. Das kann man sich ziemlich simpel in allen gängigen GUI-Frameworks zusammenbauen, sogar auch als Web-Interface mit JavaScript oder Mobil-App...
:
Bearbeitet durch User
Bauform B. schrieb: > Bei über 1500 Zeilen kann "am Ende" ganz schön weit weg sein; lieber > nicht. In was für einem masochstischen Laden läuft Software die über ein 1500 Zeilen langes config-file konfiguriert wird? Das ist ja gruselig! Ein komplettes redesign wäre die einzig sinnvolle Lösung, statt 1500 Zeilen Spaghetti.
Frank D. schrieb: >> wenn die Anwender das seit 15 Jahren so machen > Dann ändert man das Format Du hast wohl nicht begriffen, das die Anwender kein anderes Dateiformat wollen.
Nemopuk schrieb: > Frank D. schrieb: >>> wenn die Anwender das seit 15 Jahren so machen >> Dann ändert man das Format > > Du hast wohl nicht begriffen, das die Anwender kein anderes Dateiformat > wollen. Naja, damals wurden sie nicht gefragt und Änderungen mag ja niemand ;) Re D. schrieb: > In was für einem masochstischen Laden läuft Software die über ein 1500 > Zeilen langes config-file konfiguriert wird? Das ist ja gruselig! Ganz so schlimm ist es nicht, das sind hauptsächlich Texte für 3 Sprachen. Die interessanten Einstellungen stehen natürlich am Anfang und Ein T. wollte die aktuellen Werte doppelt ans Ende schreiben. Niklas G. schrieb: > Ich meinte nicht als Texteditor mit Highlighting, sondern eher eine GUI > welche z.B. eine 2-Spaltige Tabelle darstellt: Linke Spalte ist der Key, > rechte der Value. Man müsste noch die Kommentare vor jeder Zeile ändern können - nicht, aber ergänzen. Genau, read-only Text von mir und Kommentar vom Benutzer. Einerseits lohnt es sich umso besser, je genauer es alle Parameter prüfen kann, andererseits wäre es eigenständiges Programm, wahrscheinlich sogar für Windows. Könnte ich auf Debian eine DLL mit den Prüf-Funktionen erzeugen? Ich glaube, ich sollte jetzt sofort etwas ganz anderes machen ;)
Bauform B. schrieb: > Könnte ich auf Debian eine DLL mit den Prüf-Funktionen erzeugen? Ich > glaube, ich sollte jetzt sofort etwas ganz anderes machen ;) Mach's in Python oder Java, dann spielt das OS keine Rolle... Bauform B. schrieb: > Genau, read-only Text von mir und Kommentar vom Benutzer Keine schlechte Idee, der fixe Text ist im Editor fix und landet nicht in der Datei, der User Kommentar kommt in die Datei.
Schade, dass es keinen Script-Interpreter gibt, der aus nur einer Datei besteht und auf allen gängigen Betriebssystemen läuft.
Nemopuk schrieb: > Schade, dass es keinen Script-Interpreter gibt, der aus nur einer Datei > besteht und auf allen gängigen Betriebssystemen läuft. ZIP macht aus allem eine einzelne Datei.
Niklas G. schrieb: > Ein T. schrieb: >> , die überstimmen dann die oben gesetzten Defaults. > > Welchen Zweck haben dann die da herumoxidierenden Defaults, Ihre Oxidation. Und morgen lernen wir, was ein Beispiel ist. :-)
Hmmm schrieb: > Ein T. schrieb: >> Das ist eine feine Sache, zum Beispiel PostgreSQL macht das so. Schick: >> man kann die ganze Konfigurationsdatei auf den Defaultsettings lassen >> und seine getunten Settings (pgtune, anyone?) schön übersichtlich >> zusammen ans Ende der Datei schreiben, die überstimmen dann die oben >> gesetzten Defaults. > > Wenn sich da nicht in den letzten Versionen etwas geändert hat, stehen > die Defaults zwar drin, aber auskommentiert. Das hängt vom Paketierer ab, beispielsweise das Paket von Ubuntu Linux setzt einige Werte -- warum auch immer, denn die gesetzten Werte stimmen meistens mit den Defaultwerten des Upstreams überein. Wie dem auch sei, erscheint mir Dein Einwand hier leider nicht sehr relevant. Denn letztlich ist es gleichgültig, ob die am Ende eingefügten Werte bereits zuvor gesetzte Werte oder die eingebauten Defaultwerte überschreiben, oder?
Bauform B. schrieb: > Das sind die lehrreichsten Aussagen für mich. Bisher sind die Programme > gnadenlos, bei jeder kleinen Ungereimtheit wird ein Update verweigert. Das würde ich auch weiterhin so halten, Konfigurationsdaten sind sensibel. Aber mit Levenshtein kannst Du immerhin aussagekräftigere Fehlermeldungen generieren und Deinen Benutzern helfen. > Nur eins war übertrieben: eine neue > Programmversion muss gefälligst eine korrekte alte Config akzeptieren. Das würde ich nicht machen, denn sonst verbleiben einzelne Komponenten des Programms womöglich unkonfiguriert oder auf den Defaults. Aber es gibt ein probates Mittel, mit solchen Situationen umzugehen: Konvertierskripte oder -Programme, die zuerst ein Backup der alten Datei anlegen (think Downgrade), und die alten Konfigurationsdaten dann in das neue Format überführen. Diese Skripte werden einfach bei der Installation vom Paketmanager ausgeführt. > Ein Beispiel für eine misslungene Erweiterung: das Programm war > 2-sprachig, also gab es z.B. locale1 = fr_CH und locale2 = de_DE. Später > waren mehr Sprachen möglich, also gibt es locales = "fr_CH de_DE". Für > sowas muss man wohl individuelle Konverter-Funktionen bauen und locale1 > und locale2 bis in alle Ewigkeit akzeptieren. Eine beliebte Methode für solche Updates ist, neben den Konvertierskripten oder -Programmen, die Deprecation. Das heißt: wenn Du die alten Direktiven hinauswerfen möchtest, wird eine "Deprecation Warning" ausgegeben, daß die Konfigurationsdirektive in der nächsten oder übernächsten Version wegfällt, stattdessen die neue(n) Direktive(n) benutzt werden sollen. Auch hier sind aussagekräftige Meldungen natürlich besonders komfortabel für die Benutzer. Nachteil dieser Methode ist jedoch, daß die Software bis zur nächsten oder übernächsten Version -- wenn die alte Direktive entfernt wird -- zunächst beide Konfigurationsversionen unterstützen muß, was den Aufwand zumindest erhöht und manchmal sogar kaum möglich ist. > Bei über 1500 Zeilen kann "am Ende" ganz schön weit weg sein; lieber > nicht. Naja, beim GNU Emacs sind das drei Tastendrücke, "ESC" und ">", und schon bin ich am Ende der Datei. ;-) Bauform B. schrieb: > Re D. schrieb: >> In was für einem masochstischen Laden läuft Software die über ein 1500 >> Zeilen langes config-file konfiguriert wird? Das ist ja gruselig! > > Ganz so schlimm ist es nicht, das sind hauptsächlich Texte für 3 > Sprachen. Verschiedene Locales -- das betrifft ja nicht nur Sprachen, sondern auch Dinge wie die Darstellung von Zahlen (1.234,56 vs 1,234.56) und kalendarischen Daten (DMY, YMD, MDY, YDM, was für ein Chaos) -- werden heute oft mit verschiedenen Dateien oder Verzeichnissen abgebildet, welche jeweils nach der betreffenden Locale benannt sind. Das erscheint mir eine ebenso gute wie übersichtliche Lösung zu sein, so daß Deine Konfigurationsdatei überschaubar, verständlich und kompakt bleibt. Niklas G. schrieb: > Bauform B. schrieb: >> Könnte ich auf Debian eine DLL mit den Prüf-Funktionen erzeugen? Ich >> glaube, ich sollte jetzt sofort etwas ganz anderes machen ;) > > Mach's in Python oder Java, dann spielt das OS keine Rolle... Python, Java und Ähnliche erfordern die Installation eines Interpreters, und das gefällt nicht jedem Benutzer -- während andere das womöglich gar nicht dürfen, weil sie einen fremdverwalteten Computer benutzen müssen. :-) Deswegen wäre mein Ratschlag eine Webapplikation in -- ja, möglicherweise nerve ich ein bisschen damit -- Golang. Das läßt sich ganz leicht durch das Setzen einiger Umgebungsvariablen und Pakete in nur eine einzelne, statisch gelinkte Datei mit eingebetteten Ressourcen crosskompilieren, und als Webapp nicht nur lokal, sondern auch auf einem Server betreiben. Noch komfortabler dürfte IMHO kaum möglich sein... :-)
Ein T. schrieb: > Python, Java und Ähnliche erfordern die Installation eines Interpreters, Nö, da muss man nur ein ZIP herunterladen und entpacken. Ein T. schrieb: > während andere das womöglich gar > nicht dürfen, weil sie einen fremdverwalteten Computer benutzen müssen. Ein ZIP entpacken und die java.exe oder python.exe ausführen geht immer. Ein T. schrieb: > in > nur eine einzelne, statisch gelinkte Datei mit eingebetteten Ressourcen > crosskompilieren, und als Webapp nicht nur lokal, sondern auch auf einem > Server betreiben. Ist bei Java Web Apps schon seit Anbeginn der Zeit der Default
Bauform B. schrieb: > Re D. schrieb: >> In was für einem masochstischen Laden läuft Software die über ein 1500 >> Zeilen langes config-file konfiguriert wird? Das ist ja gruselig! > > Ganz so schlimm ist es nicht, das sind hauptsächlich Texte für 3 > Sprachen. Die interessanten Einstellungen stehen natürlich am Anfang Doch es ist schlimm und gruselig. Sowas war in der 70er Jahren vielleicht state of the art, aber vor 15 Jahren sicher nicht mehr. Das ganze Konzept ist stümperhaft.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.