FreeBSD: 14.000 ports überschritten

Daniel Seuffert

Daniel Seuffert

Well-Known Member
Es freut mich vermelden zu Können, daß FreeBSD mittlerweile die 14.000 ports überschritten hat, siehe http://www.freshports.org/ :)


Calculated hourly:
Port count 14005
Broken 215
Deprecated 88
Ignore 582
Forbidden 14
Restricted 314
No CDROM 205
Vulnerable 42
Expired 26
Set to expire 61
Interactive 94
new 24 hours 12
new 48 hours 15
new 7 days 42
new fortnight 84
new month 247


Mein Dank gilt allen maintainern, ports committern und sonstigen Freiwilligen, welche durch ihre hervorragende Arbeit dazu beigetragen haben, daß FreeBSD seinen Nutzern eine solch immens große Auswahl an freier software bieten kann. :)

Trotz der Patina, welche die ports teilweise angesetzt haben, beweist es die Schlüssigkeit des zugrundeliegenden Konzeptes. Ich hoffe die Entwicklung geht so weiter, weniger broken ports sind zu verzeichnen und hoffentlich wird in Zukunft an der einen oder anderen Stelle noch mehr strukturelle Verbesserung geleistet werden können. Weil ihr wißt ja: Das Bessere ist der Feind des Guten! ;)
 
Hallo,

ich bin von der großen Auswahl in den Ports auch ganz begeistert,
und möchte allen, die das ermöglichen, danke sagen.

Dankeschön! :)


Gruß, Fusselbär
 
Hi,

Weil ich seit fast 2 Jahren kein FBSD mehr nutze und ich den Stand des ports-Systems nicht mehr kenne:

Hat es in der Zeit strukturelle Verbesserungen gegeben und welche muesste es Deiner Meinung nach noch geben?
 
Hallo mawei,

was meinst Du mit strukturellen Verbesserungen? :confused:
Dein Post klingt für mich, als hätte Dich irgendetwas gestört.
FreeBSD benutze ich noch gar keine 2 Jahre.

Worüber ich mich z.B. sehr freute,
als es dazukam, war amarok ein sehr aufwendiger Audoplayer,
mit der Möglichkeit, die gesamte Musiksammlung zu verwalten.
Eine feine Sache ist auch easytag.

Auch über die Videoplayer wie z.B. kmplayer,
der sowohl die GStreamer, mplayer oder Xine Engine benutzen kann,
freue ich mich sehr,
und natürlich auch über k3b eine grafische Oberfläche zur bequemen Steuerung von Brennprogrammen.

Die puristischen Varianten wie elinks, ein Textbrowser mit Tabs,
irrsi, der IRC Client für die Konsole, moc, ein Audioplayer für die Konsole,
mc zum bequemen Überblick auf der Konsole finde ich auch toll.

Dann gibts da noch so Programme wie azureus, ein Bittorrentclient,
der sogar Unterhaltung beim torrentieren bietet.
(Da kann man die anderen Bittorrentbenutzer als Symbole sehen, wie die sich "mit Bits bewerfen")
Auch das es Spiele gibt und den nvidia-driver,
sowie auch kommerzielle Anwendungen wie z.B. opera,
ut2004 (Demoversion) und Neverwinter Nights, gefällt mir sehr gut.

Eben fällt mir doch tatsächlich was ein, was wohl doch nicht in den Ports ist:
KAudioCreator, ein Programm mit dem man Audio CDs einlesen und in das gewünschte Format umwandeln kann.
Hatte es mir aus den Sourcen so kompiliert,
und hatte das schon ganz vergessen, das es gar nicht aus den Ports ist.
Läuft übrigens fein, das Programm. :)


Gruß, Fusselbär
 
Fusselbär schrieb:
was meinst Du mit strukturellen Verbesserungen?
Dein Post klingt für mich, als hätte Dich irgendetwas gestört.
Zum Vergrößern anklicken....

Sorry, das bezog sich auf Daniels Beitrag, wo er schreibt, dass
"noch mehr strukturelle Verbesserung" geleistet werden könnte.

Sicher gab es beim ports-System damals Sachen, die mich gestört haben, aber die gibt es in der ein oder anderen Form ja überall - andererseits wird da auch ständig dran "geschraubt" und verbessert. Ich hab mitbekommen, dass die Binärpakete mittlerweile wohl sehr oft aktualisiert werden sollen, was "damals" noch nicht der Fall war.

Bei der Frage ging's mir nicht so sehr um all die schönen Anwenderprogramme, sondern mehr um die pkg- und ports-Tools, etc.

viele Grüsse
 
Ich meinte in meinem Beitrag nicht vordergründig die Tatsache, daß die Auswahl an freier software immer größer wird (vor allem aus dem GPL-Bereich) und damit die Zahl der ports automatisch steigt. Dies wird primär verursacht durch immer mehr, immer leistungsfähigere software und immer mehr Leute, die freiwillig Applikationen entwerfen und pflegen.

Es geht mir zum einen um strukturelle Verbesserungen in den ports an sich und die policy von portmgr in FreeBSD. Zu ersterem: Neben den vielen kleinen, kaum merklichen Verbesserungen erwähne ich mal beispielhaft solche Dinge wie Index, portsnap usw. und zum anderen immer leistungsfähigere build-cluster auf der anderen Seite (sie zuletzt Spende von HP mit den Blades). Nur so ist es möglich immer mehr ports und packages auf immer mehr Plattformen (vergessen wir nicht, daß SPARC usw. erst später dazukamen (ab 5.x)) gebaut werden. Die Scripte dahinter werden immer weiter optimiert, tinderbox, pointyhat usw. erfahren ständig Verbesserungen und Verifizieren (siehe beispielhaft http://pointyhat.freebsd.org/errorlogs/) die Änderungen in den ports. Die Zahl der contributors und committer wächst ständig.

Gleichzeitig finden Verbesserungen auf "politischer" Ebene statt. Früher hat es keinen Aufstand gegeben, als von 8000 ports 2000 broken waren, heute stört man sich, daß von 14.0005 215 ports broken sind. portmgr hat Direktiven erlassen, welche der Qualitätssicherung dienen, und sie werden strikter umgesetzt. Das Porters handbook wird ständig aktualisiert, ports, welche nicht fetchen, builden usw. werden frühzeitiger als broken/deprecated usw. markiert und auch schneller expired. Um ganz ehrlich zu sein erachte ich persönlich Qualität wichtiger als Quantität, was die ports betrifft, aber das ist eine ganz persönliche Ansicht. 14.000 apps ist ein Haufen Holz und das verursacht naturgemäß eine Unmenge Arbeit und Ärger und man wird nie eine perfekte Lösung finden. Das Schlagwort vom YAPM (yet another paket manager) in Linux zeugt es ja. Ich halte auch pkgsrc nicht für zwingend besser oder sonst eine Alternative. Es gibt da kein Wundermittel, wo man an einer Schraube dreht und auf einmal geht das Tor auf. Es ist zuallererst schlichte, brutale, ätzende, kraftraubende Handarbeit: Wenn die coder, maintainer usw. schlechte Applikationen bzw. Updates abliefern, dann kommt hinten nur Müll raus, egal was ich tue. Ich will auch keine vagen Vermutungen anstellen, wann wirklich grundlegende Änderungen allein durch das Wachstum in den ports notwendig werden. Vielleicht werden wir bei 20.000 ports noch ganz locker auf die 30.000 schauen ohne Schweißperlen auf der Stirn. Fakt ist: Das Konzept hat sich erstaunlich lange als performant und erweiterungsfähig gezeigt. Jegliche Ähnlichkeiten zu sysinstall etc. wären hier rein zufällig. :D

Ich konstatiere nur eines: Großartige Arbeit bisher, ein positiver Ausblick in die Zukunft und die Bereitschaft ständig zu feilen, schleifen, verbessern. es wird in den ports keinen "großen" Sprung geben können ohne weiteres, ich glaube auch nicht, daß man dies überhaupt braucht, zumindest sehe ich es heute nicht. Konstanz wahren, Qualität noch weiter heben wenn es geht.

Ad multos annos! :)
 
Fusselbär schrieb:
Eben fällt mir doch tatsächlich was ein, was wohl doch nicht in den Ports ist:
KAudioCreator, ein Programm mit dem man Audio CDs einlesen und in das gewünschte Format umwandeln kann.
Hatte es mir aus den Sourcen so kompiliert,
und hatte das schon ganz vergessen, das es gar nicht aus den Ports ist.
Läuft übrigens fein, das Programm. :)
Zum Vergrößern anklicken....

kaudiocreator ist schon seit geraumer Zeit Teil des Ports multimedia/kdemultimedia3
 
@Daniel Seuffert

15490 - 14005 = 1485

Noch 1486 Packete/Ports und FreeBSD hat Debian überholt :)

Mal im Ernst:
Um ganz ehrlich zu sein erachte ich persönlich Qualität wichtiger als Quantität,
Zum Vergrößern anklicken....
meine Rede!

Kann man bei FreeBSD analog zu Debian die Bug reports zu einem Port einsehen?

Leider musste ich in der letzten Zeit immer wieder feststellen, dass ich auf Fehler in Debian Paketen gestoßen bin, die sich dann im Nachhinein als "well known" herausgestellt haben.

Ich halte auch pkgsrc nicht für zwingend besser
Zum Vergrößern anklicken....
Der OS-Übergreifende Ansatz ist sehr interessant, aber das heißt noch lange nicht, dass es deshalb auch so funktioniert (in der letzten Zeit gab es hier im Forum immer mal wieder mehr oder weniger erfolgreiche Tests)

immer leistungsfähigere build-cluster
Zum Vergrößern anklicken....
Auch wenn hier viele anderer Meinung sind erachete ich die Verfügbarkeit eines Ports als binäres Packet als essentiell.
Warum?
Weil das binäre Packete der eindeutige Beweis dafür ist, dass die Generierung des Packetes wirklich funktioniert und zwar im Gegensatz zu "das müßte aber funktionieren".
 
tib schrieb:
Kann man bei FreeBSD analog zu Debian die Bug reports zu einem Port einsehen?
Zum Vergrößern anklicken....


Mir wäre auf Anhieb kein direkter Weg bekannt die Informationen in Freshports direkt mit http://www.freebsd.org/cgi/query-pr-summary.cgi zu verknüpfen. Das ist zumindest ein sehr ernstzunehmender Verbessrungsvorschlag imho, wenngleich ich nicht weiß, ob dies schon versucht wurde oder ob das am Aufwand/anderen Gründen prinzipiell scheitert. Vielleicht kennt aber hier jemand einen solchen Weg? Das würde mich persönlich auch sehr interessieren! ;)

Bezüglich Debian und der Zahl der dortigen Pakete will ich nur am Rande noch erwähnen, daß beides nicht direkt vergleichbar ist. Aber das ist imho reichlich belanglos.
 
Hallo markus,

dankeschön für die Aufklärung,
und ich habe wirklich gegrübelt, wo ich den her habe.
Sehr feines Teil, der kaudiocreator!
Zumal ich mich entschlossen habe, meine alten Aufnahmen
nach und nach zu löschen
und noch mal neu einzuspielen mit 320 kB/s. :)


Gruß, Fusselbär
 
Daniel Seuffert schrieb:
Mir wäre auf Anhieb kein direkter Weg bekannt die Informationen in Freshports direkt mit http://www.freebsd.org/cgi/query-pr-summary.cgi zu verknüpfen. Das ist zumindest ein sehr ernstzunehmender Verbessrungsvorschlag imho, wenngleich ich nicht weiß, ob dies schon versucht wurde oder ob das am Aufwand/anderen Gründen prinzipiell scheitert. Vielleicht kennt aber hier jemand einen solchen Weg? Das würde mich persönlich auch sehr interessieren! ;)
Zum Vergrößern anklicken....
Es wäre schön wenn was passieren würde, in Prinzip könnte es gleich mit der Thematik Ports - Online Suche wegen der ich vor kurzem nachgefragt hatte abgehandelt werden.

Bezüglich Debian und der Zahl der dortigen Pakete ...
Zum Vergrößern anklicken....
Linux-Distributionen haben bei ihren Paketen meist eine höhere Granularität, da dort oft Dokumenation (doc) und Funktionalität für die Entwicklung (dev) in eigene Pakete ausgelagert wird.
Wenn man daher die Funktionalität normieren würde sähe das Verhältnis anders aus.
 
Naja, die Holzhammermethode geht eigentlich fast immer:
Code: 
find /usr/ports -name Makefile | xargs grep FORBIDDEN

Verboten sind die Teile dann ueblicherweise wegen bekannter Sicherheitsmaengel.
bsd.port.mk schrieb:
# FORBIDDEN - Package build should not be attempted because of
# security vulnerabilities.
Zum Vergrößern anklicken....
 
Ich moechte eure kleine Party ja nicht stoeren, aber 215 Ports sind broken, d.h. sie sind effektiv nicht vorhanden. Folglich sinds nur 13790 Ports.

In diesem Sinne :huth:
 
@ningo
Hehe, das stört nun aber doch. Manche Ports bauen nur unter 4.x nicht, daher broken. Manche nicht mit gcc-295,...
Aber es sind über 14.000 Ports in den Ports. Sind also vorhanden. Also feiert ;-)
 
tib schrieb:
15490 - 14005 = 1485

