FreeBSD und Trinity

H

holgerw

Guest
Hallo,

rein aus Neugier möchte ich demnächst mal Trinity in der aktuellen Version 14.0.3 auf dem FreeBSD Desktop anschauen, ich kenne Trinity bisher unter openSUSE 13.2, MX-15 und Debian Jessie.

Auf der Trinity Seite finde ich Informationen zu fertigen Paketen für Debian und Ubuntu, und für weitere GNU/linux Distributionen Hinweise, dass aktualisierte Pakete bald kommen.

Zu FreeBSD finde ich den Hinweis:
FreeBSD Support
There are still some issues that need to be addressed before full FreeBSD support can be achieved. Additional developers or contributors willing to help porting the remaining features and applications are always welcome.
Zum Vergrößern anklicken....

Das klingt gut, gibt es da schon was Inoffizielles (ob Pakete oder Ports, beides ist mir recht). Oder muss man da noch richtig Hand anlegen mit configure && make && make install? Wenn ich das installiert bekomme, würde ich gerne auch mir unter FreeBSD auffallende Dinge melden, einen Bugzilla Account habe ich schon.

Über Hinweise freue ich mich.

Ob Trinity noch lohnt, oder ein sogenanntes totes Pferd ist, ist eine andere interessante Frage, aber vielleicht mache ich dazu einen anderen Thread auf.

Viele Grüße,
Holger
 
tja, schade... Habe wohl zu schnell nachgeschaut. Es gibt da noch ein Assembly tool aus der Bioinformatik, dass sich auch Trinity nennt... Allerdings Version 2.2.1, läuft auch auf FreeBSD :)

Grüße, Norbert
 
Hallo Norbert,

ich meine TDE, Trinity Desktop Environement, die Fortführung von kde3. Eigentlich habe ich an Trinity nur Interesse wegen einer Anwendung, und zwar dem alten digikam. Das kann nämlich - was seit Version 2.6 nicht mehr geht - noch ordentlich Inpainting, d.h. Du kannst kleine Gegenstände markieren auf einem Bild und diese dann entfernen. Mein Vater ist ganz scharf auf diese Korrekturmöglichkeit, ich habe ihm unter MX15-Linux dieses alte digikam parallel zu kde4 mit modernem digikam 4 installiert. Dort läuft es prächtig. Ich würde es aber gerne auch unter BSD zum Laufen bekommen.

Viele Grüße,
Holger
 
Hallo @abeginner,

danke für den Hinweis, aber Dein Hinweis bezieht sich doch auf das alte Digikam > 0.7.x, was kompatibel zu kde3, bzw. Trinity ist.

Im aktuellen digikam4 gibt es Inpainting auch, aber es ist schon seit Jahren kaputt, digikam hängt sich reproduzierbar auf verschiedenen Distributionen bei unterschiedlicher Hardware auf, und das seit digikam 2.6 vor einigen Jahren. Der Bug ist bekannt, es hat was mit dem Wechsel von cimg nach gmic zu tun, aber die digikam Entwickler haben wohl kein großes Interesse daran, das endlich mal zu bereinigen - ich hatte deshalb schon Auseinandersetzungen per Mail mit Marcel Wiesweg und Gilles Caulier.

Daher mein Interesse am "alten" kde3.

Viele Grüße,
Holger
 
Das ist natürlich sehr ärgerlich.
Käme GIMP als Alternative in Frage? Mit Ausnahme von UFRaw hatte ich zwar noch nie ein PlugIn ein Gimp-PlugIn installiert, Sehe aber die Chance, ein vergleichbare Funktion unter GIMP zu installieren, grösser.
Bildbearitung unter freien unixoiden OS ist halt so eine Sache . . . leider . . . :)
 
was ich nicht ganz verstehe: wieso muss man denn ein komplettes DE installieren, wenn es nur um eine einzige Anwendung geht?
Gibt es die denn nicht alleine?

digikam hatte ich auch zu meiner KDE-Zeit nie genutzt, lese aber, dass es ebenfalls auf die kipi-plugins setzt. Ebenfalls, wie etwa gwenview auch. Vielleicht ist damit ja die gewünschte Funktion ebenfalls zu realisieren und hängt nicht so sehr an diesem einen Plugin.

Davon abgesehen gibt es natürlich eine große Menge an unterschiedlicher Grafik und Bildbearbeitungssoftware, die unterschiedlichen Leistungsumfang bietet. Unter KDE sieht man häufig mehrere Anwendungen zu etwas zusammengefasst, das ich eine Suite nennen will. Da soll dann alles, was irgendwie mit Bildern zu tun hat, innerhalb dieser Suite erledigt werden können. Dieser Ansatz, den man ja auch bei anderen Entwicklungen immer häufiger sieht (etwa eine Browser soll Musik und Filme spielen, PDFs betrachten können und was weiß ich noch alles), gefällt mir persönlich eher nicht. Deshalb benutze ich selbst immer nur relativ spärliche Viewer, die quasi nichts anderes können, als Bilder Anzeigen. Über 98% aller Anwendungsfälle in denen Bilder vorkommen sind damit bei mir durch eine kleine und leichte SW abgedeckt.
Wenn es denn zur Bearbeitung kommt, wähle ich eben ein mächtigeres Programm und da allen anderen voran GIMP.
Weil ich nur recht beschränkte Aufgaben habe, kam ich damit immer sehr gut weiter und zwar ohne die zahlreichen Plugins zu nutzen, die da angeboten werden.
Das lenkt aber nun unnötig ab.

Zurück zu digikam.
Code: 
o-box@senyo ~:-> pkg search digikam
digikam-4.2.0_1,2              KDE4 digital photo management application
digikam-doc-4.2.0              Documentation for digiKam, showFoto, and Kipi-plugins
digikam-l10n-4.2.0             l10n for digiKam, showFoto, and Kipi-plugins
Wenn ich das also ansehe, gibt es da offenbar nur eine Version von digikam in den Ports und diese wird vermutlich eine ganze Reihe an Abhängigkeiten (gegenüber KDE) haben. Deshalb wird es nicht helfen, ein anderes DE zu bauen und dann digikam zu installieren. Ich könnte es nun installieren, benutze OpenBox und gar kein KDE, hätte dann die entsprechenden Abhängigkeiten dabei (wahrscheinlich ein halbes KDE) und könnte dann diese Anwendung unter OpenBox genauso nutzen, wie unter KDE oder GNOME oder was auch immer. Tatsächlich nutze ich gelegentlich noch solche KDE-lastigen Programme, versuche sie aber zu reduzieren, weil es mir eben immer zu viele Abhängigkeiten sind und dabei vor allem irgendwelche Dienste, die dann oft mit den Programmen zusammen gestartet werden, weil das eben im KDE-Environment so gehandhabt wird. Mir gefällt das nicht und nach und nach finde ich immer mehr Alternativen, die ohne diesen KDE-Ballast auskommen.
Was du suchen müsstest, wäre ja ein Weg, die alte Version von digikam mitsamt der alten Abhängigkeiten zusätzlich in dein System einzubauen.
Die Wahl des DE beeinflusst diese Aufgabe nicht.
Anbetracht der Schwierigkeiten, die sich da ergeben, will ich dir wenig Hoffnung machen. Denn wir haben nur einen gültigen Pfad der Abhängigkeiten und können nicht selbst aktiv werden und Alternativen hinzu formulieren. Man erklärt das immer mit Konsistenz, aber ich ärgere mich darüber gelegentlich auch, wenn etwa mal wieder ein Icon-Set als Abhängigkeit zu einem Programm unsinniger Weise zusätzlich installiert wird und ich das nicht ändern kann.
/usr/ports/INDEX-n enthält die Liste der Abhängigkeiten aller Ports zu der FreeBSD Version n.
Das ist eine einfache Textdatei und da könnte man natürlich etwas ändern, das aber beim nächsten Update der Ports wieder überschrieben wäre.
Mit pkgng habe ich noch nicht viel Erfahrung und sehe bisher gar keine Möglichkeit, überhaupt etwas zu beeinflussen. Da stehen die Abhängigkeiten offenbar fest, womit dann keine Möglichkeit bestünde, eine ältere Version eines Programms einzumischen.
Das ältere Programm selbst aus Quellen zu bauen und dann mit neueren Abhängigkeiten zu versehen, könnte vielleicht gelingen, aber das ist natürlich eine Bastel-Lösung vor dem Herren.
 
