Vortrag 2 - Bitwise Works Projekte

Informationen zu den Vorträgen auf dem User Treffen Köln am 26. November 2016
Antworten
Benutzeravatar
ARoederer
Beiträge: 384
Registriert: Fr 27. Dez 2013, 17:25
Wohnort: Hamburg / Germany
Kontaktdaten:

Vortrag 2 - Bitwise Works Projekte

Beitrag von ARoederer »

Download Video: Vortrag 2 - Bitwise Works Projekte (317 MB, MP4)

Zuletzt geändert von ARoederer am Sa 10. Nov 2018, 01:33, insgesamt 1-mal geändert.
Benutzeravatar
Frank Wochatz
Beiträge: 1112
Registriert: So 22. Dez 2013, 22:04
Wohnort: Berlin
Kontaktdaten:

Beitrag von Frank Wochatz »

Danke für das Video, ich hab mir den Vortrag angehört. Da Herwig ja auch ausdrücklich nach Feedback gefragt hat, will ich das hier nochmal zum Thema YUM/RPM tun.

Ich kann nachvollziehen, daß man den Support-Aufwand minimieren möchte, und das die DLL Situation einfach nur ätzend ist. Es macht Sinn, da anszusetzen.

Allerdings:
1.) schafft ihr mit so einer komplizierten, ich sag mal "High-End" Lösung euch erst mal selber Programmier- und Supportaufwand, denn das will erstmal umgesetzt werden.
2.) selbst wenn das eines Tages 100% funktioniert, löst YUM/RPM überhaupt nicht das Problem mit der Kollision von DLLs unterschiedlicher Pakete, solange die anderweitig verfügbaren Pakete dadurch nicht komplett ersetzt werden. Und die anderen Pakete (bzw. DLLs) werden schlichtweg nicht verschwinden. D.h. das wird nur für Pakete funktionieren, die eh aus derselben Quelle kommen.

Besonders suboptimal finde ich in dem Zusammenhang, daß es für gefühlte 1.000 OS/2-Benutzer nun noch drei unterschiedliche Paketquellen gibt. Dafür kann natürlich bww nichts, aber das sollte unbedingt abgeglichen werden.

Ansonsten bin ich weiterhin der Meinung, das eine Low-Tech Variante erheblich einfacher umzusetzen wäre, besonders auch in Hinblick auf die extrem begrenzten Entwicklerressourcen und finanziellen Mittel. ZB. mit einem aktuellen DLL-Pool im Internet, der einfach auf einen lokale Installation gespiegelt bzw. synchonisiert wird. Bringt zwar genauso wenig für Konflikte mit alten Paketen, wäre aber deutlich einfacher umzusetzen.
Zuletzt geändert von Frank Wochatz am Do 15. Dez 2016, 16:53, insgesamt 1-mal geändert.
Benutzeravatar
wilfried
Beiträge: 667
Registriert: Mo 23. Dez 2013, 18:26
Wohnort: Barsinghausen
Kontaktdaten:

Beitrag von wilfried »

2.) selbst wenn das eines Tages 100% funktioniert, löst YUM/RPM überhaupt nicht das Problem mit der Kollision von DLLs unterschiedlicher Pakete, solange die anderweitig verfügbaren Pakete dadurch nicht komplett ersetzt werden. Und die anderen Pakete (bzw. DLLs) werden schlichtweg nicht verschwinden. D.h. das wird nur für Pakete funktionieren, die eh aus derselben Quelle kommen.
Hallo Frank,

benutze es und Du wirst feststellen YUM/RPM ist schlauer als Du erwartest!
Ich habe mich auch lange gesträubt es einzusetzen zumal mal man auf einem frischen ecs 2.2 beta ii ohne fix sofort vor den "Baum" läuft.
In YUM/RPM steckt soviel künstliche Intelligenz um nach veralteten und inkompatiblen DLLs zu suchen und ggf. die Installation zu verweigern.
Ich will hier nicht behaupten dass das immer 100% funktioniert, aber ich bin schon mehrfach aufgefordert worden mein System zu bereinigen um eine Paketinstallation durchzukriegen!

"Give It A Try and Cry Afterwards" :D
Benutzeravatar
Frank Wochatz
Beiträge: 1112
Registriert: So 22. Dez 2013, 22:04
Wohnort: Berlin
Kontaktdaten:

Beitrag von Frank Wochatz »

Hi Wilfried,

ich hab das in dem Vortrag so verstanden, dass ein DLL-Prüftool, das relevante Pfade durchsucht noch in der Entwicklungsphase ist. Das ist sicherlich auch eine gute Sache. Ist das jetzt doch schon implementiert, oder ergibt sich dein Erfolgsergebnis auf bereits mit dem Paketmanager installierte DLLs oder auf den Unixroot? Findet der Paketmanager tatsächlich DLLs, die ich sonst wie über WPI oder per Hand installiert habe?

Ansonsten denke ich der Paketmanager ist eine gute Sache, wenn man das System neu aufsetzt, und sich selbst dazu bringt/zwingt, auch ausschließlich den Paketmanager zu benutzen. Aber gibt es denn alles als RPM-Paket? Wohl kaum. Ich habe halt ein gewachsenes System (was übrigens recht gut funktioniert). Ein universelles Tool auf einer Plattform, wo man Software der letzten 20 Jahre installiert und benutzt wird das mit Sicherheit nie werden. Ich finde es zudem unter OS2 auch gut, dass man noch was selber mache kann, und dass man überall ran kommt. Unter zB. Windows kann man gar nichts mehr selber machen. Ich würde z.B. gerne selber bestimmen, wo ich was installiere.
Benutzeravatar
wilfried
Beiträge: 667
Registriert: Mo 23. Dez 2013, 18:26
Wohnort: Barsinghausen
Kontaktdaten:

Beitrag von wilfried »

ich hab das in dem Vortrag so verstanden, dass ein DLL-Prüftool, das relevante Pfade durchsucht noch in der Entwicklungsphase ist. Das ist sicherlich auch eine gute Sache. Ist das jetzt doch schon implementiert, oder ergibt sich dein Erfolgsergebnis auf bereits mit dem Paketmanager installierte DLLs oder auf den Unixroot? Findet der Paketmanager tatsächlich DLLs, die ich sonst wie über WPI oder per Hand installiert habe?
Hallo Frank,

ich kann hier nur aus dem Gedächtnis berichten. Ich habe nach erfolgreichem Einsatz von Arca Noae Package Manager auf einer ecs 2.2 beta ii Testinstallation, den Arca Noae Package Manager auch auf meinem produktiven Rechner mit ecs 2.1 DE nachinstalliert und wurde bei der Aktualisierung mehrfach aufgefordert veraltete DLLs aus dem System zu entfernen. Leider habe ich darüber keine Aufzeichnungen gemacht. Wie ich das verstehe wird der Libpath. der Path und UNIXROOT (?) nach Dubletten oder veralteten DLLs durchsucht. Nachdem ich die Dateien entfernt hatte, ging die Aktualisierung dann durch.

Das ein System jederzeit wieder destabilisiert werden kann, wenn man über andere Installationsmethoden ältere oder veraltete Software installiert, dürfte jedem klar sein.

In dem Zusammenhang sollte ich vielleicht noch erwähnen, dass die Paket-Aktualisierung dazu geführt hat das mein Versionierungswerkzeug nicht mehr funktioniert hat. Dieses Werkzeug basiert auf einer älteren CVS Version (1.10) die über die EMX-Schiene nach OS2 portiert wurde. Vermutlich haben aktuellere EMX-Dateien zu einer Unverträglichkeit geführt. Durch Upgrade auf die letzte über Hobbes verfügbare Version von CVS und Anpassung einiger CVS-Parameter habe ich dieses Werkzeug wieder zum Laufen gebracht.
Hintergrund: Mit diesem Werkzeug halte ich Veränderungen an meinem System in einem CVS-Repository fest (CONFIG.SYS und andere textbasierte Konfigurationsdateien) und kann die Historie und die Veränderungen über eine auf CVS aufsetzende GUI sichtbar machen.
Zuletzt geändert von wilfried am So 18. Dez 2016, 12:58, insgesamt 1-mal geändert.
Antworten