Noch 1486 Packete/Ports und FreeBSD hat Debian überholt :)
Zum Vergrößern anklicken....
Das mußt du aber relativieren. In Debians repository sind insgesamt wohl ca 15500 Pakete drin, aber das Repository gilt ja für mehrere Architekturen (genau wie FreeBSDs Ports) und umfasst mehrere Versionen von Debian (mindestens stable, testing und unstable). Das bedeutet viele Pakete liegen da sozusagen mehrfach drin, weil die Binaries auf mehreren Architekturen laufen und in verschiedenen Versionen existieren müssen. Und dazu kommt auch noch, daß auch die ganzen Systemprogramme in irgendwelchen Paketen des Repositories drin sind - Linux halt.
Soweit ich weiß umfasst Debians Repository alles in allem nur rund 7000 Programme, also knapp halbsoviel wie FreeBSDs Ports.
 
.mp schrieb:
Das mußt du aber relativieren.
Zum Vergrößern anklicken....
Was ich bereits in Posting #12 getan habe!

In Debians repository sind insgesamt wohl ca 15500 Pakete drin,
Zum Vergrößern anklicken....
Laut Homepage Stand 18.01.2006: 15490

aber das Repository gilt ja für mehrere Architekturen (genau wie FreeBSDs Ports) und umfasst mehrere Versionen von Debian (mindestens stable, testing und unstable).
Zum Vergrößern anklicken....
korrekt

Das bedeutet viele Pakete liegen da sozusagen mehrfach drin, weil die Binaries auf mehreren Architekturen laufen und in verschiedenen Versionen existieren müssen.
Zum Vergrößern anklicken....
Die Korrektheit dieser Aussage möchte ich wohl stark in Zweifel ziehen!
Ein Packet liegt mindestens als Source-Packet vor und dann je nach Packet
1 bis n plattformspezifische Builds.
Bei Doc-Packeten gibt es, weil plattformunabhängig, nur ein Packet.
Trotzdem wird das Packet nur einmal gezählt!

Und dazu kommt auch noch, daß auch die ganzen Systemprogramme in irgendwelchen Paketen des Repositories drin sind - Linux halt.
Zum Vergrößern anklicken....
Das ist auch gut so - aber lassen wir das Thema :)

Soweit ich weiß umfasst Debians Repository alles in allem nur rund 7000 Programme, also knapp halbsoviel wie FreeBSDs Ports.
Zum Vergrößern anklicken....
Warum das so ist hatte ich bereits in #12 hingewiesen.
Allerdings ist entgegen Deiner Aussage ebenfalls nicht jeder Port ein Programm!
 
Leute streitet euch bitte nicht um solche Sophismen, sonst kommt der nächste hier an und philosophiert über metaports in FreeBSD und deren Bewertung... Meine Aussage ging schlicht dahin, daß dieser Vergleich wie so manch anderer schlicht und ergreifend hinkt, weil nicht exakt kongruente Begriffe/Strukturen/Auffassungen miteinander verglichen werden. Ich könnte jetzt auch noch viel mehr zu Debian sagen, aber das schenke ich mir jetzt, weil es völlig uninteressant ist, sepziell in diesem thread.

Es gibt 4 Dinge imho zu beachten:
1. Der user muß eine ausreichend große Wahl an Applikationen haben
2. Die Apps müssen erhältlich sein (ich verweise jetzt mal am Rande auf Bill Fenner und seine distfile-scripte, wurde viel getan in letzter Zeit in diesem Bereich!).
3. Irgendwie muß das Zeug verwaltet werden im Sinne von finden, updaten usw. einschliesslich Metainfo dazu (siehe Frage tib z.B.)
4. Es muß Verlässlichkeit herrschen im Sinne von wenig ist broken, vulnerable usw. es macht keinen Spass einen port zu installieren und eine der 50 dependencies ist stale aus irgendwelchen Gründen nur mal als Beispiel.

Nur meine 2 cents dazu, Daniel :)
 
@Daniel: Du hast vollkommen recht. Ein Zwist mit verfechtern von APT ist deswegen auch fehl am Platz, weil die von Dir genannten Kriterien durch APT ebenfalls hervorragend erfüllt werden.

@tib: Immer mit der Ruhe, du mußt APT nicht verteidigen, ich habe es ja nichtmal kritisiert. Ich wollte nur darauf hinweisen, wie groß der Unterschied zwischen der von dir genannten Zahl und dem tatsächlich für den einzelnen Nutzer verfügbaren Angebot ist.
 
@tib: Immer mit der Ruhe, du mußt APT nicht verteidigen, ich habe es ja nichtmal kritisiert.
Zum Vergrößern anklicken....
Solltest Du auch nicht :)!

Ich wollte nur darauf hinweisen, wie groß der Unterschied zwischen der von dir genannten Zahl und dem tatsächlich für den einzelnen Nutzer verfügbaren Angebot ist.
Zum Vergrößern anklicken....
wenn Du denn n + 1 ten Ports braucht der nicht verfügbar ist taugt das beste Packetierungssystem nichts :)
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben