YUM/RPM: Must have Pakete

(DE) System, Installation, Konfiguration, Hardware, Treiber, Netzwerk, Virtualisierung, etc.
(EN) System, Installation, Configuration, Hardware, Drivers, Network, Virtualisation, etc.
Benutzeravatar
hanno
Beiträge: 97
Registriert: Do 9. Jan 2014, 22:20

YUM/RPM: Must have Pakete

Beitrag von hanno »

Hallo,

gibt es eigentlich irgendwo Informationen/Tipps/Listen, was denn die wirklich essentiell nötigen Pakete sind, die mittels YUM auf einem System installiert werden sollten?

Schöne Grüße
Hanno
Zuletzt geändert von hanno am Mi 10. Feb 2016, 12:36, insgesamt 1-mal geändert.
Benutzeravatar
ak120
Beiträge: 1044
Registriert: Do 8. Mai 2014, 12:50
Wohnort: Demmin
Kontaktdaten:

Beitrag von ak120 »

Die wären unnötig, da yum nur zum Ermitteln und Übertragen der Pakete genutzt wird und nichts installiert.
Benutzeravatar
Frank Wochatz
Beiträge: 1112
Registriert: So 22. Dez 2013, 22:04
Wohnort: Berlin
Kontaktdaten:

Beitrag von Frank Wochatz »

Die Frage zielt ja sicher darauf ab, welche DLLs aus den RPM Paketen man unbedingt braucht (man kann ja auch mal versuchen, eine Frage zu verstehen, und muss keine Erbsen zählen, Dr. Akt120).

Also die Frage lässt sich so pauschal nicht beantworten, es hängt davon ab, welche Software Du einsetzt. Die Informationen findest Du dann immer in der Dokumentation der Software (oder auch nicht, dann helfen ev. die Programmierer oder eine Suche in den Foren weiter).

Ich hab mir letztens alle DLLs als zip runter geladen und alle darin enthaltenen DLLs extrahiert. Am besten legt man sich ein Verzeichnis Bootdrive:\dllhell an ;), und setzt den libpath dahin. Ich habe also einen kompletten Pool mit allen DLLs. Leider gibt es dabei das Problem, dass einige DLLs unter gleichen Namen in unterschiedlichen Versionen vorliegen, aber nicht durchnummeriert sind. Das muss man beim Entpacken aufpassen, dass man da die letzten Versionen verwendet.
Benutzeravatar
ak120
Beiträge: 1044
Registriert: Do 8. Mai 2014, 12:50
Wohnort: Demmin
Kontaktdaten:

Beitrag von ak120 »

Bei yum handelt es sich um ein System zur Aktualisierung von RPM-Paketen. Folglich ändern sich die Paketlisten manchmal.
Mit dem Befehl "yum provides name.dll" kann/könnte man sich die bereitgestellten RPM-Pakete anzeigen lassen, welche diesen Dateinamen enthalten.
Der Hinweis auf die angebliche Dokumentation ist natürlich sehr scheinheilig. Ohne den Umweg über ein zusätzliches Terminalemulationsprogramm, sind selbst die über GNU gettext vorgenommenen Lokalisierungen nicht nutzbar, da diese in einer lokal nicht vorhanden Zeichenumsetztabelle vorliegen. Ebenso sind die Befehle man (gar nicht erst nicht vorhanden) und info kaum sinnvoll verwendbar. Es steht natürlich jedem frei groff und man von Hand nachzurüsten, um dann weitere schwerwiegende Lücken festzustellen.
Benutzeravatar
Frank Wochatz
Beiträge: 1112
Registriert: So 22. Dez 2013, 22:04
Wohnort: Berlin
Kontaktdaten:

Beitrag von Frank Wochatz »

Ich meinte nicht die YUM-Doku oder Dokus zu RPM-Paketen, sondern die Dokumentationen der Programme, die entsprechende DLLs benötigen. ZB. steht in der Firefox readme.txt, welche DLLs benötigt werden (mit entsprechenden Links bzw. YUM Downloadbefehlen). Ich gehe mal davon aus, das dies der häufige Anwendungsfall ist. Wenn man bestimmte Pakete direkt nutzen will (zB. irgenwelche Commandlinetools), die als RPM angeboten werden, ist das natürlich etwas anderes. Daher würde ich in diesem Fall eher zu den ZIP-Files als zu den RPM-Paketen greifen.
Benutzeravatar
aschn
Beiträge: 1363
Registriert: Mi 25. Dez 2013, 22:47

