Diskussion YUM/RPM (ausgelagert aus eCS 1.2->2.0->2.1->2.2)

(DE) System, Installation, Konfiguration, Hardware, Treiber, Netzwerk, Virtualisierung, etc.
(EN) System, Installation, Configuration, Hardware, Drivers, Network, Virtualisation, etc.
Benutzeravatar
Frank Wochatz
Beiträge: 1112
Registriert: So 22. Dez 2013, 22:04
Wohnort: Berlin
Kontaktdaten:

Diskussion YUM/RPM (ausgelagert aus eCS 1.2->2.0->2.1->2.2)

Beitrag von Frank Wochatz »

ThomasOF » Mo 27. Okt 2014, 21:55 hat geschrieben:Hallo,

was sind eigentlich die wirklichen Unterschiede und Verbesserungen seit eCS 1.2?

[....]
aschn » Mo 27. Okt 2014, 22:26 hat geschrieben: [....]



So lässt sich ein älteres eCS nicht mit eCS-Mittel auf neueren Stand bringen. Natürlich hatte man sich mehr vorgenommen.

Abhilfe könnte RPM/YUM schaffen, das jedoch noch eine GUI braucht, um allgemein akzeptiert zu werden. Trotzdem könnte es bereits im aktuellen Zustand von einem beliebigen Installationsprogramm verwendet werden.
Entschuldigung, aber was soll denn bitte RPM für Probleme lösen? Wenn auf der Baustelle Mauersteine fehlen, dann nützt eine neue Schubkarre auch nichts. RPM bringt erstmal nur neue Probleme. Ich würde sogar sagen, es IST eines der Probleme. Nur leider wird es forciert. Ein paar Dateien von Hand kopieren ist sicher nicht das Ding.

Pragmatisch und realisierbar wäre ein vereinfachtes Verfahren zum Clonen des Basissystems, und dann Pakete für weitere Funktionen bauen , die man upgraden kann. Und dann auf die Mauersteine konzentrieren.
Benutzeravatar
Frank Wochatz
Beiträge: 1112
Registriert: So 22. Dez 2013, 22:04
Wohnort: Berlin
Kontaktdaten:

Beitrag von Frank Wochatz »

aschn » Mi 29. Okt 2014, 19:53 hat geschrieben: Bevor hier jetzt noch weitere Mutmaßungen angestellt werden und das Thema in unerwünschte Bereiche abdriftet


Andreas, das Thema RMP/YUM ist hier im Forum nicht "überwünscht", alles was OS2 betrifft ist erwünscht. Allerdings muss dazu auch ein Kommentar möglich sein, und den werde ich mir auch weiterhin vorbehalten. Welche Probleme RPM nun eigentlich lösen soll, ist immernoch nicht geklärt.
Andi B.
Beiträge: 742
Registriert: Di 24. Dez 2013, 16:40
Kontaktdaten:

Beitrag von Andi B. »

Welche Probleme RPM nun eigentlich lösen soll, ist immernoch nicht geklärt.
Ich hab zwar schon in diversen threads dazu geschrieben, aber gerne nochmal meine unbedeutende Meinung dazu.

Problem, installieren von Software und auflösen der Abhängigkeiten vor allem für diverse dlls die für portierte SW benötigt werden. Aus der Vergangenheit hat man gelernt, bzw. viele wussten es eh aber leider nicht alle, dass man solche dlls keinesfalls mit verschiedenen Apps mitpacken (und in deren Verzeichnis ablegen) darf. Daraus folgte nämlich auch unter OS/2 - eCS die sog. DLL-Hell. User wussten nicht warum manche Programme manchmal funktionierten, manchmal aber nicht. Support durch den Portierer bzw. andere Usern praktisch unmöglich. Selbst die üblicherweise ziemlich computer-affinen OS/2 User schafften es oft nicht, ihre dlls sauber in nur einem Verzeichnis abzulegen.

Lösungsversuch - ein Installer der checked ob die benötigten Dateien vorhanden sind und wenn nicht nachinstalliert und welcher auch alte Versionen durch die aktuelle ersetzen kann. Keiner der bekannten OS/2 Installer kann dies vernünftig. Am besten dafür geeignet für all die portierten Anwendungen schien rpm weshalb es auch genommen wurde.

Natürlich kann man es nie allen Usern recht machen. Aber primär geht's darum, dass die Entwickler die eine Menge Zeit ins portieren reinstecken nicht immer genervt werden mit Fehlermeldungen nur weil wieder jemand doppelte dlls oder alte Versionen rumliegen hat. Auch können die paar verbliebenen OS/2 - eCS Entwickler nicht alle möglichen Installationsvarianten auf einem OS/2 System testen und auch nicht immer alle hardcoded Pfade in den fremden Sourcen (verschiedene Pfade werden unter *nix einfach vorausgesetzt) verbiegen nur weil User X einen anderen Pfad dafür haben will. Ein gewisses Grundgerüst auf welchem man aufbauen kann, hilft da enorm.

Hoffentlich trägt dies dazu bei, dass so mancher rpm/yum nicht mehr ganz so verteufelt. Klarerweise wird dies nicht alle OS/2 User überzeugen, aber der Versuch war's wert.
Benutzeravatar
Frank Wochatz
Beiträge: 1112
Registriert: So 22. Dez 2013, 22:04
Wohnort: Berlin
Kontaktdaten:

Beitrag von Frank Wochatz »

Ich sehe nicht, wie RPM die genannten Probleme auch nur im Ansatz löst. Es ist doch einfach nur eine Technik, um Pakete übers Netz zu installieren.

Auch Warpin löst diese Probleme nicht, aber zumindest ist es bereits verbreitet, und ich erinnere mal daran, wie lange es gedauert hat das Ding zu debuggen bzw. notwenige Features nachzurüsten (Features wie ein Directory Picker fehlen immer noch). Waren es 5 Jahre oder mehr? Jetzt ist es da und funktioniert ganz gut, nun muss was neues her?

Außerdem hat die Problematik mit den DLLs in Wirklichkeit eine völlig andere History:

1. die Entwickler haben angefangen, DLLs nicht mehr in die Pakte zu packen.
2. den Anwendern haben DLLs gefehlt, die jedesmal in Detektivarbeit nachinstalliert werden mussten - das Geschrei war gross
3. dann wurde als Heilmittel RPM eingeführt

Symptom- statt Ursachenbehandlung. Das Problem wäre wirklich weitaus einfacher zu lösen, mit Komplettpaketen mit allen DLLs und von mir aus mit einem Installscript, dass die DLLs synchronisiert. Warum muss das immer alles so kompliziert werden.

Ich wäre dafür, wieder komplette Pakete einzuführen. Das Problem mit den doppelten DLLs kann man nur mit einer Versionskontrolle in den Griff bekommen. RPM funktioniert nur, wenn ich es immer benutze, und nagelt den User damit fest. Deshalb wird das auch immer ein Problem bleiben.

Die DLL Hölle ensteht doch auch erst, weil wir jetzt diverse Locations für DLLs haben.

Entwickler entlasten - bin ich übrigens dafür. Aber RPM muss erstmal portiert und etabliert werden. Wie wärs wenn wir darauf verzichten? Das wäre auch eine Entlastung.

Leider siehts wohl so aus, dass diese Technik zusammen mit dem Linux-Tree mit der Brechstange ins System/2 reingehebelt wird. Für mich eine Rolle rückwärts, dann kann ich auch auf Linux wechseln.

Die angedachte Synchronisierung der DLLs zwischen lokalem System und einem Webverzeichnis heraus ist leider auch im Sande verlaufen. Nachdem zuerst Adrian von Netlabs das Verzeichnis anlegen wollte. Das wäre wirklich mal eine Erleichtung gewesen.
Andi B.
Beiträge: 742
Registriert: Di 24. Dez 2013, 16:40
Kontaktdaten:

Beitrag von Andi B. »

1. die Entwickler haben angefangen, DLLs nicht mehr in die Pakte zu packen.
Das müsste so ca. rund um 1985 gewesen sein. Zumindest seit dieser Zeit sind shared dlls Standard. Und die werden und dürfen natürlich nicht mit jedem Programm mitgeliefert werden.
2. den Anwendern haben DLLs gefehlt, die jedesmal in Detektivarbeit nachinstalliert werden mussten - das Geschrei war gross
Die 'Detektivarbeit' bestand und besteht meist aus dem Lesen der readme.os2 (Ausnahmen bestätigen die Regel. Entwickler vergessen machmal halt auch eine dll und schreiben nun mal nicht gerne readmes). Aber leider sind viel User schon alleine mit dem Lesen der Readme überfordert. Weiters sind die Links darin zu diversen dlls und Paketen oft schon tot wenn der User das Programm installiert. rpm.netlabs wird hoffentlich ewig verfügbar bleiben und könnte deshalb eine Verbesserung sein.
Das Problem wäre wirklich weitaus einfacher zu lösen, mit Komplettpaketen mit allen DLLs und von mir aus mit einem Installscript, dass die DLLs synchronisiert. Warum muss das immer alles so kompliziert werden.
Meinst du wirklich es wäre super wenn bei jedem portierten Programm eine andere Version der z.B. libc mitgeliefert würde? Und der User sollte dann wissen ob er sie löschen muss weil veraltet oder die anderen auf seinem System damit überschreiben? Klar programmatisch dies zu lösen wäre nicht kompliziert WENN jede dieser dlls oder jedes benötigte Hilfsprogramm eine eindeutige Versionskennung HÄTTE. Wer schon mal ein Programm portiert hat und den OS/2 üblichen bldlevel string zugefügt hat weiß, dass das Arbeit und Zeit kostet und deshalb fehlt sowas leider oft. Und selbst wenn man diese Info hätte, müssten ALLE Partitions und ALLE Verzeichnisse nach installierten dlls gleichen Namens durchsucht werden. Bei einem üblichen System würde das für jede dll zig Minuten dauern. Gerade deshalb weil eben manche Leute (User und Entwickler) sharde dlls bzw. Hilfsprogramme in Programmverzeichnissen abgelegt haben.
...Linux-Tree mit der Brechstange ins System/2 reingehebelt wird...
Auch da bin ich anderer Meinung. Ersten wer's nicht will kann's ja sein lassen. Aber wie ich schon schrieb ist dies hauptsächlich deswegen nötig, damit man portierte SW ans Laufen bringt ohne dabei jedesmal alle hardcoded Pfade händisch anpassen zu müssen. Eine Arbeit welche kein Entwickler gerne macht, welche ineffizient und fehleranfällig ist und nur Zeit vergeudet.

Nur ein Beispiel weil's mich selbst betrifft - wer XWLAN3.12 nutzen will, wird höchstwahrscheinlich auch den ISC dhclient brauchen. Wenn ich in die readme schreibe 'yum install dhclient' dann weiß ich, dass die passende, getestete und von mir adaptierte Version verwendet wird. Wenn jemand irgendeine andere Version z.B. aus eine .zip installiert, kein Problem wenn er damit glücklich ist. Aber wenn nicht, dann kann er nicht erwarten, dass ich auch noch meine Zeit mit seiner vermurksten Installation verplempere.

Btw. ich hab auch schon Warpin scripts geschrieben. Warpin ist ja nicht schlecht, aber für XWLAN tu ich mir diese Arbeit sicher nicht an. Christian hat damals einige Zeit in die Installationsscripte reingesteckt. Und wenn's nicht sein muss, wird daran auch nichts geändert. Aber natürlich kann jeder der will daraus ein .wpi machen und dabei gleich alle Abhängigkeiten checken.
Benutzeravatar
ThomasOF
Beiträge: 257
Registriert: Mo 20. Jan 2014, 19:26
Wohnort: Offenbach
Kontaktdaten:

Beitrag von ThomasOF »

Hallo,

also ich finde es zumindest gut dass es YUM/RPM überhaupt gibt und dass man so einigen Freiraum aus der Linux-Welt nutzen kann. Auch wenn das nun nicht gleich alle Probleme löst ist OS2/eCS meiner Meinung nach mit YUM schon mal besser als ohne.

Um der DLL-Hölle zu entfliehen hilft m.E. nur Standardisierung, aber das wäre auch ein langer Prozeß und wer will den durchsetzen. Und ein readme zu lesen ist doch so aufwändig nicht und bringt auch immer einen Gewinn.

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

Beitrag von Frank Wochatz »

Leute, man kann sich das auch schön reden, und hier wird auch alles mögliche durcheinander gewürfelt.

Ist doch völlig egal, welche Art von Link im Readme steht. Was ist das denn für ein Argument? Hauptsache es steht drin (und gegen Readmes ist auch nichts einzuwenden, ganz im Gegenteil). Ist doch auch Unsinn, das man nur mit RPM korrekte Pakete an den korrekten Platz installieren kann, oder das die Weblocation von RPM Paketen irgendwie sicherer oder länger verfügbar ist, als eine andere Weblocation von einem WPI.

Fehlt nur noch, dass jemand sagt RPM sei "alternativlos".
Benutzeravatar
ak120
Beiträge: 1044
Registriert: Do 8. Mai 2014, 12:50
Wohnort: Demmin
Kontaktdaten:

Beitrag von ak120 »

RPM ist schon ganz in Ordnung. Letztlich sind es auch nur cpio-Archive mit einigen Zusätzen. Der verursachte Unmut liegt jedoch bei YUM. Dieses erfordert schon allein eine Python-Umgebung mit zusätzlichen Abhängigkeiten. Für die gleiche Funktionalität ließe es sich sicherlich für OS/2 auch eleganter in Rexx lösen, aber das ist für Programmierer vielleicht zu langweilig.
Andi B.
Beiträge: 742
Registriert: Di 24. Dez 2013, 16:40
Kontaktdaten:

Beitrag von Andi B. »

Ist doch völlig egal, welche Art von Link im Readme steht. Was ist das denn für ein Argument? Hauptsache es steht drin
Das Argument war, dass viele User die readmes gar nicht lesen geschweige den berücksichtigen. Wenn man so manche Diskussion verfolgt meint man, manche wäre auch noch stolz darauf. Und viele Problem der letzten Jahre von diversen Usern rühren genau daher.
Leute, man kann sich das auch schön reden, und hier wird auch alles mögliche durcheinander gewürfelt.
Zu meinem Hauptargument - portierter SW eine Umgebung geben damit diese überhaupt läuft - gibt's noch immer kein Gegenargument. Was daran schön reden sein soll, weiß ich nicht. Was wäre eine mögliche Alternative? Z.B. alle dlls in \os2\dll oder ecs\dll? Vergiss es. In meinem /usr/lib liegen über 7000 Dateien und mehr als 330MB. Nie und nimmer will ich das am Bootdrive in einem Standard OS/2 Verzeichnis haben.

Je mehr über yum/rpm in diversen Foren diskutiert wird desto mehr verstärkt sich mein Eindruck, es wird hauptsächlich gelästert weil es neu und anders ist. War bei mir übrigens genauso. Ich wollte rpm auch anfangs nicht. Nur, man muss nicht unbedingt alles Neue verteufeln. Schon gar nicht wenn man keine Ahnung davon hat (=allgemein formuliert, soll kein Angriff auf bestimmte Personen sein) sollte man sich vorher informieren und die Alternativen vergleichen bevor man bashing betreibt. Oder ganz pragmatisch zugegen, dass so mancher Entwickler sich bei gewissen Themen viel besser auskennt als man selbst. Man darf manchmal auch darauf vertrauen, dass ein Entwickler seine Entscheidungen gut überlegt und besser weiß wie er ein Problem in den Griff bekommt. Zumindest ich versuche mir diese Einstellung zu bewahren. Nachdem für mich geklärt war, dass rpm nicht unbedingt am Bootdrive seine Dateien unterbringen muss, hab ich es einfach ausprobiert. Und jetzt lebe ich halt damit und verstehe die Ablehnung dagegen nicht mehr.
Für die gleiche Funktionalität ließe es sich sicherlich für OS/2 auch eleganter in Rexx lösen, aber das ist für Programmierer vielleicht zu langweilig.
Oder vielleicht zu aufwendig? Warum macht das keiner? Rexx kann doch jeder. Warum programmiert sowas keiner? Wer sind die Programmierer die sich von yum/rpm Vorteile erhoffen? Wollen wir ernsthaft, dass z.B. Yuri statt an AOO zu arbeiten eine weiteren Rexx Installer schreibt? Oder soll Dmitriy statt an FF und git und autoconf und QT und Java und ... sich lieber seine Zeit mit Rexx scripten vertreibt? Oder sollte wir David statt für ACPI und Multimac und Uniaud und ... zu bezahlen lieber Warpin scripte basteln lassen? (Hypothetische Fragen die zum Nachdenken anregen sollen. Wir hier haben kaum ein Mitspracherecht und können dies nur indirekt über Geldleistungen beeinflussen)

So hart es klingt, wer's besser kann und weiß, der soll's doch gefälligst machen. Und wenn's mir gefällt, dann zahle ich auch dafür. So wie ich es die letzten Jahre gehalten habe. Aber da bis jetzt noch keiner mit einer besseren Lösung vorgeprescht ist, nehme ich halt die die verfügbar ist.
Benutzeravatar
aschn
Beiträge: 1363
Registriert: Mi 25. Dez 2013, 22:47

Beitrag von aschn »

Ich glaub die Gründe, weshalb Nutzer sich gegen die einzige heutzutage brauchbare Paketverwaltung, die für unser OS existiert, wehren, sind folgende:
  • Die Paketverwaltung YUM braucht selbst ein für OS/2-Verhältnisse riesiges FHS-System mit Python-Umgebung. Andreas Kohl hat es bereits genannt.
  • Die Installation von Paketen klappte in der Vergangenheit häufig nicht oder es wurden fehlerhafte Dateien installiert. Die RPM-Dateien sind also nicht sorgfältig genug erstellt worden, wofür YUM nichts kann.
  • Keiner möchte unbekannte Dateien (das FHS-System) auf seinem System haben, die er selbst aber niemals bewusst nutzen will oder wollte.
Leute suchen nach Auswegen, verteufeln RPM und YUM und basteln stattdessen vereinzelt WarpIN-Pakete, was nur wieder zu neuen Problemen bei den nächsten Updates führt.

RPM/YUM ist bisher die einzig existierende Möglichkeit für Nutzer eine definierte Umgebung herzustellen (Andi hat es gesagt). Damit bedeutet es für von Linux portierte Software eine extreme Arbeitserleichterung für die Entwickler. Sie brauchen sich beim Support nur auf die definierte, für alle nachvollziehbare Umgebung konzentrieren. Für etwas anderes fehlen uns die Ressourcen. Alles andere mag auch funktionieren, muss aber nicht mehr von den Entwicklern unterstützt werden.

RPM/YUM könnte aber noch mehr: Es wäre denkbar, das gesamte OS/2 und eCS damit zu verteilen, auch wenn wegen Lizenzgründen vielleicht einiges erst on-the-fly erzeugt werden müsste. Damit würde die OS/2-Neuinstallation der Vergangenheit angehören und jeder könnte sofort Neuerungen testen und auf einfachste Weise wieder deinstallieren.

Es ist eigentlich völlig egal, welche Paketverwaltung man dafür nimmt. Yuri hat jetzt nun mal RPM und dann YUM portiert. Ein anderes System existiert bisher nicht für OS/2.

Mit WarpIN wäre das nur theoretisch, mit eigener REXX-Skriptbibliothek, möglich. Bisher hat sich keiner diesem Aufwand gestellt, Andi hat es erwähnt.
Andreas Schnellbacher
Benutzeravatar
Frank Wochatz
Beiträge: 1112
Registriert: So 22. Dez 2013, 22:04
Wohnort: Berlin
Kontaktdaten:

Beitrag von Frank Wochatz »

RPM/YUM könnte aber noch mehr: Es wäre denkbar, das gesamte OS/2 und eCS damit zu verteilen,
Jetzt machst Du mir echt Angst. Die Frage ist, ob man das wirklich braucht. ich habe keinen 7000 Linux-DLLs auf meienr Platte. Wieviele Leute werden wohl am Ende übrig bleiben, die sowas dann benutzen? Ich meine außer denen, die eigenlich sowieso Linux benutzen und ein wenig mit eCS spielen.

Klar kann man keine Ansprüche oder Forderungen an die Open Source Entwickler stellen, da stimme ich zu. Trotzdem muss man auch nicht alles gut finden, nur weil es grad OS ist. Und "Die Entwickler werden schon recht haben" ist ein Totschlagargument, dass jede Diskussion überflüssig macht. Die Partei hat immer recht, oder wie. :)

Allerdings glaube ich, dass auch eigentlich keine richtige Diskussion stattfindet, denn das hier zu besprechen hat ja keine Relevanz. Insofern: wird schon! Und: Muss ja! :(
Benutzeravatar
aschn
Beiträge: 1363
Registriert: Mi 25. Dez 2013, 22:47

Beitrag von aschn »

Frank Wochatz » So 2. Nov 2014, 21:34 hat geschrieben: Klar kann man keine Ansprüche oder Forderungen an die Open Source Entwickler stellen, da stimme ich zu. Trotzdem muss man auch nicht alles gut finden, nur weil es grad OS ist. Und "Die Entwickler werden schon recht haben" ist ein Totschlagargument, dass jede Diskussion überflüssig macht. Die Partei hat immer recht, oder wie. :)
Wie Andi schon gesagt hat: Mach es selbst besser. Ohne Linux-Portierungen zu leben, würde bedeuten auf folgendes zu verzichten:
  • YUM ;-)
  • Mozillen
  • OpenOffice
  • Java
  • Qt-Anwendungen
  • OpenSSL
  • GCC
  • MultiMac
  • AHCI
Viel Spaß mit so einem System in der heutigen Zeit. ;-) Nebenbei: Ich bin überhaupt nicht der Meinung, dass ehemalige, nicht auf Portierungen basierte OS/2-Anwendungen weniger produktiv sind, sondern ganz im Gegenteil: Ich halte diese aktuellen Monsterpakete für viel zu aufgebläht, wobei die Hersteller mit immer neuen Dateiformaten wie eh und je versuchen alte Software lahmzulegen. Bei den Mozillen fällt mir dagegen aber auch kein Feature ein, auf das ich verzichten wollte und was gleichzeitig das Paket wesentlich schlanker machen könnte.
Andreas Schnellbacher
Andi B.
Beiträge: 742
Registriert: Di 24. Dez 2013, 16:40
Kontaktdaten:

Beitrag von Andi B. »

Und "Die Entwickler werden schon recht haben" ist ein Totschlagargument, dass jede Diskussion überflüssig macht. Die Partei hat immer recht, oder wie. :)
Solange nicht mehr kommt als diffuse Behauptungen ohne vernünftige Argumentation, ja.

Nicht der Entwickler der mir AOO lauffähig auf mein Lieblings-OS liefert muss für mich beweisen dass er Recht hat. Sondern derjenige der behauptet das sei alles Quatsch, sollte nachvollziehbar argumentieren, warum er anderer Meinung ist.
Benutzeravatar
Frank Wochatz
Beiträge: 1112
Registriert: So 22. Dez 2013, 22:04
Wohnort: Berlin
Kontaktdaten:

Beitrag von Frank Wochatz »

Andi, da bis jetzt auch alles ohne RPM/YUM funktioniert, sollte Argument genug sein, dass wir diese problematische Software nicht unbedingt brauchen. Und da es genug andere Software gibt, die komplett ausgeliefert wird bzw. wo die DLLs auch im System-DLL-Verzeichnis liegen dürfen, ist denke ich auch ein Argument. Fixe Trees sind für mich eine Rolle rückwärts.

Ich brauche übrigens auch kein Warpin, ich habe die unglaublichen Skills, ein Zipfile alleine auszupacken. Und was im WPI ev. noch ausgeführt wird, ließe sich schneller in ein Rexxscript bauen (oftmals wird Warpin einfach als Entpacker benutzt).

Eine Versionskontrolle mit Warpin oder RPM hinzubekommen ist eine Illusion. Das würde erstmal bedeuten, dass nur noch das eine oder andere Tool für wirklich alle Komponenteninstallation benutzt wird.

Btw, ev. habe ich eine selektive Wahrnehmung, aber ich lese eigentlich sehr selten über Probleme mit doppelten DLLs in den Foren. Ich glaube auch, dass die meisten OS2 User sich ganz gut auskennen. Was ich oft lese ist, dass Leute die Programme nicht starten können, weil DLLs fehlen, weil entweder die Doku unvollständig ist, oder sie zu faul sind diese zu lesen. Beide Probleme löst doch aber nicht der Paketmanager!

Andreas, ich bin überhaupt nicht gegen Linuxportierungen, auch wenn ich das meiste aus Deiner Liste in der Tat nicht benutze. Ich kann mir DLLs aber auch selber ins DLL Verzeichnis kopieren, dafür brauche ich keinen problematischen Packetmanager. Und bislang geht das zum Glück auch alles so.
Wie Andi schon gesagt hat: Mach es selbst besser.
Ja friß oder stirb, ist schon klar. Ein diskussionfeindliches Statement erster Kajüte. Soll ich noch eine devote Körperhaltung einnehmen? Übrigens habe ich angeboten, dass ich bei Netlabs ein Verzeichnis anlege, wo ich alle DLLs reinkopiere, und das sich die Leute synchronisieren können. Und übrigens gibts bei meinen Programmen kein RPM.

Erfreulicherweise hat Arca Noa angekündigt, neben RPM auch WPI Pakte für die Neuentwicklungen anzubieten (was auch nochmal ahnen lässt, das RPM nicht wirklich benötigt wird). Das lasse ich jetzt mal als letzten Satz zu dem Theme von meiner Seite so stehen.
Benutzeravatar
ak120
Beiträge: 1044
Registriert: Do 8. Mai 2014, 12:50
Wohnort: Demmin
Kontaktdaten:

Beitrag von ak120 »

Zu meinem Hauptargument - portierter SW eine Umgebung geben damit diese überhaupt läuft - gibt's noch immer kein Gegenargument. Was daran schön reden sein soll, weiß ich nicht. Was wäre eine mögliche Alternative? Z.B. alle dlls in \os2\dll oder ecs\dll? Vergiss es. In meinem /usr/lib liegen über 7000 Dateien und mehr als 330MB. Nie und nimmer will ich das am Bootdrive in einem Standard OS/2 Verzeichnis haben.
Von diesen vielen installierten Dateien sind etliche völlig unnötig. Die wenigsten Endbenutzer brauchen die zahlreichen Übersetzungen unter \usr\share\locale (das sind schon über 10 MB). Nirgends ist dokumentiert, wie und ob es überhaupt nutzbar ist. Und ohne geeignetes Leseprogramm kann ich mir leider nicht mal die russische Manpage zu RPM ansehen. Früher war es noch üblich die Manual-Seiten als lesbaren Text oder INF-Datei mitzuliefern. Die Liste ließe sich weiter fortsetzen.

Solange die zur Verfügung stehenden Möglichkeiten nur halbherzig genutzt werden, sind die schnellen Hacks keine ernsthaften Portierungen. Aktuelle Anwendungen sind daher im Moment nur noch in virtuellen Maschinen und/oder über Remote Desktop unter OS/2 produktiv nutzbar.
_diver
Beiträge: 306
Registriert: Fr 27. Jun 2014, 10:57

Beitrag von _diver »

ak120 » Mo 3. Nov 2014, 16:27 hat geschrieben:
Zu meinem Hauptargument - portierter SW eine Umgebung geben damit diese überhaupt läuft - gibt's noch immer kein Gegenargument. Was daran schön reden sein soll, weiß ich nicht. Was wäre eine mögliche Alternative? Z.B. alle dlls in \os2\dll oder ecs\dll? Vergiss es. In meinem /usr/lib liegen über 7000 Dateien und mehr als 330MB. Nie und nimmer will ich das am Bootdrive in einem Standard OS/2 Verzeichnis haben.
Von diesen vielen installierten Dateien sind etliche völlig unnötig. Die wenigsten Endbenutzer brauchen die zahlreichen Übersetzungen unter \usr\share\locale (das sind schon über 10 MB). Nirgends ist dokumentiert, wie und ob es überhaupt nutzbar ist. Und ohne geeignetes Leseprogramm kann ich mir leider nicht mal die russische Manpage zu RPM ansehen. Früher war es noch üblich die Manual-Seiten als lesbaren Text oder INF-Datei mitzuliefern. Die Liste ließe sich weiter fortsetzen.

Solange die zur Verfügung stehenden Möglichkeiten nur halbherzig genutzt werden, sind die schnellen Hacks keine ernsthaften Portierungen. Aktuelle Anwendungen sind daher im Moment nur noch in virtuellen Maschinen und/oder über Remote Desktop unter OS/2 produktiv nutzbar.
Hmm wenn das so ist, dann frage ich mich schon so langsam aber sicher was wir tagtäglich machen.
Jeder darf seine Meinung haben, das ist klar, aber dass die Portierungen halbherzig sind, finde ich eine Frechheit.
Jeder der soetwas behauptet, soll bitte selbst etwas dazubeitragen, dass sie besser werden. Nur herumjammern bringt nämlich genau gar nix!!!!

Gruss
Silvan
Andi B.
Beiträge: 742
Registriert: Di 24. Dez 2013, 16:40
Kontaktdaten:

Beitrag von Andi B. »

Aktuelle Anwendungen sind daher im Moment nur noch in virtuellen Maschinen und/oder über Remote Desktop unter OS/2 produktiv nutzbar.
Ich zähle zu aktuellen Anwendungen z.B.
AOO 4.1
PSI0.16
QPDFview0.4.10
Seamonkey2.14
luckyBackup
kDiff3
Apache + .....
cups
Ghostscript
sowie diverse Java Apps z.B.
SmartSVN
SmartSync
OpenFire
...
Warum diese nur in virtuellen Maschinen nutzbar sein sollten, verstehe ich nicht.
Benutzeravatar
aschn
Beiträge: 1363
Registriert: Mi 25. Dez 2013, 22:47

Beitrag von aschn »

Frank Wochatz » Mo 3. Nov 2014, 08:19 hat geschrieben: Ich kann mir DLLs aber auch selber ins DLL Verzeichnis kopieren, dafür brauche ich keinen problematischen Packetmanager. Und bislang geht das zum Glück auch alles so.
Na dann ist ja alles gut. Ich dachte schon, Du würdest das auch von den Entwicklern verlangen.
Andreas Schnellbacher
Benutzeravatar
Sigurd
Beiträge: 995
Registriert: Mo 23. Dez 2013, 08:35
Kontaktdaten:

Beitrag von Sigurd »

Ich möchte hierzu gerne auch meine Meinung kund tun.

Zunächst einmal finde ich es überaus positiv, dass eine weitere Firma für OS/2 gegründet wurde. Hier kommen sich dann nicht zwei Firmen ins Gehege sondern ergänzen sich sehr gut - wenn ich es richtig verstanden habe - so ist Bitwise in Zukunft wohl für die Software zuständig, während Arche Noah an Treibern werkelt. Insofern ist es also die Firma Bitwise, der wir es zu verdanken haben, wenn es überhaupt noch größere Softwarepakete für OS/2 geben soll, bzw. das überhaupt noch welche vorliegen. Ich kann von dort für mich nur gutes erkennen - die angenommenen Projekte, z.B. JAVA usw. wurden immer sehr zielstrebig und mit Rückmeldungen an die User verfolgt und zeitnah umgesetzt. Vor allem kam dabei auch immer etwas wirklich nutzbares heraus.

Ob man mit OS/2 noch sinnvoll arbeiten kann, das wird sicher jeder anders beurteilen und entscheiden, je nachdem, welchen Zweck an Arbeit er/sie verfolgt und was dafür benötigt wird. Auch wenn meine Dinge richtigerweise als "Hobby" betrachtet werden, so bin ich doch der Meinung, dass ich mit dem Sony Vaio Pro 13 in Verbindung mit OS/2 große Teile meiner Freizeitcomputernutzung abdecken könnte.

Was ich persönlich noch benötigen würde, wären WLAN Treiber, ein funktionierender Firefox samt Flash und einen neuen UNIAUD Treiber sowie Grafiktreiber. Natürlich sind dies noch viele Dinge, aber ich sehe es so dass diese wenn überhaupt nur realistisch betrachtet von diesen beiden neuen Firmen kommen könnten (ACPI funktioniert, USB funktioniert, Panorama eigentlich auch recht schnell, mit Open Office 3.2 kann man auch noch aktuell gut arbeiten, für die Spiele, die ich auf einem Laptop spiele reichen auch SCUMMVM und DOSBOX, die "richtigen" lohnen sich eh nur auf einem Desktop PC). Andere wiederum werden es für absurd halten OS/2 auf so einem Laptop zu betreiben, aber so ist es eben. Deshalb habe ich bei den Treibern die Hoffnung auch noch nicht aufgegeben, Arche Noah ist vermutlich ohnehin die letzte Chance dafür. Und es ist vielleicht auch etwas anders, wenn man OS/2 einmal LIVE auf diesem Laptop sehen würde, dazu gibt es ja bei Interesse in Köln Gelegenheit!

Und von daher ist es mir persönlich eigentlich egal, ob da nun ein Linuxbaum vorhanden sein muss oder nicht - ich war auch zunächst sehr reserviert gegenüber YUM/RPM- zu kryptisch erschien es mir. Nachdem ich mich aber ein bisschen damit beschäftigt hatte - und vor allem nachdem ich sehr kurzfristig bereits von Silvan eine Antwort auf ein bei mir entstandenes Problem bekommen hatte - komme ich doch damit gut zurecht.

Natürlich wäre es schön, wenn man das ganze unter einer grafischen OS/2 Oberfläche "verschwinden" lassen könnte, dann wäre der "Schmerz" der Nutzung vielleicht etwas geringer.

Letztlich bin ich aber der Meinung - wenn die Entwickler bei Bitwise meinen, dass dies eine gute Voraussetzung für die Portierung von Anwendungen schafft, dann ist es für mich OK, denn ich bin froh, wenn es überhaupt in eine Richtung weitergeht. Es geht doch eigentlich jeder so vor - ich zum Beispiel benutze auch die aufgebohrte Warp 4 Version lieber als eCs, weil ich dort auf die ganzen ecosoft runtimes etc. verzichten kann. Anderen dürfte dies wiederum vollkommen egal sein oder nutzen gerne die eCS weil die ecosoft Dinge dabei sind. Ist doch OK. Bitwise macht wenigstens was und ich akzeptiere dann auch was dazu vorgegeben wird.

Den Gedanken die WPS auf einen Linux Unterbau zu setzen fand ich auch sehr gut. Leider wird das wohl nichts, aber ich glaube die Strategie von Arche Noah ist bei den Treibern ähnlich - man versucht Bedingungen zu schaffen, die BSD Treiber unter OS/2 nutzbar zu machen und zwar ohne diese ständig ändern zu müssen. Vermutlich so eine Art Wrapper wie GENMAC es ist.

Ich finde wir sollten das etwas ruhiger angehen, niemand ist doch gezwungen YUM/RPM zu benutzen, ich habe es jedenfalls in meine "Klone" mit aufgenommen und freue mich schon auf das Usertreffen in Köln, um darüber Gedanken mit anderen auszutauschen!
OS/2 versus Hardware - Maximum Warp!
Benutzeravatar
aschn
Beiträge: 1363
Registriert: Mi 25. Dez 2013, 22:47

Beitrag von aschn »

ak120 » Mo 3. Nov 2014, 16:27 hat geschrieben: Von diesen vielen installierten Dateien sind etliche völlig unnötig.
Richtig. Aber was würde es bringen? Plattenplatz?

Für mich sieht es so aus, dass sich die Entwickler auf eine kleinere Anzahl beschränken wollen, als jedesmal auch z.B. ein Runtime-Paket anzubieten.
ak120 » Mo 3. Nov 2014, 16:27 hat geschrieben: Die wenigsten Endbenutzer brauchen die zahlreichen Übersetzungen unter \usr\share\locale (das sind schon über 10 MB). Nirgends ist dokumentiert, wie und ob es überhaupt nutzbar ist. Und ohne geeignetes Leseprogramm kann ich mir leider nicht mal die russische Manpage zu RPM ansehen. Früher war es noch üblich die Manual-Seiten als lesbaren Text oder INF-Datei mitzuliefern. Die Liste ließe sich weiter fortsetzen.

Solange die zur Verfügung stehenden Möglichkeiten nur halbherzig genutzt werden, sind die schnellen Hacks keine ernsthaften Portierungen.
Dann nutz sie doch einfach nicht. Mein Entwickler soll sich lieber auf das Wesentliche beschränken als überflüssige Dateien auszusortieren. ;-)
Andreas Schnellbacher
Benutzeravatar
Frank Wochatz
Beiträge: 1112
Registriert: So 22. Dez 2013, 22:04
Wohnort: Berlin
Kontaktdaten:

Beitrag von Frank Wochatz »

"Halbherzig" würde ich Portierungen nicht nennen. Erstmal unterstellt das eben eine negative/fehlende Einstellung des Entwicklers, und Probleme sind doch eher Ressourcenprobleme, so dass eben diverse Portierungen sagen wir mal nicht vollständig sind (was keine Kritik, sondern eine Feststellung ist).

Außerdem ist der Stand der Portierungen bei unterschiedlichen Projekten auch unterschiedlich weit fortgeschritten. Ghostscript beispielweise funktioniert hier ausgezeichnet, während andere Programme oft erstmal starten, Probleme aber dann auftreten, wenn man mal richtig was damit machen will. Und da addieren sich eben auch Probleme der Originalversion mit möglicherweise unvollständiger Portierung bzw. OS2 spezifischen Problemen. Beispielweise habe ich zZ. Probleme mit Image Magick, und ich glaube niemand wird die jemals beheben. Was glaube ich auch daran liegt, das es zwar Leute gibt, die wissen wir man Portierungen macht, aber sich mit den Programmen selbst dann doch nicht so gut auskennen.

Wenn ich mir was wünschen könnte, und das ist durchaus konstruktiv gemeint: weniger Portierungen, dafür aber mehr Tests und Debugging. Ich denke, es gibt einfach zu viele Baustellen. Ob man das koordinieren kann, weiss ich nicht. Null-Aussagen wie "dann machs selber" oder "dann benutz es halt nicht" kehren jedenfalls die Probleme nur unter den Tisch. Wenn die Programme nicht für User sind, kann man sich alles gleich spraren.

Da ist natürlich jeder eingeladen, mitzumachen. Ich persönlich kann das nicht, sage ich ganz offen.

Allerdings hat das alles nichts mit RPM zu tun. RPM ist nicht der Treiber oder die Software, das ist nur ein Downloadmanager. Ich sags gerne zum dritten mal: ich hab nichts gegen Portierungen. Aber es ging auch immer ohne RPM und ohne sich einen gigantischen Linuxtree aufzuspielen. Auch in den Produkten von Bitwise wie Firefox brauche ich das bislang erfreulicherweise nicht. Für einen Linuxtree und statische Verzeichnisse gibt es gute Boardmittel wie Environment-Setups, und eine DLL-Versionsabfrage wird durch RPM auch nicht überflüssig.
ajunra
Beiträge: 375
Registriert: Mo 23. Dez 2013, 06:40
Wohnort: Insel Rügen

Beitrag von ajunra »

Hallo,
mir juckt es schon ewig in den Fingern etwas bei diesen Diskussionen zu schreiben, aber irgendwie hab' ich mir bisher gesagt daß ich eindeutig zu wenig Ahnung davon habe und schließlich ja auch kein Programmierer bin und mich deshalb besser da raus halte. Aber hier werden jetzt Vermutungen angestellt warum ein Nutzer RPM/YUM nicht mag bzw. akzeptiert - und ein Nutzer bin ich nun mal auch - deshalb hier nun doch (in unsortierter Reienfolge) mein Senf:

Ich konnte und kann mich mit RPM/YUM nicht anfreunden, weil es zum einen einen riesen Wasserkopf mit sich rumschleppt.
In Ordnung; bei heutigen Plattenpreisen kein Monetäres Argument, jedoch habe ich hier Rechner zum einen schon seit Jahren (2009/2010) zu laufen und die sind somit auf so ein Monster nicht vorbereitet, will sagen daß die schöne Trennung System (1 GB) + Daten (Rest) mal wieder verwaschen wird. Eigentlich gehören für mich Installationsprogramme; Systemwartungsprogramme sowie die von vielen Programmen gemeinsam genutzten DLLs aufs Startlaufwerk. Nutze ich nun RPM, habe ich entweder die DLL und damit RPM auf dem Startlaufwerk und somit (da es ja dann UNIXROOT ist) kein Platz mehr (z.B. der Thunderbird Posteingang möchte ja dort seine Mails ablegen) oder ich schmeiße eben alles auf Datenlaufwerk - Trennung adè. Zugegeben; das ist eher ein generelles Problem von Linux bzw. Portierungen von dort - unschön ist es allemal.

Zum anderen: RPM/YUM muss kryptisch mit Kommandozeile bedient weren. Einer der Gründe lieber OS/2 als Windows zu benutzen war für mich, daß ich viel mehr mit der grafischen Oberfläche machen konnte. Das war zu Zeiten von 2.1. OS/2 2.1 wohlgemerkt. Na ja, ich war jung. An der Bequemlichkeit hat sich seitem aber nichts geändert. Ich kann mich einfach nicht mit Ellenlangen Parametern welche man in der Kommandozeile eingibt, anfreunden. Ich bin jemand der - wenn man etwas mehr als einmal benötigt - lieber einmalig in ein Objekt auf der Arbeitsoberfläche anlegt als zweimal den Rattenschwanz eintippen.
Ja, ich bin ein Mausschubser!

Auch die Notwendigkeit einer Internetverbindung stört mich nicht wenig. Kann man auch ein Lokales Verzeichnis als Quelle angeben? Daß man also zb. ein fernes Verzeichnis (von z.B. Netlabs) kopiert und per USB nutzt? Hätte den Vorteil einer Offline-Verügbarkeit (wie viele gute OS/2 Netzadressen sind im Laufe der Zeit unvermittelt verschwunden...? kiew.ua etc.) und zum anderen kann man so evtl. Kosten senken: Nicht überall liegt DSL an; manch einer (wie ich) muss Internet per Funk nutzen, und dort gibt es - zumindest bezüglich angenehmer Geschwindigkeit - eine Volumenbegrenzung.

Aber da wäre dann auch schon der nächste Punkt: da es eben keine grafische Oberfläche gibt und man möglichst nichts falsch machen will, ist man gezwungen die Umfangreichen Anleitungen zu lesen. Und die gibt es meines Wissens nach nur auf englisch. Das mag für Entwickler - welche nahezu täglich mit englischer Fachliteratur usw. umgehen - durchaus ausreichend und nützlich sein - für nicht englischsprachige Endnutzer ist es dank des fachlichen Vokabulars eher ein Krampf. Ich denke, das ist nicht nur für deutsche Nutzer so. Und das um ggf. nur ein Programm zu installieren...

Das wäre alles ja noch halb so wild wenn rpm/yum mit eCS mitinstalliert werden würde. Da man es in der Regel nunmal später nachträglich auf den Rechner bringt, hat man mit hoher wahrscheinlichkeit wieder einige DLLs doppelt welche auch nicht auf diesem Wege aktualisiert werden.

Nun ja, meine Argumente klingen Fadenscheinig - und ja: sie sind es auch. Aber es ist eben das, was mich daran stört.
Ich bin mir vollständig bewusst daß es - wie in anderen Kommentaren ausgeführt - wohl der einfachste Weg für Portierer ist, der Sache Herr zu werden. Zumal (wie ich bei Paul Smedleys Warpstock-Beitrag las) viele Portierer gar keine Entwickler/Programmierer sind! Ich akzepiere das und finde es klasse daß sie sich überhaupt die Arbeit machen, Programme für uns verfügbar zu machen! Nur: mögen muss ich diese Lösung deshalb nicht.

Wenn ich das richtig verstand, soll es ja bald eine grafisch Oberfläche geben und in einem Kommentar (nicht jedoch bei den öffentlichen Lies.mich- Dateien) las ich auch etwas davon, daß das ganze in der (hoffentlich) kommenden eCS eingebunden ist. Das würde in meinen Augen schon mal die größten Hindernisse umschiffen bzw. beseitigen.
Ich für meinen Fall habe es nunmehr schon über einen Monat auf der Platte eines meiner Rechner - ohne es jedoch richtig verstanden zu haben. Schön ist das nicht, denn im Allgemeinen kann ich jemanden zu benutzter Software auch etwas sagen/erklären. Hier kenn ich nur das Ergebnis - also den Zweck des Programms, nicht jedoch das wie-womit-wodurch. Ich komm mir dabei vor wie ein Wind-Nutzer. Man braucht keine Ahnung zu haben was man tut, Hauptsache man tut etwas.

Im Grunde halte ich es aber mit dem alten Fritz: Jeder solle doch nach seiner eigenen Façon selig werden. Ich verstehe nicht so ganz wieso manch einer sinngemäß behauptet 'man könne eCS nicht (mehr) benutzen' oder 'rpm/yum ist nicht zumutbar'. Das solle doch jeder für sich entscheiden! Natürlich wird ein gewisser Zwang ausgeübt, wenn mache Programme nur über die eine oder andere Weise verfügbar sind, aber wer zwingt dazu gerade dieses Programm zu nutzen? Wenn ich mir schon (ohne Auftrag) die Arbeit mache etwas zu Programmieren oder Portieren, sollte das wie (ich es mache) doch auch mir überlassen bleiben.
Das ist in meinen Augen doch alles legitim - warum sich darüber aufregen? Wobei auch das sich Aufregen in Ordnung ist, solange man niemanden bevormundet oder gar beleidigt oder kränkt.
Genug geschwafelt!
Schöne Grüße von Deutschlands größter Insel
ajunra
Andi B.
Beiträge: 742
Registriert: Di 24. Dez 2013, 16:40
Kontaktdaten:

Beitrag von Andi B. »

...einen riesen Wasserkopf mit sich rumschleppt...
Meine 330MB enthalten auch so einiges was man als User nicht braucht. Aber trotzdem, auf der Bootpartition wären mir auch z.B. 200MB zu viel. Auf meiner "Programme" Partition hingegen fallen die paar MBytes nicht ins Gewicht. Wie du ja schreibst ist es Ansichtssache wo man diese Daten haben will. Für mich gehört's zu "Progamme" und nur die 3 Pfadeinträge in die config.sys. Denn alles was unter %unixroot% drinnen ist, brauche ich bei einer Systemherstellung nicht unmittelbar sondern kann leicht später wiederhergestellt werden.
(z.B. der Thunderbird Posteingang möchte ja dort seine Mails ablegen)
Ich verwende Seamonkey und die Emails liegen da im Profil Verzeichnis. Bei mir auf der Datenpartition. Nicht unter %unixroot% und auch nicht im %home% Verzeichnis. Sollte das bei Thunderbird anders sein?
RPM/YUM muss kryptisch mit Kommandozeile bedient weren.
Ja ein GUI Frontend ist zwar schon lange geplant, aber es gibt noch immer keins. Andererseits, mehr als 'yum update' braucht man sich üblicherweise nicht zu merken. Und wenn was nachinstalliert werden muss, dann steht das eh genau in der readme wie z.B. 'yum install libc'. Mehr sollte es nicht sein.

Btw. ein Hauptgrund warum ich OS/2 viel lieber als Win oder *nix mag ist, weil ich fast alles sowohl über GUI als auch über CLI machen kann und ich es mir selbst aussuche, welchen Weg ich gerade lieber gehe. Aber wie du richtig schreibst, ist das nicht mehr überall so.
Auch die Notwendigkeit einer Internetverbindung stört mich nicht wenig. Kann man auch ein Lokales Verzeichnis als Quelle angeben?
Das stört mich auch. Der Verweis auf andere Systeme wo man noch viel viel mehr über dauernde INET Verbindung runterladen muss, bringt da natürlich auch nicht viel. Und ja, man kann auch ein lokales Repository anlegen von welchem sich dann andere Rechner updaten können. Aber da wird es dann doch etwas aufwändiger. Zu aufwendig für mich. Darum, für einen meiner Rechner mache ich es einfach über "copy /us" (4os2 - update, auch subdirectories). Geht natürlich mit jedem anderen sync tool auch. Aber so ist das nicht gedacht und ob man sich damit Probleme einhandeln kann, weiß ich nicht. Übrigens, eine zweite Adresse für alle netlabs rpms gibt es schon irgendwo. Hab nur grad vergessen wo.
zumindest bezüglich angenehmer Geschwindigkeit - eine Volumenbegrenzung.
Bei mir geht's nicht ums Volumen, sondern die Geschwindigkeit ist mies. Bei uns im ländlichen Raum leider schlecht ausgebaut. So hat jeder sein Päckchen zu tragen ;-)
Umfangreichen Anleitungen zu lesen. Und die gibt es meines Wissens nach nur auf englisch.
Das wäre wieder ein Punkt wo viele einfache User auch aushelfen könnten wenn sie den nur wollten. Rezessionen schreiben, z.B. im netlabs wiki, oder einfach nur eine Übersetzung der Readme oder inf Dateien. Im trac.netlabs wiki einen Link einfügen und eine übersetzte Seite anlegen könnte jeder.

Zu dem Punkt muss ich andererseits aus Entwicklersicht sagen, mich ödet an, dass XWLAN mit 4 Sprachdateien geliefert wird. Jeden Furz muss ich nun 4x reinkopieren (=fehleranfällig) anstatt nur einmal in einer englischen Readme. Und dabei mach ich eh nur Deutsch und Englisch. Aber freiwillige Helfer hab ich noch nicht gefunden. Andererseits, wenn viele ohnehin nicht mal die readme lesen und schon gar nicht die .inf, warum dann überhaupt was dokumentieren? Soll nur verdeutlichen, es gibt die ganze Bandbreite von "ich will alles perfekt dokumentiert haben in meiner Sprache" bis "braucht eh keiner weil's ohnehin nicht gelesen wird". Raus kommt meist irgendwas dazwischen.
Das wäre alles ja noch halb so wild wenn rpm/yum mit eCS mitinstalliert werden würde.
Ist doch ohnehin bei eCS2.2beta so wenn man es nicht abwählt, oder?

Ansonsten viel Zustimmung für das was du geschrieben hast.
Benutzeravatar
ak120
Beiträge: 1044
Registriert: Do 8. Mai 2014, 12:50
Wohnort: Demmin
Kontaktdaten:

Beitrag von ak120 »

Schade, daß wieder mit Unterstellungen und Rabulistik gearbeitet wird. Wer sich die Zeit zum Lesen nimmt, wird feststellen können, daß ich niemals Portierungen pauschal als halbherzig bezeichnet habe. Deshalb folgt nur noch einzige konkrete Fragen zum RPM/YUM-System.
Wie kann ich als Endbenutzer die Manual-Seiten in lesbarer Form anzeigen? Danke.
Benutzeravatar
aschn
Beiträge: 1363
Registriert: Mi 25. Dez 2013, 22:47

Beitrag von aschn »

ak120 » Mi 5. Nov 2014, 13:54 hat geschrieben: Wie kann ich als Endbenutzer die Manual-Seiten in lesbarer Form anzeigen?
Dieser Weg geht auch: SeaMonkey starten, Ctrl+L, "man yum" eintippen und einen der gefundenen Links anklicken.

Zusätzlich hat Alex Taylor irgend etwas gebaut um Man-Seiten auf OS/2 anzuzeigen. Das müsste (auch) auf Hobbes sein.

Ich will mal nicht weiter so tun, als würde ich Dich nicht verstanden haben:

Ja, Du hast Recht: Es wird keine .man-Datei mit ausgeliefert. Das könnte damit zu tun haben, dass das Systemwekzeug, das dieses Format gut lesbar anzeigen kann, normalerweise nicht bei OS/2 dabei ist. Das würd ich nicht "halbherzig" nennen, sondern einfach nicht zu 100 % fertig. Nebenbei: Fällt Dir irgendein Programm (oder ein Treiber) für OS/2 ein, dass Du als fertig bezeichnen würdest? Es geht um Entwicklerressourcen. Sogar eine GUI war mit Sicherheit schon lange geplant, existiert aber auch noch nicht. Wer heute OS/2 nutzt, weiß, woher er sich die Info beschafft. Einfach die .man-Seiten auf OS/2 anzuzeigen reicht auch in den wenigsten Fällen. Es fehlt häufig systembedingt etwas oder (im Fall von YUM) es gibt erweiterte Möglichkeiten (WPS-Objekte). Die OS/2-spezifischen Erweiterungen findet man hier: http://trac.netlabs.org/rpm/wiki/RpmHowToPackagers
Andreas Schnellbacher
Antworten