1) Es kommt hier natürlich sehr stark darauf an, was man sucht.
1a) Wenn man eine gewisse Nähe zu Pkgsrc haben möchte, dann drängt sich das XBPS von Void Linux auf (der Gründer von Void und Schöpfer von XBPS ist ein früherer NetBSD-Entwickler, der sich Linux zugewendet hat, so daß die Verwandtschaft keine allzugroße Überraschung sein dürfte). Für mich als ehemaligen Archer der auch die alternative C-Bibliothek Musl sehr schätzt, ist Void überhaupt sehr anziehend (Runit scheint mir auch recht nett zu sein). Ich habe es die letzten Jahre nicht genauer verfolgt, aber in meiner Erinnerung war XBPS recht brauchbar (es war wohl mal dazu gedacht, Pkgsrc abzulösen). Verglichen mit Raven ist es aber trotzdem noch deutlich näher am etwas Altbackenen (getrennte Befehle für die Paketwerkzeuge usw.), also meiner Einschätzung nach eine gute Weiterentwicklung aber kein radikaler Neuanfang. Es ist allerdings für Portabilität entworfen und *könnte* vermutlich auch für andere Systeme verwendet werden (ist meines Wissens aber nicht ernsthaft passiert).
1b) Wenn's minimalistisch sein soll, habe ich früher sehr gerne mit Apk von Alpine Linux gearbeitet. Unverkennbar Arch-ähnlich (APKBUILD- statt PKGBUILD-Dateien und ganz ähnlicher Aufbau), aber auf sparsam getrimmt (z.B. Subpackages "-dev" für die Header wie bei Debian anstatt wie bei Arch alles KISS-mäßig in ein Paket zu packen). Schick, sparsam, leider auch ein Exot.
1c) Ein sehr interessanter Ansatz ist auch der Package-Manager Nix, der das Paradigma funktionaler Programmierung auf die Paketverwaltung überträgt (einfach mal kurz informieren, ist gut investierte Zeit, wenn man sich für das Thema interessiert). Für mich persönlich verliert er sich aber etwas zu sehr in Dingen, die ich als Bastler nett finde, die für mich aber am Ende des Tages wie Spielerei aussehen. Dadurch ist eine recht hohe Komplexität gegeben und mir sind z.B. die nixpkgs zu unübersichtlich, um damit intensiver zu arbeiten.
1d) Verzicht auf vorgefertigte Binärpakete und Nutzung z.B. der FreeBSD-Ports oder von Gentoos Emerge kann für manchen natürlich auch eine Option sein. Mit etwas Aufwand lassen sich damit eigene Binärpakete schaffen und auf zahlreichen Maschinen nutzen.
2) Als jemand, der mit heterogenen Systemen arbeitet, ist für mich der Hauptvorteil, daß ich auf den BSD- und den Linux-Kisten (verschiedene Distris) die gleichen Versionen bestimmter kritischer Software laufen lassen kann - und damit dem Wahnsinn des Versionsjungels entgehe, der droht, wenn man dazu die jeweils im Distri-Repo vorhandenen Versionen nutzt (und den Aufwand spare, alles auf den Zielsystemen selbstzubauen und zu pflegen).
In einer homogenen Umgebung mit nur einer Linux Distri kann Raven diese Stärke natürlich nicht ausspielen. Hier würde vielleicht dafür sprechen, daß man darüber recht neue Software zusätzlich beziehen kann. Der Rabe ist nicht eifersüchtig: Alle Pakete werden standardmäßig mit Präfix /raven gebaut (könnten aber genausogut nach /opt oder dergleichen installiert werden) und kommen durch diese Parallelstruktur den Paketen der Distri nicht ins Gehege. Das kann z.B. ganz nett sein, da Raven auch die Installation z.B. mehrerer PHP-Versionen gleichzeitig unterstützt. Man kann seit kurzem sogar Pakete kombinieren, die verschiedene SSL-Bibliotheken nutzen (z.B. LibreSSL, OpenSSL 1.0.2 und OpenSSL 1.1.1)!
Das Tooling ist aus meiner Sicht einfach großartig. Wer selbst angepaßte Pakete (z.B. anderer Prefix) bauen möchte, bekommt ein leicht zu handhabendes und gleichzeitig sehr mächtiges Werkzug an die Hand: Ravenadm.
Es werden „Varianten“ unterstützt, d.h. eine Software kann in mehreren gängigen Kompilierzeit-Konfigurationen zur paketiert werden (z.B. eine mit minimalen Abhängigkeiten und eingeschränkten Fähigkeiten, eine Durchschnittskonfiguration und eine mit vollem Featureumfang aber vielen und schwergewichtigen Abhängigkeiten).
--
Theoretisch könnte man auch eine ganze Distri aufziehen, die Raven für die Paketerstellung nutzt. Als Fernziel habe ich die Idee eines „teammate Linux“ (Arbeitstitel) im Hinterkopf, einer Distribution, die darauf ausgelegt ist, sich gut in heterogene Umgebungen einzupassen. Aber das ist weit weg. Realistischer wäre es wahrscheinlich, daß eine bestehende kleine Distri Raven als Zweitpaketsystem einführt (die Arbeit für „pflegeintensive“ Programme wie Webkit-*, die verschiedenen Qt-Komponenten, LibreOffice samt Abhängigkeiten, aktuelle GCC- und LLVM-Toolchain sowie Rust usw. nicht doppelt machen zu müssen, da andere sich darum kümmern, könnte attraktiv sein).
1) Richtig, jedes System hat so seine besten Anwendungsfälle/-nichen.
Manchmal beschleicht mich allerdings das Gefühl, dass die Schnittmengen der Eigenschaften & (Non-)Features sehr groß sind, und man sich dort schon Arbeit hätte sparen können.
So haben bspw. Alpine Linux APKBUILD, Arch Linux PKGBUILD, Crux Ports, XBPS etwa den selben Fokus. Sogar Source Mage kommt dem sehr nahe, ist allerdings ohne Absicht, Binärpakete zu verteilen, entwickelt worden, und wirkt mittlerweile fast tot (siehe 1d).
Die Verschiedenheit der Ports-Systeme der BSDs habe ich auch nie ganz nachvollziehen können. Klar müssten die Makefiles und Patches mitunter anders aussehen. Andere Software läuft mitunter gar nicht, da nötige Kernelschnittstellen o. -module fehlen. Aber die Werkzeuge zum bauen oder verteilen sollten doch mit minimalen Anpassungen auf einer gemeinsamen Basis stehen können, oder nicht?
Aus der Ferne kommt mir das bei den Ravenports schon anders vor. Allein der Zustand und die Absichten hinter dem Projekt versprechen ein besseres Zusammenspiel auf verschiedenen Platformen.
Ich will nicht sagen, dass die hier genannten Projekte nicht existieren sollten. Es geht ja meist auch darum, was man (ein/die Entwickler) selbst auf die Beine gestellt bekommt. Möge die bessere Lösung gewinnen - nach welchen Metriken von "besser" auch immer...
zu 1c) Den Ansatz von Nix finde ich interessant, aber auch sehr kompliziert. Man erhält viele Garantien von diesem Ansatz. Der Preis, den man zahlt, ist allerdings enorm: Eine traditionelle, manuelle Installation eigener Software per make wird zur Qual und geht eigentlich nur mittels diverser Tricks und der Emulation einer speziellen Umgebung samt FHS usw. Desweiteren muss man eine (weitere) DSL lernen oder anderen beibringen. Nur kleinere Teams und Startups werden sich soetwas leisten (können). GoboLinux mit seinen Recipes ist ja kläglich damit gescheitert, den FHS zu revolutionieren.
1d) Die FreeBSD Ports mag ich sehr gern. Leider ist TeXLive immer noch nicht auf dem aktuellen Stand, siehe Bug #211997.
Gentoos Ansatz hat mich noch nie besonders umgehauen. Ich sehe die Stärken eigentlich nur beim Konzept als Metadistribution. Für mich ergibt das eigentlich nur wirklich Sinn, falls man eine größere Zahl maßangefertigter Systeme betreibt, sodass sich Skalierungseffekte ausnutzen lassen.
Obwohl ich es nie verwendet habe, fand ich Source Mage fand schon immer ganz niedlich. Im Wesentlichen sind die Abhängigkeiten diverse Tools, die sowieso auf den meisten Systemen vorhanden sind (coreutils, Archivierungs- und Kompressionsprogramme, eine vollständige Buildtoolchain) und Bash. Sozusagen der nächste konsequente Schritt nach LFS. Interessanter Ansatz.
1e) Was mich ggü. RPM so fasziniert, ist, dass die Abhängigkeiten, bspw. von Perl, nicht wirklich notwendig sind, Systeme mit ähnlichen Features anzubieten. So kommen die meisten dieser Systeme ohne viele/große Abhängigkeiten aus, und schaffen es trotzdem, mit weniger Code zum Ziel zu kommen.
1f) Haben Sie zufälligerweise Erfahrung mit dem Open Build Service (OBS) sammeln können? Ich habe hier und da sehr positive Kurzberichte dazu lesen können.
Die Hauptinstanz ist bekanntlich die des openSUSE-Projekts. Man kann auch eigene Instanz betreiben, was scheinbar so einige größere Projekte für sich nutzen, siehe hier.
2) Klingt plausibel, in so einem Anwendungsfall, auf Ravenports zu setzen. Ich sehe, dass es mit den "Professional Services" auch eine Grundlage gibt, nicht nur ein weiteres Ports-/Paketprojekt zu sein. Ich wünsche dem Projekt und seinen Mitstreitern viel Erfolg.
Ravenports ist mit Ausnahme der darunterliegenden Tools für Paketformat pkg anscheinend in Ada geschrieben. Eine interessante Wahl!
zum Thema „Geschichte der *nix-Paketverwaltung“ und verschiedenen alternativen Ansätzen habe ich in der Vergangenheit bereits geschrieben. Wenn PL Interesse daran haben sollte, kann ich da gerne etwas zur Verfügung stellen. Vielen Dank für die Anregung!
Wollte mich an dieser Stelle nochmal für die Antwort bedanken. Insbesondere über den „Source Mage“ war ich z.B. noch nie gestolpert.
Bezüglich der Verschiedenheit der Ports-Systeme: Eingeführt wurde das Ports-Framework 1993 in FreeBSD 1.0 durch Jordan Hubbard. Es wurde ca. ein Jahr später von NetBSD adaptiert (und landete dadurch auch im späteren Fork OpenBSD). Zu diesem Zeitpunkt waren die Unterschiede wohl sehr gering und man tauschte sich auch aus, wodurch Erweiterungen unter NetBSD zu FreeBSD zurückflossen. Als sich dann aber unter NetBSD der Fokus verschob, trennten sich eben die Wege und man entwickelte sich wortwörtlich voneinander weg. Das führt dann dazu, daß Software, die schon ewig dabei ist, auch z.B. in den gleichen Kategorien steckt, während später hinzugefügte sich unterscheiden kann (worauf ich u.a. jedes Mal wieder reinfalle, obwohl ich es eigentlich weiß, ist, daß der Origin von Tmux unter FreeBSD sysutils/tmux ist, unter Pkgsrc aber misc/tmux!).
Schön, daß Sie Gobo erwähnen! Ich hatte auch überlegt, es anzukratzen, habe mich aber letztlich dagegenentschieden, um den Kommentar nicht noch weiter aufzublasen. Ich fand den Ansatz auch äußerst interessant und freute mich, als das Projekt nach langem Schlaf wiedererweckt wurde - habe es aber inzwischen aus den Augen verloren.
TeX in FreeBSD: Ja, das ist eine der großen Baustellen. Wir haben das Monster in Raven irgendwann auch noch vor uns...
Mit SuSEs OBS habe ich nie gearbeitet. Ich finde den Ansatz gut, er ist mir aber nicht flexibel genug (da ich nicht nur mit mehreren Linux-Distris arbeite, sondern auch *BSD und Illumos in meine Planung einbeziehen möchte). Aber als das, was es ist, soll es ganz ordentlich sein.
Zu Ada: Ja, der Hauptentwickler hat wohl ursprünglich einen NASA- / Raumfahrt-Hintergrund, wo diese Sprache bevorzugt für missionskritische Anwendungen eingesetzt wurde, wodurch er Ada genügend zu schätzen gelernt hat, daß er u.a. der Maintainer für die Ada-Compiler unter *BSD wurde. Ich selbst beherrsche kein Ada, weshalb ich mich mit Wertungen sehr zurückhalte. Aber ich erlebe immer wieder, daß viele Leute nach einem kurzen Staunen über den Praxiseinsatz des Exoten für Ravenadm das eigentlich recht gut finden.
Sehr gerne, freue mich über Dein Interesse!
1) Es kommt hier natürlich sehr stark darauf an, was man sucht.
1a) Wenn man eine gewisse Nähe zu Pkgsrc haben möchte, dann drängt sich das XBPS von Void Linux auf (der Gründer von Void und Schöpfer von XBPS ist ein früherer NetBSD-Entwickler, der sich Linux zugewendet hat, so daß die Verwandtschaft keine allzugroße Überraschung sein dürfte). Für mich als ehemaligen Archer der auch die alternative C-Bibliothek Musl sehr schätzt, ist Void überhaupt sehr anziehend (Runit scheint mir auch recht nett zu sein). Ich habe es die letzten Jahre nicht genauer verfolgt, aber in meiner Erinnerung war XBPS recht brauchbar (es war wohl mal dazu gedacht, Pkgsrc abzulösen). Verglichen mit Raven ist es aber trotzdem noch deutlich näher am etwas Altbackenen (getrennte Befehle für die Paketwerkzeuge usw.), also meiner Einschätzung nach eine gute Weiterentwicklung aber kein radikaler Neuanfang. Es ist allerdings für Portabilität entworfen und *könnte* vermutlich auch für andere Systeme verwendet werden (ist meines Wissens aber nicht ernsthaft passiert).
1b) Wenn's minimalistisch sein soll, habe ich früher sehr gerne mit Apk von Alpine Linux gearbeitet. Unverkennbar Arch-ähnlich (APKBUILD- statt PKGBUILD-Dateien und ganz ähnlicher Aufbau), aber auf sparsam getrimmt (z.B. Subpackages "-dev" für die Header wie bei Debian anstatt wie bei Arch alles KISS-mäßig in ein Paket zu packen). Schick, sparsam, leider auch ein Exot.
1c) Ein sehr interessanter Ansatz ist auch der Package-Manager Nix, der das Paradigma funktionaler Programmierung auf die Paketverwaltung überträgt (einfach mal kurz informieren, ist gut investierte Zeit, wenn man sich für das Thema interessiert). Für mich persönlich verliert er sich aber etwas zu sehr in Dingen, die ich als Bastler nett finde, die für mich aber am Ende des Tages wie Spielerei aussehen. Dadurch ist eine recht hohe Komplexität gegeben und mir sind z.B. die nixpkgs zu unübersichtlich, um damit intensiver zu arbeiten.
1d) Verzicht auf vorgefertigte Binärpakete und Nutzung z.B. der FreeBSD-Ports oder von Gentoos Emerge kann für manchen natürlich auch eine Option sein. Mit etwas Aufwand lassen sich damit eigene Binärpakete schaffen und auf zahlreichen Maschinen nutzen.
2) Als jemand, der mit heterogenen Systemen arbeitet, ist für mich der Hauptvorteil, daß ich auf den BSD- und den Linux-Kisten (verschiedene Distris) die gleichen Versionen bestimmter kritischer Software laufen lassen kann - und damit dem Wahnsinn des Versionsjungels entgehe, der droht, wenn man dazu die jeweils im Distri-Repo vorhandenen Versionen nutzt (und den Aufwand spare, alles auf den Zielsystemen selbstzubauen und zu pflegen).
In einer homogenen Umgebung mit nur einer Linux Distri kann Raven diese Stärke natürlich nicht ausspielen. Hier würde vielleicht dafür sprechen, daß man darüber recht neue Software zusätzlich beziehen kann. Der Rabe ist nicht eifersüchtig: Alle Pakete werden standardmäßig mit Präfix /raven gebaut (könnten aber genausogut nach /opt oder dergleichen installiert werden) und kommen durch diese Parallelstruktur den Paketen der Distri nicht ins Gehege. Das kann z.B. ganz nett sein, da Raven auch die Installation z.B. mehrerer PHP-Versionen gleichzeitig unterstützt. Man kann seit kurzem sogar Pakete kombinieren, die verschiedene SSL-Bibliotheken nutzen (z.B. LibreSSL, OpenSSL 1.0.2 und OpenSSL 1.1.1)!
Das Tooling ist aus meiner Sicht einfach großartig. Wer selbst angepaßte Pakete (z.B. anderer Prefix) bauen möchte, bekommt ein leicht zu handhabendes und gleichzeitig sehr mächtiges Werkzug an die Hand: Ravenadm.
Es werden „Varianten“ unterstützt, d.h. eine Software kann in mehreren gängigen Kompilierzeit-Konfigurationen zur paketiert werden (z.B. eine mit minimalen Abhängigkeiten und eingeschränkten Fähigkeiten, eine Durchschnittskonfiguration und eine mit vollem Featureumfang aber vielen und schwergewichtigen Abhängigkeiten).
--
Theoretisch könnte man auch eine ganze Distri aufziehen, die Raven für die Paketerstellung nutzt. Als Fernziel habe ich die Idee eines „teammate Linux“ (Arbeitstitel) im Hinterkopf, einer Distribution, die darauf ausgelegt ist, sich gut in heterogene Umgebungen einzupassen. Aber das ist weit weg. Realistischer wäre es wahrscheinlich, daß eine bestehende kleine Distri Raven als Zweitpaketsystem einführt (die Arbeit für „pflegeintensive“ Programme wie Webkit-*, die verschiedenen Qt-Komponenten, LibreOffice samt Abhängigkeiten, aktuelle GCC- und LLVM-Toolchain sowie Rust usw. nicht doppelt machen zu müssen, da andere sich darum kümmern, könnte attraktiv sein).
Hey, danke. Das klingt ja alles ganz interessant.
1) Richtig, jedes System hat so seine besten Anwendungsfälle/-nichen.
Manchmal beschleicht mich allerdings das Gefühl, dass die Schnittmengen der Eigenschaften & (Non-)Features sehr groß sind, und man sich dort schon Arbeit hätte sparen können.
So haben bspw. Alpine Linux APKBUILD, Arch Linux PKGBUILD, Crux Ports, XBPS etwa den selben Fokus. Sogar Source Mage kommt dem sehr nahe, ist allerdings ohne Absicht, Binärpakete zu verteilen, entwickelt worden, und wirkt mittlerweile fast tot (siehe 1d).
Die Verschiedenheit der Ports-Systeme der BSDs habe ich auch nie ganz nachvollziehen können. Klar müssten die Makefiles und Patches mitunter anders aussehen. Andere Software läuft mitunter gar nicht, da nötige Kernelschnittstellen o. -module fehlen.
Aber die Werkzeuge zum bauen oder verteilen sollten doch mit minimalen Anpassungen auf einer gemeinsamen Basis stehen können, oder nicht?
Aus der Ferne kommt mir das bei den Ravenports schon anders vor. Allein der Zustand und die Absichten hinter dem Projekt versprechen ein besseres Zusammenspiel auf verschiedenen Platformen.
Ich will nicht sagen, dass die hier genannten Projekte nicht existieren sollten. Es geht ja meist auch darum, was man (ein/die Entwickler) selbst auf die Beine gestellt bekommt.
Möge die bessere Lösung gewinnen - nach welchen Metriken von "besser" auch immer...
zu 1c) Den Ansatz von Nix finde ich interessant, aber auch sehr kompliziert. Man erhält viele Garantien von diesem Ansatz. Der Preis, den man zahlt, ist allerdings enorm: Eine traditionelle, manuelle Installation eigener Software per make wird zur Qual und geht eigentlich nur mittels diverser Tricks und der Emulation einer speziellen Umgebung samt FHS usw.
Desweiteren muss man eine (weitere) DSL lernen oder anderen beibringen. Nur kleinere Teams und Startups werden sich soetwas leisten (können).
GoboLinux mit seinen Recipes ist ja kläglich damit gescheitert, den FHS zu revolutionieren.
1d) Die FreeBSD Ports mag ich sehr gern. Leider ist TeXLive immer noch nicht auf dem aktuellen Stand, siehe Bug #211997.
Gentoos Ansatz hat mich noch nie besonders umgehauen. Ich sehe die Stärken eigentlich nur beim Konzept als Metadistribution. Für mich ergibt das eigentlich nur wirklich Sinn, falls man eine größere Zahl maßangefertigter Systeme betreibt, sodass sich Skalierungseffekte ausnutzen lassen.
Obwohl ich es nie verwendet habe, fand ich Source Mage fand schon immer ganz niedlich. Im Wesentlichen sind die Abhängigkeiten diverse Tools, die sowieso auf den meisten Systemen vorhanden sind (coreutils, Archivierungs- und Kompressionsprogramme, eine vollständige Buildtoolchain) und Bash. Sozusagen der nächste konsequente Schritt nach LFS. Interessanter Ansatz.
1e) Was mich ggü. RPM so fasziniert, ist, dass die Abhängigkeiten, bspw. von Perl, nicht wirklich notwendig sind, Systeme mit ähnlichen Features anzubieten.
So kommen die meisten dieser Systeme ohne viele/große Abhängigkeiten aus, und schaffen es trotzdem, mit weniger Code zum Ziel zu kommen.
1f) Haben Sie zufälligerweise Erfahrung mit dem Open Build Service (OBS) sammeln können? Ich habe hier und da sehr positive Kurzberichte dazu lesen können.
Die Hauptinstanz ist bekanntlich die des openSUSE-Projekts. Man kann auch eigene Instanz betreiben, was scheinbar so einige größere Projekte für sich nutzen, siehe hier.
2) Klingt plausibel, in so einem Anwendungsfall, auf Ravenports zu setzen. Ich sehe, dass es mit den "Professional Services" auch eine Grundlage gibt, nicht nur ein weiteres Ports-/Paketprojekt zu sein. Ich wünsche dem Projekt und seinen Mitstreitern viel Erfolg.
Ravenports ist mit Ausnahme der darunterliegenden Tools für Paketformat pkg anscheinend in Ada geschrieben. Eine interessante Wahl!
Was geht denn hier ab, das ist ja so interessant das hieraus ein Artikel für PL gemacht werden sollte!
Hallo Mitzekatze,
zum Thema „Geschichte der *nix-Paketverwaltung“ und verschiedenen alternativen Ansätzen habe ich in der Vergangenheit bereits geschrieben. Wenn PL Interesse daran haben sollte, kann ich da gerne etwas zur Verfügung stellen. Vielen Dank für die Anregung!
Wollte mich an dieser Stelle nochmal für die Antwort bedanken. Insbesondere über den „Source Mage“ war ich z.B. noch nie gestolpert.
Bezüglich der Verschiedenheit der Ports-Systeme: Eingeführt wurde das Ports-Framework 1993 in FreeBSD 1.0 durch Jordan Hubbard. Es wurde ca. ein Jahr später von NetBSD adaptiert (und landete dadurch auch im späteren Fork OpenBSD). Zu diesem Zeitpunkt waren die Unterschiede wohl sehr gering und man tauschte sich auch aus, wodurch Erweiterungen unter NetBSD zu FreeBSD zurückflossen. Als sich dann aber unter NetBSD der Fokus verschob, trennten sich eben die Wege und man entwickelte sich wortwörtlich voneinander weg. Das führt dann dazu, daß Software, die schon ewig dabei ist, auch z.B. in den gleichen Kategorien steckt, während später hinzugefügte sich unterscheiden kann (worauf ich u.a. jedes Mal wieder reinfalle, obwohl ich es eigentlich weiß, ist, daß der Origin von Tmux unter FreeBSD sysutils/tmux ist, unter Pkgsrc aber misc/tmux!).
Schön, daß Sie Gobo erwähnen! Ich hatte auch überlegt, es anzukratzen, habe mich aber letztlich dagegenentschieden, um den Kommentar nicht noch weiter aufzublasen. Ich fand den Ansatz auch äußerst interessant und freute mich, als das Projekt nach langem Schlaf wiedererweckt wurde - habe es aber inzwischen aus den Augen verloren.
TeX in FreeBSD: Ja, das ist eine der großen Baustellen. Wir haben das Monster in Raven irgendwann auch noch vor uns...
Mit SuSEs OBS habe ich nie gearbeitet. Ich finde den Ansatz gut, er ist mir aber nicht flexibel genug (da ich nicht nur mit mehreren Linux-Distris arbeite, sondern auch *BSD und Illumos in meine Planung einbeziehen möchte). Aber als das, was es ist, soll es ganz ordentlich sein.
Zu Ada: Ja, der Hauptentwickler hat wohl ursprünglich einen NASA- / Raumfahrt-Hintergrund, wo diese Sprache bevorzugt für missionskritische Anwendungen eingesetzt wurde, wodurch er Ada genügend zu schätzen gelernt hat, daß er u.a. der Maintainer für die Ada-Compiler unter *BSD wurde. Ich selbst beherrsche kein Ada, weshalb ich mich mit Wertungen sehr zurückhalte. Aber ich erlebe immer wieder, daß viele Leute nach einem kurzen Staunen über den Praxiseinsatz des Exoten für Ravenadm das eigentlich recht gut finden.