Beitrag von aschn »

Ich hab's so gemacht, dass ich nur die in der Doku genannten Pakete installiert hab. Von Zeit zu Zeit geh ich dann aber die verfügbaren durch und installier das, was mir interessant erscheint, oder wovon ich nur eine ältere Version hab, hinzu.

Wenn man z.B. etwas für die Befehlszeile braucht, das nur nach Posix riecht, dann sollte man erst mal bei den RPM-Paketen nachsehen. Dazu gehören auch Zip und Ghostscript.
Andreas Schnellbacher
Benutzeravatar
Frank Wochatz
Beiträge: 1112
Registriert: So 22. Dez 2013, 22:04
Wohnort: Berlin
Kontaktdaten:

Beitrag von Frank Wochatz »

ZZ. soll es ja bei Netlabs zu allen dort verfügbaren RPM Paketen inhaltsgleiche ZIPs geben... Ich habe da bislang auch nichts vermisst (bis auf eine Ausnahme, und Silvan hatte das dann auch ein oder zwei Tage später bereits wieder aktualisiert). Man kann also beide Wege gehen.
Benutzeravatar
hanno
Beiträge: 97
Registriert: Do 9. Jan 2014, 22:20

Beitrag von hanno »

Danke für die Antworten! (Den Betreff habe ich etwas geändert, damit die Frage etwas "richtiger" ist, aber, wie Frank bemerkt hat, war hoffentlich klar was ich wissen wollte.)

Dass es da keine allgemeingültige Antwort gibt ist logisch. Ich habe auch, so wie vorgeschlagen, eigentlich immer nur aufgrund der Readme's installiert.
Die Liste der verfügbaren Pakete (Befehl "yum list") ist ja aber viel länger und da sind sicher Sachen dabei, die in jedem System (zB aufgrund der BS-Installation) schon drinnen sind. Und meine Frage zielte eben darauf ab, ob jemand weiß, was da "so üblich" ist ;).

Danke auf für den Tipp mit den Zip's - der Weg ist event. auch nicht schlecht.

Schöne Grüße
Hanno
Benutzeravatar
MikeK
Beiträge: 369
Registriert: Mo 23. Dez 2013, 13:51
Wohnort: Potsdam

Beitrag von MikeK »

Hallo Hanno,

schau Dir doch mal den Arche Noah Paket Manager (https://www.arcanoae.com/resources/downloads/) an.
Der erleichtert meiner Meinung nach die Verwaltung der Pakete doch etwas.

Grüße aus Potsdam,
Mike
Benutzeravatar
Frank Wochatz
Beiträge: 1112
Registriert: So 22. Dez 2013, 22:04
Wohnort: Berlin
Kontaktdaten:

Beitrag von Frank Wochatz »

Hallo Hanno, ich würde sagen 'üblich' ist davon garnichts. Es bringt auch garnicht so viel, sich die DLLs schonmal vorsichtshalber vorab zu installieren, da öfter mal mit neuen Programmen auch neue DLL-Versionen kommen.
Benutzeravatar
ak120
Beiträge: 1044
Registriert: Do 8. Mai 2014, 12:50
Wohnort: Demmin
Kontaktdaten:

Beitrag von ak120 »

Am sinnvollsten wäre es die jeweiligen DLL-Dateien im Programmverzeichnis zu halten und den Suchpfad "." zu priorisieren bzw. BEGINLIBPATH zu nutzen. Nicht nur wegen gleicher Dateinamen, sondern auch bei gleichen Modulaufrufen innerhalb, kann es sonst schnell zu Konflikten kommen, insbesondere zwischen EMX- und klibc-Erzeugnissen.
Benutzeravatar
Frank Wochatz
Beiträge: 1112
Registriert: So 22. Dez 2013, 22:04
Wohnort: Berlin
Kontaktdaten:

Beitrag von Frank Wochatz »

Am sinnvollsten wäre es die jeweiligen DLL-Dateien im Programmverzeichnis zu halten und den Suchpfad "." zu priorisieren bzw. BEGINLIBPATH zu nutzen.
Sehe ich auch so, und wenn dann die Programmierer noch komplette Pakete inkl. der DLLs erstellen würden, das wäre dann Weihnachten und Ostern an einem Tag. Dann brauchts kein YUM, kein RPM, keine Readmes mit langen, parallelen Erklärungen zu YUM und ZIP Installationen, weniger Support für die Leute, mit dem berechtigten Fragezeichen auf dem Kopf, keine Paketverwaltung (wozu?), keine Frontends etc.pp.. Installationen wären wieder einfach und simpel, das würde einfach mal mit einem Schlag sämtliche Probleme beheben. Alleine das Schreiben der entspr. Readmepassagen dürfte den Programmierern mehr Zeit kosten als ein komplettes Paket zu schnüren. Einfach die 4 benötigten DLLs mit ins ZIP.

Aber die Diskussion hatten wir schonmal, und die Meinungen gehen auseinander, insbesondere was dann versch. DLL Versionsstände im System bedeuten. Wobei das Argument für mich auch nicht zieht, solange nicht wirklich alles über eine Paketverwaltung installiert wird, ist das ein Problem was IMMER bestehen wird. Das Problem kann man nur mit einer Versionsabfrage einer DLL aus der Anwendung mit entsprechender aussagekräftiger Fehlermeldung sauber lösen. Voila.

Die Entscheidung ist eben gefallen, und ich denke der Drops ist gelutscht. Die Verteilung von Software in Fragmenten ist jetzt da und wird nicht mehr verschwinden. Die Paketverwaltungen oben drauf sind Symptom- statt Ursachenbehandlung.
Benutzeravatar
ak120
Beiträge: 1044
Registriert: Do 8. Mai 2014, 12:50
Wohnort: Demmin
Kontaktdaten:

Beitrag von ak120 »

Dann brauchts kein YUM, kein RPM, keine Readmes mit langen, parallelen Erklärungen zu YUM und ZIP Installationen
Das wäre ja viel zu einfach und würde eventuell auch noch unnötige neue Entwickler motivieren. YUM ist schon ganz praktisch, hab es selber unter Yellow Dog Linux genutzt, nur hat es dort vor 15 Jahren schon besser funktioniert. Die README-Dateien sind meistens nur lieblos zusammenkopiert und daher fehleranfällig. Schnell wird dort eine URL ungültig oder eine neuere Version der DLL vergessen. Einen Sinn (Vorteil) hätte der Einsatz von RPM nur, wenn die tatsächlichen Anwendungen als RPM-Paket vorliegen würden und die Abhängigkeiten sich dann entsprechend auflösen. Das Erstellen und Aktualisieren der RPM-Pakete müßte natürlich auch noch jemand übernehmen, die Befürworter dieses Ansatzes haben dafür nachweislich weder Zeit noch Lust. Multipliziert mit dem mangelnden technischen Verständnis ergibt sich daraus leider die nun vorliegende (desolate) Situation.

Ich kann den Einsatz von YUM/RPM nur innerhalb einer gesonderten (experimentellen) Entwicklungsumgebung (bei Bedarf am besten virtuell) empfehlen. Solange keine hinreichenden Berichte über die Verträglichkeit mit bereits bestehenden und eingesetzten Programmen vorliegen, sollte man auf jeden Fall einen Rückfallplan schnell griffbereit halten.
Benutzeravatar
Frank Wochatz
Beiträge: 1112
Registriert: So 22. Dez 2013, 22:04
Wohnort: Berlin
Kontaktdaten:

Beitrag von Frank Wochatz »

Ich denke mal es wird so laufen: den Paketmanager wird man hinbekommen, und dann funktioniert das für eine bestimmte Auswahl an Programmen zumindest mit einem Frontend. Andere Programme wird man wie gehabt installieren. Es ist wohl eigentlich auch nicht zielführend, wenn wir hier darüber zu diskutieren. Konstruktiv wäre es, eine Alternative anzubieten, zB. könnte man Komplettarchive von Programmen erstellen, oder man könnte den DLL-Pool auf anderem Wege zur Verfügung stellen. Aber das ist ein 'moving target', wo man immer hinterherarbeiten müsste. Also werden die Nutzer sich damit arangieren, oder eben diese Programme nicht benutzen können. Mal nüchtern betrachtet.
Benutzeravatar
wilfried
Beiträge: 667
Registriert: Mo 23. Dez 2013, 18:26
Wohnort: Barsinghausen
Kontaktdaten:

Beitrag von wilfried »

Das scheint ein Phänomen unserer Zeit zu sein.
Wie hies es doch früher "Never change a running system".
Wenn man diesem Thread hier folgt, bekommt man den Eindruck, die Hauptaktivität eines ecs- oder OS/2-Users besteht darin sein System so aktuell wie möglich zu halten.
Kann man denn nur noch mit dem letzten Stand des Systems vernünftig arbeiten?
Wenn Dinge nicht laufen, geht es mir auch so, dann versuche ich hartnäckig eine Lösung oder Umgehung zu finden.
Die meiste Zeit freue ich mich aber das Dinge funktionieren und wenn das so ist wird nicht mehr geändert sondern einfach gearbeitet.
Allenfalls wird ein Testrechner oder eine andere Platte eingesetzt um herauszufinden ob die Änderungen nichts kaputtmachen oder was die neue Funktion bringt.

Viel Spaß beim Ändern!
Andi B.
Beiträge: 742
Registriert: Di 24. Dez 2013, 16:40
Kontaktdaten:

Beitrag von Andi B. »

Nüchtern betrachtet kommen fast alle Neuerungen und aktuelle Anwendungen direkt oder indirekt von BWW. Also von Silvan, Dmitriy, Yuri... auch in Zusammenarbeit mit z.B. Paul. Neuerungen/Fixes für's Grundsystem sind nur von Arca Noae zu erwarten. Und die arbeiten eng mit BWW zusammen. Und dann noch ein paar Einzelkämpfer wie Lars (exemplarisch genannt, nicht böse sein wenn ich hier andere nicht explizit nenne), die aber auch mehr oder weniger eng mit AN und BWW zusammenarbeiten. Und die sind nun mal alle von den Vorteilen von rpm/yum für unser OS/2 überzeugt, oder besser gesagt, sie wissen, dass dies das kleinere Übel ist verglichen mit dem Wildwuchs der davor entstanden ist. Das hat seine Gründe welche schon mehrfach diskutiert (von so manchen aber leider nicht verstanden) wurden, die man nicht teilen muss, aber man kann sich damit arrangieren. Blöd schreiben dagegen ohne selbst irgendwas positives an der Verbesserung der Nutzbarkeit unseres Systems beizutragen (ak120) geht leicht, hilft den Usern aber nicht.

Auch Vorschläge wie dll Pakete als zips parallel zu verteilen konterkarieren in gewissen Maße die Arbeit der Experten (ich verwende dieses Wort hier bewusst weil viele der ev. sogar gutgemeinten Ratschläge in diversen Foren von Leuten gemacht werden, welche man sicher nicht so bezeichnen kann) dieses Chaos einzudämmen. Was bitte soll besser sein daran seine dlls händisch nach \irgendwo\dlls zu kopieren anstatt diese automatisch durch yum update in \usr\... auf Stand zu halten? Dass viele versuchen ihrer dlls händisch aktuell zu halten (was praktisch aus diversen Gründen kaum möglich ist) ist doch der Grund dafür, dass bei so manchen die blödesten Probleme auftreten welche andere (auch der Entwickler/Portierer) nicht nachvollziehen können.
den Suchpfad "." zu priorisieren bzw. BEGINLIBPATH zu nutzen
Müsste heißen "BEGINLIBPATH" und "LIBPATHSTRICT" zu nutzen für spezielle Programme die spezielle Versionen von dlls brauchen. "." zu priorisieren ist leider ein schlechter Vorschlag. "." am Ende des LIBPATH ist der bessere Weg. Wenn er am Anfang ist, dann hängt es wieder davon ab welches Programm man zuerst startet und die Probleme werden nur verschleppt und viel schwerer zu finden.

Klar kann ein jeder mit seinem System machen wie er will. Aber das Jammern über die Arbeit der anderen von jemanden welcher selbst keinen Handgriff zur Entwicklung neuer Anwendungen beiträgt, hilft nur dessen eigenem Ego und geht mir schon ziemlich auf den Geist.

Sorry off topic. Ich halt jetzt auch die Klappe.
Benutzeravatar
Frank Wochatz
Beiträge: 1112
Registriert: So 22. Dez 2013, 22:04
Wohnort: Berlin
Kontaktdaten:

Beitrag von Frank Wochatz »

Hi Wilfried, eigentlich gehts zZ. nicht um das System selbst. Über o.g. Verfahren werden überwiegend Pakete angeboten, die für Anwendungsprogramme erforderlich sind. Ständig braucht man das nicht, aber jedesmal wenn man mal ein Anwendung oder ein Tool installieren möchte. ;)
Benutzeravatar
Frank Wochatz
Beiträge: 1112
Registriert: So 22. Dez 2013, 22:04
Wohnort: Berlin
Kontaktdaten:

Beitrag von Frank Wochatz »

Dass viele versuchen ihrer dlls händisch aktuell zu halten (was praktisch aus diversen Gründen kaum möglich ist) ist doch der Grund dafür, dass bei so manchen die blödesten Probleme auftreten welche andere (auch der Entwickler/Portierer) nicht nachvollziehen können.
Nö. Das Problem und der damit verbundene Supportaufwand ensteht, weil Programme versuchen DLLs zu laden, ohne den Versionsstand abzufragen, und ohne ggf. eine lesbare Fehlermeldung auszugeben. Btw zZ lese ich überwiegend über Probleme mit RPM und YUM.
Andi B.
Beiträge: 742
Registriert: Di 24. Dez 2013, 16:40
Kontaktdaten:

Beitrag von Andi B. »

DLLs zu laden, ohne den Versionsstand abzufragen, und ohne ggf. eine lesbare Fehlermeldung auszugeben
Und wenn du mal bei allen portierten dlls die Versionskennung eingebaut hast und diese dann auch dauernd auf Stand hältst (die Ursprungsplattform braucht nicht die Versionskennung wie wir sie brauchen würden --> bei jedem update wieder Hand anlegen!), dann noch die portieren Programme so erweitert hast, dass diese dir genehme Fehlermeldung ausgegeben wird (die eigentlich überflüssig ist wenn man nicht die dlls übers ganze System chaotisch verstreut hätte), dann können wir weiter darüber diskutieren, welchen Mehraufwand diese Vorgangsweise beansprucht hat.

Bevor jemand aufschreit, ich baue in so ziemlich allen meinen Programmen buildlevel info dazu. Ich habe auch schon checks auf DLLs eingebaut und workarounds für Systeme wo diese nicht gefunden werden. Kurz, ich weiß wovon ich rede. Diejenigen die der Meinung sind, dass sind ja eh nur ein paar Anpassungen hier, ein paar Anpassungen da, die sollen diese doch mal bei einem Projekt probieren. Nur so ein Beispiel, FF und AOO und viel andere sourcen sind verfügbar. Aber auch viel kleinere Projekte. Also es fehlt anscheinend nur jemand der sich hinsetzt und das macht. Warum tut es keiner? Meine persönliche Erklärung, meist sind die die groß reden einfach nicht kompetent genug es zu machen. Oder wollen die alle nicht?

Talk is cheap.
Benutzeravatar
Frank Wochatz
Beiträge: 1112
Registriert: So 22. Dez 2013, 22:04
Wohnort: Berlin
Kontaktdaten:

Beitrag von Frank Wochatz »

Also estmal denke ich, dass die Problematik mit verschiedenen DLL Versionen, die zu Fehlern führen und den Support überlasten weitaus kleiner ist als hier angenommen. Jedenfalls sehe ich in den OS2 Foren vor allem Problme mit RPM und YUM. Und wenn es Probleme mit DLLs gibt, dann scheint es doch oft so zu sein, das die benötigten DLLs einfach fehlen. Die Ursache dafür ist, dass DLLs seperat auf verschiedene Pakete verteilt wurden.

Zweitens wird eine DLL Versionierung ja bereits efolgreich bei Bibliotheken, die häufigen Updates unterliegen vorgenommen! Es stimmt doch überhaupt nicht, dass diese Sachen nicht vorhanden sind. Und das wird - ebenso simpel wie wirkunsgvoll - über den Dateinamen erreicht. zB.:

Code: Alles auswählen

gcc322.dll
gcc335.dll
gcc432.dll
gcc433.dll
gcc434.dll
gcc440.dll
gcc441.dll
gcc442.dll
gcc444.dll
gcc445.dll
gcc446.dll
gcc452.dll
gcc453.dll
gcc473.dll

Da hat doch wohl jemand das Problem erkannt! Das gleiche gilt für libc, kairo etc.pp. Da kann das angesprochende Problem von vornherein garnicht auftreten, und das muss doch wohl die Lösung sein.

Und unterschiedliche DLL-Versionen mit gleichen Dateinamen und ohne interne Versionierung - sorry, aber das darf einfach nicht sein. (gibt es das überhaupt?)

Drittens muß auch über YUM/RPM eine Versionierung erfolgen, oder nicht? Es ist doch nicht so, dass sich eine Identifikation der DLL-Versionen mit YUM/RPM erledigt hat bzw. von alleine funktioniert, auch dort müssen enstprechende Vorkehrungen getroffen werden.

Abschließend find eich schon, dass auch gute Fehlermeldungen mal deutlich weiterhelfen würden. Ich weiss, es ist aus der Mode gekommen. Das es nur nur zwei Entwicklergruppen für OS2 gibt ist für mich ürbigens auch kein Argument für Expertise für solche Design-Entscheidungen. *Zig andere OS2 Entwickler und Firmen haben es anders gemacht, und etliche der Programme setze ich heute noch erfolgreich ein.
Andi B.
Beiträge: 742
Registriert: Di 24. Dez 2013, 16:40
Kontaktdaten:

Beitrag von Andi B. »

Das gleiche gilt für libc,
Nun dann denk doch mal scharf nach z.B. bei der libc063. Tip, es existieren mehrere neuere Versionen als forwarder wegen bugfixes....
*Zig andere OS2 Entwickler und Firmen haben es anders gemacht,
Da fällt mir die ebenfalls hypothetische Frage ein, warum die dann nicht die neue Programme und Portierungen machen? Sorry, diese Aussage ist genauso überflüssig wie solche z.B.: "Mit den Fixpacks von IBM war alles besser". Oder hast du eine Zeitmaschine um das Rad zurückzudrehen?
Benutzeravatar
ak120
Beiträge: 1044
Registriert: Do 8. Mai 2014, 12:50
Wohnort: Demmin
Kontaktdaten:

Beitrag von ak120 »

Andi B. » Do 11. Feb 2016, 10:03 hat geschrieben:Nüchtern betrachtet kommen fast alle Neuerungen und aktuelle Anwendungen direkt oder indirekt von BWW. Also von Silvan, Dmitriy, Yuri... auch in Zusammenarbeit mit z.B. Paul.
Leider ist es noch etwas zu früh, um mir darauf vom Gastwirt erstmal ein Bier bringen zu lassen. ;)
Ich möchte nicht darüber streiten, ob nun ein 70er/80er-Jahre-UNIX-Befehl als "Neuerung" oder gar "aktuelle" Anwendung im OS/2-Sinne aufzufassen ist. Meine Ansicht dazu habe ich oft genug geäußert. Nur bezweifele ich, daß es tatsächlich eine kritische Zielgruppe bzw. einen ernsthafteren Bedarf gibt. Einer der Gründe, warum es überhaupt noch OS/2-Endbenutzer gibt, ist sicherlich die Tatsache, daß eine nicht unbedeutende Anzahl unabhängiger Entwickler und Enthusiasten verbreitete und oft gern genutzte Programme weiterhin im Rahmen der Möglichkeiten pflegt und verbessert.
Neuerungen/Fixes für's Grundsystem sind nur von Arca Noae zu erwarten. Und die arbeiten eng mit BWW zusammen.
Ein Unternehmen wird üblicherweise geführt um Gewinne zu erwirtschaften. Ich kann den Markt in Übersee nicht beurteilen, also erwarte ich besser nicht zuviel.
Und dann noch ein paar Einzelkämpfer wie Lars (exemplarisch genannt, nicht böse sein wenn ich hier andere nicht explizit nenne), die aber auch mehr oder weniger eng mit AN und BWW zusammenarbeiten. Und die sind nun mal alle von den Vorteilen von rpm/yum für unser OS/2 überzeugt, oder besser gesagt, sie wissen, dass dies das kleinere Übel ist verglichen mit dem Wildwuchs der davor entstanden ist.
Natürlich ist es immer vorteilhaft, wenn man Brandstifter und Feuerwehrmann zugleich sein kann.
Das hat seine Gründe welche schon mehrfach diskutiert (von so manchen aber leider nicht verstanden) wurden, die man nicht teilen muss, aber man kann sich damit arrangieren. Blöd schreiben dagegen ohne selbst irgendwas positives an der Verbesserung der Nutzbarkeit unseres Systems beizutragen (ak120) geht leicht, hilft den Usern aber nicht.
Wenn die Rabulistik nicht weiter mehr hilft, muß eben zur Pöbelei übergegangen werden - merci beaucoup menteur!

P.S.
Falls jemand in meinen Beiträgen sachliche und fachliche Fehler entdeckt, bin ich für entsprechende Hinweise sehr dankbar. Aber wenn schon im Vorfeld alles entweder aus dem Zusammenhang gerissen oder bei Bedarf auch komplett verdreht wird, kann ich von keinem ernsthaften inhaltlichen Diskurs mehr ausgehen.
Benutzeravatar
Frank Wochatz
Beiträge: 1112
Registriert: So 22. Dez 2013, 22:04
Wohnort: Berlin
Kontaktdaten:

Beitrag von Frank Wochatz »

Ein OS mit Kleinstbenutzerzahlen, eine riesige Diskussion und ein Jahre dauernder Kraftakt zur Etablierung eines neuen Installers (den kaum einer wirklich will), weil zwei Programmierer keine Lust haben, die drei benötigten DLLs ins Programmarchiv zu kopieren. Das steht alles in keiner Relation, das hat auch nichts mehr mit gesundem Menschenverstand oder Pragmatismus zu tun, ich sehe da auch wenig Attraktivität um Unterstützer zu gewinnen. Ich steig jetzt auch mal aus der Debatte aus, sonst sitzen wir irgendwann bei Anne Will und diskutieren über die Rente.
Benutzeravatar
thorolf
Beiträge: 563
Registriert: Mi 25. Dez 2013, 16:14
Wohnort: Rhein-Main

Beitrag von thorolf »

Frank Wochatz » Do 11. Feb 2016, 16:50 hat geschrieben:Ein OS mit Kleinstbenutzerzahlen, eine riesige Diskussion und ein Jahre dauernder Kraftakt zur Etablierung eines neuen Installers ...
das sehe ich ähnlich.

Ein ordentliches Paket-Management auf einem aktuellen System ist im Prinzip unerlässlich, wenn denn die wirklich wichtigen Dinge funktionieren würden und es Ressourcen gäbe, das sauber zu implementierten. Nicht zu vergessen, es müsste auch eine relevante Anzahl von Paketen dafür vorhanden sein, denn ein Paket-Management bringt überhaupt nichts, wenn nicht ein Großteil der Installierten Treiber, Libs, Programme usw. drin ist.

Auf OS/2 oder irgendeinem der Nachfolger trifft das alles nicht zu, es gibt bereits eine Reihe an Installations-Programmen, WarpIN ist hier sicher das "modernste", was auch mit einer rudimentären Paketdatenbank daher kommt. Ich habe seinerzeit das WPI-Paket für die letzte Papyrus-Version gemacht, das hat ausreichend gut funktioniert.

Im übrigen reicht in 99% der Fälle ein einfaches Rexx-Script um eine Anwendung zu installieren, zur Not kopiert man die Sachen einfach per Hand und legt ein Objekt an. Es kommt ja sowieso eher selten vor, das man unter OS/2 was installieren muss, wenn das System einmal eingerichtet ist.
Grüße,

Thorolf
Benutzeravatar
Sigurd
Beiträge: 994
Registriert: Mo 23. Dez 2013, 08:35
Kontaktdaten:

Beitrag von Sigurd »

Frank Wochatz » Do 11. Feb 2016, 16:50 hat geschrieben:Ein OS mit Kleinstbenutzerzahlen, eine riesige Diskussion und ein Jahre dauernder Kraftakt zur Etablierung eines neuen Installers (den kaum einer wirklich will), weil zwei Programmierer keine Lust haben, die drei benötigten DLLs ins Programmarchiv zu kopieren. Das steht alles in keiner Relation, das hat auch nichts mehr mit gesundem Menschenverstand oder Pragmatismus zu tun, ich sehe da auch wenig Attraktivität um Unterstützer zu gewinnen.
Ich sehe das so - und das ist mein einziger Beitrag dazu - :

Ich verschwende keine Zeit und Energie damit mich über Dinge aufzuregen, die ich ohnehin nicht ändern kann (nicht zuletzt seit dem Disaster mit eCS habe ich es aufgegeben), ich konzentriere mich lieber auf die Suche nach Lösungen und verwende darauf meine Energie. Das klappt jedenfalls ganz gut, vor allem dadurch das mir immer jemand zur Seite springt, schont die Nerven und führt zu so manchem Erfolgserlebnis, wenn ich mir so die letzen Jahre ansehe.
OS/2 versus Hardware - Maximum Warp!
Antworten