Vortrag 2 - Bitwise Works Projekte

Informationen zu den Vorträgen auf dem User Treffen Köln am 26. November 2016
Online
User avatar
ARoederer
Posts: 303
Joined: Fri 27. Dec 2013, 17:25
Location: Hamburg / Germany

Vortrag 2 - Bitwise Works Projekte

Post by ARoederer » Mon 12. Dec 2016, 05:06

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

Last edited by ARoederer on Sat 10. Nov 2018, 01:33, edited 1 time in total.

User avatar
Frank Wochatz
Posts: 872
Joined: Sun 22. Dec 2013, 22:04
Location: Berlin

Post by Frank Wochatz » Thu 15. Dec 2016, 16:53

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.
Last edited by Frank Wochatz on Thu 15. Dec 2016, 16:53, edited 1 time in total.

User avatar
wilfried
Posts: 573
Joined: Mon 23. Dec 2013, 18:26
Location: Barsinghausen

Post by wilfried » Sat 17. Dec 2016, 11:46

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

User avatar
Frank Wochatz
Posts: 872
Joined: Sun 22. Dec 2013, 22:04
Location: Berlin

Post by Frank Wochatz » Sun 18. Dec 2016, 11:05

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.

User avatar
wilfried
Posts: 573
Joined: Mon 23. Dec 2013, 18:26
Location: Barsinghausen

Post by wilfried » Sun 18. Dec 2016, 12:42

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.
Last edited by wilfried on Sun 18. Dec 2016, 12:58, edited 1 time in total.