chaos schrieb:
In meinen Augen ist digikam kein reines Bildbearbeitungsprogramm, sondern dient zur Bilderverwaltung mit Bearbeitungsplugins.
Zum Vergrößern anklicken....
Die Grenzen zwischen Verwaltungsprogrammen, spezialisierten RAW-KonverterProgrammen & Bearbeitungsprogrammen verschmelzen zusehends. Ursachen dafür gibt's mehrere.
 
Hallo,

zunächst vielen Dank für die rege Beteiligung an meiner Frage.

Mit gimp und dem registry-plugin kann man große Gegenstände aus einem Bild auf ziemlich professionelle Weise weg bekommen. Insofern ist gimp nicht nur eine Alternative, sondern eine bessere Alternative.

Es geht bei der Inpainting-Funktion von digikam jedoch eher um kleinere Sachen, Flecken auf der Haut bei Portrait-Fotos, kleinere Artefakte u.s.f. Da ist dann mit digikam sehr schnell ein gutes Resultat zu erzielen. gimp wäre da die berüchtigte Kanone, mit der man auf Spatzen schießt :)

Übrigens geht es um das System meines Vaters, er möchte das so haben und sperrt sich ein weng, das mit gimp zu machen, obgleich er verschiedene andere Sachen bei der Fotobearbeitung durchaus auch mit gimp macht. Die Schwierigkeit bei diesem registry-plugin von gimp ist, dass es nicht durchgängig auf Deutsch lokalisiert ist, man hat einen Mix aus englisch- und deutschsprachigen Menüs.

Natürlich ist mir klar, dass digikam primär ein Fotoverwaltungsprogramm ist, aber geade Anwendungen mit Bezug zu KDE sind ja doch eher etwas multifunktionaler - manche sagen dazu auch überfrachtet. Es ist wie bei modernen Smartphones, man kann auch noch damit telefonieren. :D

Was TDE (Trinity) angeht: Den gesamten Desktop dazu möchte ich gar nicht installieren, allerdings brauche ich eine minimale Basis samt Lokalisierungspaket und Artwork, damit das alte digikam zum Laufen zu bekommen ist.

Viele Grüße,
Holger
 
Was ich nicht verstehe, das KDE3 und Gnome2 aus den Ports entfernt wurde. Ein mündiger User sollte doch selber entscheiden, ob er das noch nutzt oder eben nicht. Selber kann und will ich nicht auf solche Highlight's wie Digikam oder Knoda als Datenbankfrontend für Dbase, Paradox, SQlite, PostgreSQL und MySQL verzichten, weil es dafür keine wirkliche Alternativen gibt. Gerade Knoda besitzt einen eingebauten Formulardesigner, womit ich meine Daten anspruchsvoll darstellen kann.
 
Nunja, KDE3 und GNOME2 sind ja eigentlich beide tot und daher kann man das durchaus verstehen, wenn die irgendwann aus den Ports verschwinden. Wenn an SW nicht mehr aktiv entwickelt wird, dann fehlen mitunter rasch die ein oder andere Eigenschaft, die man im Laufe der Zeit hinzu entwickelt hat und die nur in die weiter gepflegten Versionen übernommen werden.
Es liest sich auch ziemlich kurz, KDE3 oder GNOME2, aber dahinter stecken ja furchtbar viele Programm-Pakete und die haben alle wieder ihre Abhängigkeiten ins System. Der Aufwand dafür, solche Ports zu pflegen, ist sicher nicht gerade bescheiden. Die Maintainer wachsen auch nicht gerade auf den Bäumen und so ergibt es sich dann, dass irgendwann tote Äste beschnitten werden müssen, was ich persönlich auch schon häufiger bedauerte.

Gerade das Konzept von KDE muss ich daher in diesem Atemzug aber auch kritisieren, denn dadurch, dass da sehr viele Anwendungen nicht unabhängig entwickelt und angeboten werden, sondern nur zusammen mit KDE, wird meiner Ansicht nach der Nutzer zu sehr in seiner Wahl festgelegt.
 
Wie pit schon sagte, die Abhängikeiten gehen auf Dauer kaputt. Die alten Sachen kompilieren unter Umständen nicht mehr mit neueren Bibliotheksversionen, und mehrere Versionen gleichzeitig werden AFAIK nicht unterstützt. Somit würden KDE3 und GNOME2 den gesamten Portstree „aufhalten“.

KDE und GNOME schenken sich im Bezug auf Abhängigkeiten nichts, alle Frameworks haben dieses Problem. Bei GNOME war es bislang modularer, was aber zu deutlich mehr Paketen geführt hat, mit KDE Frameworks 5 soll das aber auch bei KDE Einzug halten. Allerdings sind die GNOME-Entwickler nicht gewillt, auch nur das geringste bisschen Rücksicht auf andere Entwickler zu nehmen, da werden die ABIs nach Belieben gebrochen, solange es innerhalb von GNOME passt. Das fand ich bei KDE nicht ganz so krass.
 
Danke, das habe ich jetzt besser verstanden. Aber offensichtlich hat OpenBSD dieses Problem nicht, denn die haben immer noch zumindest KDE 3 in der neuesten Ausgabe. Warum die diese Probleme nicht haben, weiss ich aber auch nicht.
 
ralli schrieb:
Danke, das habe ich jetzt besser verstanden. Aber offensichtlich hat OpenBSD dieses Problem nicht, denn die haben immer noch zumindest KDE 3 in der neuesten Ausgabe. Warum die diese Probleme nicht haben, weiss ich aber auch nicht.
Zum Vergrößern anklicken....
OpenBSDs packaging Werkzeuge unterstützen flavours, vielleicht haben sie darüber die Versionen festgenagelt? Mehr als Raten kann ich aber auch nicht.
 
Man könnte grundsätzlich Systeme so bauen, dass alte und neue Versionen nebeneinander laufen können. Bei Paketen für OS-X wird zum Beispiel nicht nur die eigentliche SW eingebaut, sondern alle benötigten Abhängigkeiten ebenfalls. Das hat dann zur Folge, dass man von einer Lib vielleicht gleichzeitig fünf oder mehr Versionen an Board hat und die befinden sich alle an speziellen Orten im Zusammenhang mit der installierten SW.
FreeBSD und viele GNU/Linux-Systeme machen das anders und installieren etwa nur eine gültige Version einer Lib an einem zentralen Platz und alle Anwendungen müssen dann genau zu dieser Lib passen.
Also, das soll nun nur ein Beispiel sein, aber gerade bei den Libs kann man sich das auch sehr schön ansehen. Häufig gibt es einen Namen für eine Lib und dieser ist dann ein Link auf die aktuelle Version. Ältere Versionen stehen oft noch zur Verfügung, falls man zurückrudern möchte, aber im Grunde könnten die gelöscht werden (wofür es auch SW gibt).
Durch dieses Prinzip braucht man "weniger SW" auf dem PC zu halten und zu installieren. Es ist eigentlich echt elegant, braucht dann aber eben Versionen von Programmen, die alle auch die jeweilig gültige Lib benutzen.
Das alles ist in den System-Abhängigkeiten eingeflossen.

Allerdings, diese Abhängigkeiten werden nicht in alle denkbaren Richtungen getestet. Die werden ziemlich stur festgeschrieben. Getestet ist nur mit der aktuellen Lib, also ist nur diese für uns gültig. Dass es mit anderen Libs (ich sage immer Libs, meine aber irgendwelche Programme, die benötigt werden) evtl auch problemlos funktionieren würde, ist nicht Gegenstand einer Betrachtung. Und da kann dann schon mal ziemlich dummes Zeugs als Abhängigkeit festgeschrieben sein und mir Dinge installieren, die ich gar nicht mag.
In manchen GNU/Linux-Systemen kann man hier die Abhängigkeiten in gewissem Umfang konfigurieren (etwa bei Debian). So viel ich bisher gesehen habe, gilt das nicht für FreeBSD. Der Vorteil ist bei FreeBSD, wo ich mich nicht einmischen kann: alle Programme (der komplette Ports-Tree) haben konsistente Abhängigkeiten.

Ein Nachteil ist eben eine geringere Flexibilität der Ports und Pakete.
Das ist eine Design-Frage. Wie wir auch keine getrennten Kernel unter einem GNU hinweg tauschen, sondern immer nur komplettes FreeBSD bekommen. Das wäre auch anders möglich, ist aber so entschieden und im Grunde bietet dies weniger Freiheit, als wenn ich nach Belieben tauschen könnte. Darüber beschwert hat sich aber wohl selten jemand.
 
Dann kann ich ja auch gleich wieder statisch linken. Das klingt jetzt genauso wie die Praxis unter Windows, alle benötigten Bibliotheken in das Verzeichnis der Anwendung zu kippen. So kombiniert man die Nachteile des statischen Linkens mit denen des dynamischen Linken, hat also das schlechteste beider Welten. Fortschritt!
 
goblin schrieb:
Dann kann ich ja auch gleich wieder statisch linken. Das klingt jetzt genauso wie die Praxis unter Windows, alle benötigten Bibliotheken in das Verzeichnis der Anwendung zu kippen. So kombiniert man die Nachteile des statischen Linkens mit denen des dynamischen Linken, hat also das schlechteste beider Welten. Fortschritt!
Zum Vergrößern anklicken....

ganz genau.
Ich wollte nicht etwa dergleichen vorschlagen, sondern nur erwähnen, dass es grundsätzlich machbar wäre.
Das ist eine Design-Frage.
 
goblin schrieb:
Wie pit schon sagte, die Abhängikeiten gehen auf Dauer kaputt. Die alten Sachen kompilieren unter Umständen nicht mehr mit neueren Bibliotheksversionen, und mehrere Versionen gleichzeitig werden AFAIK nicht unterstützt. Somit würden KDE3 und GNOME2 den gesamten Portstree „aufhalten“.
Zum Vergrößern anklicken....

Hallo @goblin
unter debian basierten Systemen wird der ganze TDE Kram nach /opt gepackt. Unter MX15 (Antix+Mepis, debian stable basiert aber ohne systemd) läuft das erstaunlich gut, ich kann unter dem Loginmanager kde4, xfce4 und TDE auswählen.

Viele Grüße,
Holger
 
holgerw schrieb:
Hallo @goblin
unter debian basierten Systemen wird der ganze TDE Kram nach /opt gepackt. Unter MX15 (Antix+Mepis, debian stable basiert aber ohne systemd) läuft das erstaunlich gut, ich kann unter dem Loginmanager kde4, xfce4 und TDE auswählen.
Zum Vergrößern anklicken....

Wenn Trinity ihre Bibliotheken und Programme umbenannt hat, dann müssten sie nichtmal nach ``/opt`` installiert werden. Das Problem ist „lediglich“, alles zum Kompilieren zu bringen und das dann in Form eines Ports zu automatisieren. Es müsste sich eben jemand drum kümmern. Da es bislang keine Rückmeldung zum Thema Port gab denke ich, dass wir hier noch ganz am Anfang stehen. Also müsstest du vermutlich erstmal schauen, ob es denn kompiliert.
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben