# Portage in andere Programmiersprache

## Knieper

Gesplittet von "Was ist los mit Gentoo?" -- Finswimmer

 *Jokey_ wrote:*   

> Und re: python/portage...
> 
> Python ist nicht langsam, es ist die Art wie Portage programmiert ist. [...] Ist eben eine Frage des anständigen Programmierens und nicht der Sprache die man benutzt.

 

Python ist langsam - genau wie Perl, Ruby oder Java. Das mag bei Skripten und Prototypen keine Rolle spielen, im Einsatz zeigt es sich aber ganz deutlich, wenn die naechsten Server gekauft werden...

----------

## Jokey_

 *Knieper wrote:*   

> 
> 
> Python ist langsam - genau wie Perl, Ruby oder Java. Das mag bei Skripten und Prototypen keine Rolle spielen, im Einsatz zeigt es sich aber ganz deutlich, wenn die naechsten Server gekauft werden...

 

Naja okay, mit C mit inline Assembler kann es nicht mithalten (zumindest nicht, wenn das Programm von einem guten Programmierer entwickelt wird), aber einen Ebuild Manager in C? Wieviele Jahre entwicklungszeit mag soetwas wohl haben? 15 Mannjahre? 20?

Ferner ist so ein Code nicht so dynamisch anpassbar wie Skriptcode. Hinzufügen neuer Features wäre also ein noch langsamerer Prozess als er ohnehin schon ist.

(Wobei Brian Harring Teile, die besonders aufwendig sind, bereits ín C implementiert hat)

----------

## Knieper

 *Jokey_ wrote:*   

> Naja okay, mit C mit inline Assembler kann es nicht mithalten (zumindest nicht, wenn das Programm von einem guten Programmierer entwickelt wird), aber einen Ebuild Manager in C? Wieviele Jahre entwicklungszeit mag soetwas wohl haben? 15 Mannjahre? 20?

 

Ach quark. Erstens ist es nicht so komplex und zweitens gibt es gerade fuer C einen Haufen Bibliotheken, die man benutzen kann, bis man es durch vernuenftige Eigenentwicklungen ersetzt.

 *Quote:*   

> Ferner ist so ein Code nicht so dynamisch anpassbar wie Skriptcode.

 

Das kann man ganz leicht umgehen, indem man sich vorher einen Kopf macht. "Dynamisch anpassbar" und "erweiterbar" und "skriptbar" und was weiss ich sind mit ein Grund fuer den Softwaremuell da draussen.

Bei der verkackten Portage-API ist ein Rewrite sowieso angebracht.

----------

## Jokey_

 *Knieper wrote:*   

> Bei der verkackten Portage-API ist ein Rewrite sowieso angebracht.

 

Dann mal happy coding  :Smile:  Bin schon mal auf deine Version gespannt

----------

## Necoro

 *Jokey_ wrote:*   

>  *Knieper wrote:*   Bei der verkackten Portage-API ist ein Rewrite sowieso angebracht. 
> 
> Dann mal happy coding  Bin schon mal auf deine Version gespannt

 

Also 

1.) wenn dich portage stört: nehm doch paludis  :Smile: 

2.) es stimmt schon dass die Portage-API nicht gerade gut ist ... aber sie hat sich verbessert (es gibt jetzt sogar Kommentare  :Very Happy: )

3.) für das Backend bei Portato musste ich Teile von Emerge re-implementieren. Und obwohl das nur ein arg kleiner Ausschnitt ist, ist es alles andere als trivial. Ein Package-Manager muss halt ohne Ende Eventualitäten berücksichtigen. Und wenn man die nicht von Grund auf kennt führt das halt zu einem komplexen "Spagghetti"-Code. (Das ist natürlich ein Vorteil für die Re-Implementierungen von pkgcore und paludis ... Sie brauchen die Fehler, die Portage gemacht hat nicht noch einmal machen ^^)...

Was ich sonst noch sagen wollte: s/390 ftw ^^

----------

## xraver

 *Knieper wrote:*   

> 
> 
> Python ist langsam ...

 

Dafür ist es ne feine Sprache mit der sogar Laien wie ich was vernünftiges auf die Beine stellen können.

Ich habe schon versucht mich in zig Sprachen reinzuarbeiten. Sogar C Bücher hab ich mir reingezogen. Doch python war die erste Sprache die mir auf Anhib gefallen hat.

Ich mag diese Programmiersprache.

Und Python langsam? Nein, wenn dann ist der geschriebende Code zu langsam...aber python selber  :Wink: 

 *Think4UrS11 wrote:*   

> 
> 
> Gumstix

 

Jetzt musst ich glatt mal googlen was dat ist  :Wink: .

----------

## Inte

 *Knieper wrote:*   

>  *Jokey_ wrote:*   Ferner ist so ein Code nicht so dynamisch anpassbar wie Skriptcode. Das kann man ganz leicht umgehen, indem man sich vorher einen Kopf macht.

 Wenn es bloß so einfach wäre. Pflichtenheft abarbeiten und hinterher sagen können: "Das war so aber nicht vereinbart.", ist ein Luxus den man sich bei einem Community-Projekt nicht leisten kann.

Manchmal ist es einfach besser etwas zu tun, als immer nur davon zu reden. Besser, effizienter, schneller, kleiner ... so what? Es läuft so wie es ist. Nicht optimal, aber es läuft.

Irgendjemand hat immer eine bessere Idee. Nur sind Ideen kleine feine, pflegebedürftige Pflänzchen. Von alleine wachsen die nicht. Kümmern muss man sich um sie ... ausgiebig und nachhaltig.  :Wink: 

----------

## c_m

Und da wir in der OpenSource Welt sind könnte dieser jemand sie dann auch gleich implementieren ;->

----------

## think4urs11

 *xraver wrote:*   

>  *Think4UrS11 wrote:*   Gumstix Jetzt musst ich glatt mal googlen was dat ist .

 

Das gibt aber einen Minuspunkt im Geekzähler  :Wink: 

Ich bin darüber gestolpert als ich nach ähnlicher HW wie einer Yoogie gesucht habe.

----------

## hoschi

Paludis (Portageersatz) ist komplett in C++ geschrieben worden, wie ich vor einigen Monaten befunden habe, aber vom Frontend her komplizierter (zumindest bisher). Paludis ist "gefuehlt" etwas schneller, was aber nicht zwingend mit der Programmiersprache zu tun hat, sondern mit dem Code an sich.

Ausserdem entfaellt Python damit langfristig als Dependency aus dem Basesystem, wo es ehrlich gesagt auch nicht zwingend hingehoert, da es keine Compiler- und Systemsprache ist.

Ich werde mich huetten hier Programmiersprachen zu werten. Und ich raten jedem es ebenso zu halten  :Very Happy: 

----------

## Knieper

 *Necoro wrote:*   

> 
> 
> Also 
> 
> 1.) wenn dich portage stört: nehm doch paludis 
> ...

 

Das hat noch alpha-Status.

 *Quote:*   

> 2.) es stimmt schon dass die Portage-API nicht gerade gut ist ... aber sie hat sich verbessert (es gibt jetzt sogar Kommentare )

 

Oh toll - leider macht das keine API aus.

 *xraver wrote:*   

> Dafür ist es ne feine Sprache mit der sogar Laien wie ich was vernünftiges auf die Beine stellen können.

 

Da ich der Meinung bin, dass Laien in seltensten Faellen brauchbaren Code produzieren, ist mir das Argument ziemlich egal.

 *Quote:*   

> Ich habe schon versucht mich in zig Sprachen reinzuarbeiten. Sogar C Bücher hab ich mir reingezogen. Doch python war die erste Sprache die mir auf Anhib gefallen hat.
> 
> Ich mag diese Programmiersprache.

 

Ich nutze Python auch, wenn ich schnell Sachen erledigen muss und die Wahrsch. gering ist, dass ich es noch einmal benoetige. Ich habe auch schon ziemlich rechenintensive Dinge damit gemacht, daher weiss ich auch dass manche Sachen (inkl. Nebenlaeufigkeit) in Python einfach nicht gemacht werden sollten.

 *Quote:*   

> Und Python langsam? Nein, wenn dann ist der geschriebende Code zu langsam...aber python selber 

 

Ja ja... eine Sprache an sich hat per definitionem eh keine Geschwindigkeit.

 *Inte wrote:*   

> Wenn es bloß so einfach wäre. Pflichtenheft abarbeiten und hinterher sagen können: "Das war so aber nicht vereinbart.", ist ein Luxus den man sich bei einem Community-Projekt nicht leisten kann.

 

Ich halte es wie viele andere Projekte: wenn es eine Verbesserung ist, dann baue ich das gerne ein oder tausche etwas aus, ansonsten kuemmere ich mich nicht darum.

 *Quote:*   

> Manchmal ist es einfach besser etwas zu tun, als immer nur davon zu reden. Besser, effizienter, schneller, kleiner ... so what? Es läuft so wie es ist. Nicht optimal, aber es läuft.

 

Das sehe ich in der Industrie haeufig. Schoen alles in Java mit tollen Frameworks, log4j, xml trallala. Laeuft, nur nicht im Kundeneinsatz. Ploetzlich hat der doch 1000 Kunden statt nur 10/s oder die vereinbarte Reaktionszeit von 3s wird um das 20-fache (letzter Fall) ueberstiegen. Der Code sieht nicht einmal schlecht aus, aus oo-Sicht, nur leider sind die Technologien dahinter totaler Overkill. Und sowas kann man nicht beschleunigen. Also entweder neu schreiben oder 10 Server mehr kaufen.

 *hoschi wrote:*   

> Ausserdem entfaellt Python damit langfristig als Dependency aus dem Basesystem, wo es ehrlich gesagt auch nicht zwingend hingehoert, da es keine Compiler- und Systemsprache ist.

 

Das ist das Hauptproblem, das ich damit habe. Gleiches gilt fuer die bashabhaengigen Skripte.

 *Quote:*   

> Ich werde mich huetten hier Programmiersprachen zu werten. Und ich raten jedem es ebenso zu halten 

 

Ich nicht. Solange es da draussen nur halbwegs brauchbare Sprachen bzw. Compiler gibt, werde ich nicht aufhoeren zu noergeln.  :Very Happy: 

----------

## think4urs11

 *Knieper wrote:*   

> Ich nicht. Solange es da draussen nur halbwegs brauchbare Sprachen bzw. Compiler gibt, werde ich nicht aufhoeren zu noergeln. 

 

Ausschließlich nörgeln widerspricht aber dem Communitygedanken.

Bring doch mal ein besser konzeptioniertes 'new-portage' auf den Tisch..  :Wink: 

Anforderungsprofil:

Suche (-S) unter 10s auf heutigen Mittelklasse-PC, 30s 'noch akzeptabel'

_vollständiges_ Handling von Vor- und Rückwärtsabhängigkeiten

Sprache - egal, aber auch auf embedded lauffähig

Abhängigkeiten minimal (keine DB, kein aufs/squashfs/btrfs)

Tree darf wahlweise lokal oder woanders liegen (gut für embedded), lokal muß aber möglich sein

Updates des Tree sollten flott gehen (<3 Min. auf Mittelklasse-PC, 1MBit-DSL)

cli-basiert, saubere API für optionale GUIs (ncurses, QT, GTK, ...)

multi-tree-fähig, d.h. overlays sollten nahtlos integrierbar sein

----------

## xraver

 *Knieper wrote:*   

> 
> 
>  *xraver wrote:*   Dafür ist es ne feine Sprache mit der sogar Laien wie ich was vernünftiges auf die Beine stellen können. 
> 
> Da ich der Meinung bin, dass Laien in seltensten Faellen brauchbaren Code produzieren, ist mir das Argument ziemlich egal.
> ...

 

Ignorant. Jeder fängt mal klein an und auch Laien können brauchbaren Code basteln.

Kommt jetzt natürlich darauf an wie man "brauchbar" für sich definiert.

Für mich ist Code brauchbar wenn er in erster Linie funktioniert und man ihn wiederverwerten kann.

Mit python kann ich Dinge machen wo ich mit C 10Jahre bräuchte und wahnsinnig werde würde.

Gerade die Python-Shell macht Spaß, man kann gleich Ideen antesten und sieht das Ergebnis.

Programmieren an sich ist für mich ein Thema was ich sehr trocken finde. HardcoreCoder möchte ich nicht sein, da wird man irre.

----------

## Knieper

 *Think4UrS11 wrote:*   

> Ausschließlich nörgeln widerspricht aber dem Communitygedanken.

 

Nicht unbedingt, Kritik kann auch hilfreich sein.

 *Quote:*   

> Bring doch mal ein besser konzeptioniertes 'new-portage' auf den Tisch.. 

 

Aus dem Stegreif? Ich wuerde zB. nicht den kompletten Tree uebertragen. Die Pakete verwaltet Gentoo, wieso soll jeder Rechner eine Kopie davon haben? An den Downloads der Ebuilds koennte man auch sehen, wie oft ein Paket installiert wird und wo Support nicht mehr notwendig ist.

 *Quote:*   

> Anforderungsprofil:
> 
> Suche (-S) unter 10s auf heutigen Mittelklasse-PC, 30s 'noch akzeptabel'

 

Das strukturelle Problem ist doch, dass Informationen auf dem Rechner landen, die keiner will (tausende ebuilds in tausenden Verzeichnissen). Wieso gibt es kein "Verzeichnis" (hier ist nicht das V. auf der Platte gemeint), das alle Informationen, die den Nutzer interessieren, bereithaelt? Erst wenn er sich entscheidet, ein Programm zu installieren, sollte die Struktur inkl. ebuild und Verzeichnissen auf der Platte landen. (Overlays in parallelen Verzeichnissen mit derselben Struktur.)

Kurzes Beispiel nur in Posix Shell (kein C, keine libowfat, cdb, kein Bitgeschubse, kein Perl, Python, MySQL etc.):

Fehlenden _Textindex_ erzeugen (log'weise leicht und schnell updatebar):

```

>time dash csi.sh >| si.txt

dash csi.sh >| si.txt  20.13s user 28.97s system 92% cpu 53.164 total

```

das Skript gewinnt einige "Useless use of ..."-Awards und generiert es aus /usr/portage (reiserfs).

Zu Deiner Suche in 10s (mMn. absolut inakzeptabel):

Suche nach Namen:

```

>time dash spn.sh eix

app-portage/eix - Small utility for searching ebuilds with indexing for fast results

dash spn.sh eix  0.00s user 0.00s system 97% cpu 0.007 total

```

Suche nach Beschreibung:

```

>time dash spd.sh tintin

games-mud/ytin - yet another TinTin++

games-mud/lyntin - tintin mud client clone implemented in Python

dash spd.sh tintin  0.00s user 0.00s system 89% cpu 0.007 total

```

0,00s! Kann uebrigens auch regulaere Ausdruecke ohne die regex-Rotzimplementationen der gaengigen Sprachen.

Edit:

 *xraver wrote:*   

> Für mich ist Code brauchbar wenn er in erster Linie funktioniert und man ihn wiederverwerten kann.

 

Fuer mich ist Code brauchbar, der seine Aufgabe korrekt (wenn moeglich vollstaendig) erfuellt, sicher ist und verwendbare Schnittstellen (I/O) hat.

 *Quote:*   

> Gerade die Python-Shell macht Spaß, man kann gleich Ideen antesten und sieht das Ergebnis.

 

Das Problem ist aber, dass Laien meistens keinen sicheren Code schreiben. Ganz leicht zu sehen an den x EcmaScript- und PHP-"Tutorials" im Netz, die nur so vor Fehlern strotzen. Wenn man die Bugs im Gaestebuch aufzaehlt, wird man dann noch angepflaumt, wieso man Kritik uebt und sich nicht erstmal fuer das gut gemeinte Tutorial bedankt. Typcheck von Dateien ueber Mime-Typ, Dateiexistenzpruefung mit fileexist, Pfad als Nutzereingabe... - wir kennen das alle.

 *Quote:*   

> Programmieren an sich ist für mich ein Thema was ich sehr trocken finde. HardcoreCoder möchte ich nicht sein, da wird man irre.

 

Ich habe nichts gegen Anfaenger und Hobbyprogrammierer. Nur sollten sie keine Codebeispiele und Tutorials veroeffentlichen oder diese Hacks als "stable" freigeben.

----------

## Klaus Meier

 *xraver wrote:*   

> Dafür ist es ne feine Sprache mit der sogar Laien wie ich was vernünftiges auf die Beine stellen können.

 

Besser jemand, der sich als "Laie" bezeichnet, als jemand, der sich überschätzt. Und das mit dem Gnome/KDE am Ende möchte ich jetzt lieber nicht kommentieren.

----------

## Knieper

 *Klaus Meier wrote:*   

> Und das mit dem Gnome/KDE am Ende möchte ich jetzt lieber nicht kommentieren.

 

Wuerde ich auch keinen Wert drauf legen. Wahrsch. ist die nicht qualifizierter als Deine Meinung zu PFWs. </DiskussionMitKlausMeier>

----------

## Necoro

Bin zu faul zum zitieren ... bitte einfach selber in den Kontext einfügen ^^

1.) "Python aus dem Base-System draußen haben": es stimmt schon, dass Python als Interpreter da nicht unbedingt reingehört ... aber mir ist python mit seiner überschaubaren Installationszeit (3 minuten bei mir) bei weitem lieber als obstruse C++-Libs (boost: 20 minuten)... und selbst Perl braucht länger

2.) "Zeit" ... ich will hier nochmal das Argument untermauern, dass der Algorithmus die Zeit bestimmt und nicht unbedingt die Sprache (bzw fällt dies auf modernen Rechnern nicht mehr unbedingt ins Gewicht). Die Möglichkeit coden zu können ohne sich um so sinnfreie Sachen wie Speicherallokierung zu kümmern, erleichtert in meinen Augen schon das konzentrieren auf den Algorithmus an sich.

3.) "Laien vs Professionals" ... ich halte es für ein Gerücht, dass Professionals besseren Code schreiben als Laien. Sicher: Er mag evtl sicherer sein - aber auch bei weitem obskurer und daher evtl schlechter zu überprüfen (hey: bei den Laien hast du die Fehler gefunden ... nur weil du sie bei den anderen nicht findest heißt es nicht dass es keine gibt - sie sind nur schwerer zu sehen). Außerdem verdient mit OpenSource kaum jmd Geld - daher ist der Anteil an Laien auch größer und notwendig (jeder fängt mal klein an...)

----------

## Klaus Meier

Necoro, meinst errnsthaft, dass hier Argumente von einem Laien etwas bewirken?

----------

## Knieper

 *Necoro wrote:*   

> 1.) "Python aus dem Base-System draußen haben": es stimmt schon, dass Python als Interpreter da nicht unbedingt reingehört ... aber mir ist python mit seiner überschaubaren Installationszeit (3 minuten bei mir) bei weitem lieber als obstruse C++-Libs (boost: 20 minuten)... und selbst Perl braucht länger

 

Fuer Perl gilt dasselbe wie fuer Python oder Boost (ist zB. nicht auf meinem System).

 *Quote:*   

> 2.) "Zeit" ... ich will hier nochmal das Argument untermauern, dass der Algorithmus die Zeit bestimmt und nicht unbedingt die Sprache (bzw fällt dies auf modernen Rechnern nicht mehr unbedingt ins Gewicht). Die Möglichkeit coden zu können ohne sich um so sinnfreie Sachen wie Speicherallokierung zu kümmern, erleichtert in meinen Augen schon das konzentrieren auf den Algorithmus an sich.

 

Das stimmt zum Teil ("Premature optimization is the root of all evil."), gilt aber mMn. nicht fuer Architekturen.

Wenn Du viel in Datenstrukturen rumwurschtelst werden Dir irgendwann die Pointer fehlen, weil die Standarddatentypen viel zu langsam sind. Im Kleinen (Pipidesktopanwendung) mag das alles funktionieren, sobald sich die Randbedingungen aendern (embedded, Server, viele Nutzer...) geht es nicht mehr. Hinzu kommen die teilweise lahmen Implementierungen in Standardbibliotheken. Ein qsort ist kein Quicksort, die vergurkten exponentiellen regex-Engines habe ich oft genug erwaehnt, Stringhandling kann sehr langsam werden... Im Uebrigen bin ich der Meinung, dass man die Speicherverwaltung ganz gut verstecken kann.

 *Quote:*   

> 3.) "Laien vs Professionals" ... ich halte es für ein Gerücht, dass Professionals besseren Code schreiben als Laien.

 

"Professionals" wuerde ich auch nicht als Koenner bezeichnen, die koennen bei mir auch unter "Laien" fallen.

Hast Du auch das Gefuehl, dass immer irgendwer ungefragt dazwischenbläkt?

----------

## Necoro

 *Klaus Meier wrote:*   

> Necoro, meinst errnsthaft, dass hier Argumente von einem Laien etwas bewirken?

  Ich sehe mich nicht als Laie ... zwar auch nicht als Professional (noch nicht)... irgendwo dazwischen ... und da ich schon Code gesehen hab von Programmen die von vielen auch sehr großen Kunden eingesetzt hab, weiß ich auch wovon ich sprech wenn ich meine "Professionals schreiben nicht unbedingt guten Code"... guter Programmierer und guter Softwareentwickler sind halt zwei verschiedene paar schuhe

----------

## Necoro

 *Knieper wrote:*   

> Wenn Du viel in Datenstrukturen rumwurschtelst werden Dir irgendwann die Pointer fehlen, weil die Standarddatentypen viel zu langsam sind. Im Kleinen (Pipidesktopanwendung) mag das alles funktionieren, sobald sich die Randbedingungen aendern (embedded, Server, viele Nutzer...) geht es nicht mehr. 

 

Das mag wirklich sein ... aber wir sprechen hier von einer in Maßstäben sehr kleinen Anwendung (portage). Eine große Serverapplikation auf System z mit tausenden Transaktionen in einer Minute würde ich auch nicht in Python implementieren... aber das hatte ja auch niemand vor

----------

## Knieper

 *Necoro wrote:*   

> Das mag wirklich sein ... aber wir sprechen hier von einer in Maßstäben sehr kleinen Anwendung (portage).

 

Aber fuer C zu gross?  :Wink:  S. oben - mich stoert vor allem das Design und die Abhaengigkeit.

----------

## Necoro

 *Knieper wrote:*   

>  *Necoro wrote:*   Das mag wirklich sein ... aber wir sprechen hier von einer in Maßstäben sehr kleinen Anwendung (portage). 
> 
> Aber fuer C zu gross?

 

Naja. Ich finde C sollte nur noch in performance-kritischen Anwendungen benutzt werden. Das Programmieren mit C ist halt um einiges komplexer als das in Python/Java/Ruby... Daher finde ich es schon richtig ^^.

"Design" - nun ja: da mögen einige Fehler in der Vergangenheit passiert sein. Aber bei einer für die Distri so überlebenswichtigen Aufgabe wie den Paketmanager kann man im Nachhinein nur sehr schwer große Designänderungen vornehmen. Auch da sei wieder auf die alternativen Manager verwiesen.

"Abhängigkeit" - dazu hab ich oben schon was geschrieben ...  :Smile:  Im Allgemeinen halte ich den C-Purismus für nicht zielführend... Denn wo ist jetzt genau das Problem an Python als Abhängigkeit? (bitte was anderes antworten als "weil es nicht sein sollte")

----------

## Anarcho

Zum Glück spielt in der Realität nicht immer die Performance einer Programmiersprache die entscheidende Rolle, sonst würden wir alle Gästebücher in Assembler schreiben müssen. Fragen wie Entwicklungszeit und Portabilität spielen auch eine Rolle und gerade da ist Java recht gut.

Gleichfalls sind die üblichen Vorurteile gegen Perl oder Java nicht immer zutreffend. Gerade im Vergleich zu C++ schneidet Java nicht schlechter ab. Einzig der erste Start ist langsamer weil dort nämlich der Bytecode noch nachkompiliert wird und voher die JVM geladen wird.

Siehe z.B.: http://kano.net/javabench/

Ein weiterer Vorteil in Performancefragen ist die JVM weil dort Bytecode auf der Zielplattform optimiert wird und nicht beim kompilieren. Bei OSS mag das egal sein, aber bei proprietärer Software weiss man eben nicht genau auf welcher Plattform sie läuft.

EDIT:

Der Link soll nicht beweisen das Java schneller ist als C++ aber demonstrieren, dass das Voruteil Java sei generell langsamer als C++ eben auch nicht stimmt.

----------

## Jokey_

 *Anarcho wrote:*   

> Zum Glück spielt in der Realität nicht immer die Performance einer Programmiersprache die entscheidende Rolle, sonst würden wir alle Gästebücher in Assembler schreiben müssen.

 

Oh shit, neuer Server... Nu muss ich mein Gästebuch schon wieder neu programmieren, son mist

*scnr*  :Wink: 

----------

## Knieper

 *Necoro wrote:*   

> Denn wo ist jetzt genau das Problem an Python als Abhängigkeit? (bitte was anderes antworten als "weil es nicht sein sollte")

 

Gern:

```

>du -sh /usr/lib/python2.4

44M     /usr/lib/python2.4

```

 *Anarcho wrote:*   

> Fragen wie Entwicklungszeit und Portabilität spielen auch eine Rolle und gerade da ist Java recht gut.

 

Bei der Portabilitaet kommt man kaum an C vorbei - es sei denn, man schreibt nur fuer verbreitete Desktopsysteme.

 *Quote:*   

> Gerade im Vergleich zu C++ schneidet Java nicht schlechter ab.

 

Ich bin auch kein C++-Freund, eigentlich ueberhaupt kein OO-Freund. Der Hang zu Fertigbastelloesungen und Bloatframeworks ist einfach zu gross, obwohl meine Ablehnung eher auf theoretischen Aspekten beruht.

----------

## Necoro

 *Knieper wrote:*   

>  *Necoro wrote:*   Denn wo ist jetzt genau das Problem an Python als Abhängigkeit? (bitte was anderes antworten als "weil es nicht sein sollte") 
> 
> Gern:
> 
> ```
> ...

 

Hmm ... na gut ... wobei ich mal darauf hinweisen möchte, dass ein equery s -e python die exaktere Zahl liefert. Denn in /usr/lib/python-2.4 liegen generell alle Python-Sachen (also auch Programme die in Python geschrieben sind)...

Ich möchte jetzt nicht diskutieren ob die Ersparnis von 44MB wirklich so viel bringt ^^

 *Quote:*   

>  *Anarcho wrote:*   Fragen wie Entwicklungszeit und Portabilität spielen auch eine Rolle und gerade da ist Java recht gut. 
> 
> Bei der Portabilitaet kommt man kaum an C vorbei - es sei denn, man schreibt nur fuer verbreitete Desktopsysteme.

 

Seh ich anders ... Bei C muss man sich selber um die Portabilität kümmern ("#ifdef" ftw) - bei den Sprachen der höheren Generationen muss man das nicht mehr machen - das macht die VM / der Interpreter für einen. Insofern ist die Portabilität bei Programmen solcher Sprachen im Allgemeinen höher.

 *Quote:*   

>  *Quote:*   Gerade im Vergleich zu C++ schneidet Java nicht schlechter ab. 
> 
> Ich bin auch kein C++-Freund, eigentlich ueberhaupt kein OO-Freund. Der Hang zu Fertigbastelloesungen und Bloatframeworks ist einfach zu gross, obwohl meine Ablehnung eher auf theoretischen Aspekten beruht.

 

Ohne dich beleidigen zu wollen ... aber ich glaube, du bist einfach jmd, der vor 20 Jahren mal Informatik studiert hat und seit dem alles neue ablehnt ...

----------

## Knieper

 *Necoro wrote:*   

> Seh ich anders ... Bei C muss man sich selber um die Portabilität kümmern ("#ifdef" ftw) - bei den Sprachen der höheren Generationen muss man das nicht mehr machen - das macht die VM / der Interpreter für einen.

 

Die in was geschrieben sind und erst von wem portiert werden muessen? Es gibt diese VMs iA. deshalb nur fuer Massensysteme.

 *Quote:*   

> Insofern ist die Portabilität bei Programmen solcher Sprachen im Allgemeinen höher.

 

Aber nur, wenn ein anderer die Arbeit macht.

 *Quote:*   

> Ohne dich beleidigen zu wollen ... aber ich glaube, du bist einfach jmd, der vor 20 Jahren mal Informatik studiert hat und seit dem alles neue ablehnt

 

Das stimmt nicht. Ich probiere auch gern "neuere" Sachen aus, zB. Mercury, Erlang, Ocaml, Haskell (ok, nur Mercury ist hier neuer). Das OO-Konzept gefaellt mir nicht, weil es meiner theoret. Ausbildung widerspricht - was heisst widerspricht, man sieht, dass der theoret. Unterbau nicht gerade schoen ist und man versucht, das zB. mit Coalgebren zu umschiffen. Funktionale Sprachen liegen mir da schon mehr, solange sie statisch und streng getypt sind. Aber mangels Portabilitaet oder fehlender Umgebung fallen die fuer die meisten Zwecke aus. Ich halte auch C bei weitem nicht fuer ideal (eher das Gegenteil), das Ergebnis ueberzeugt aber immer noch am meisten. Wenn es jmd. schafft, endlich einen vernuenftigen Compiler fuer schoene funktionale Sprachen zu entwickeln, dann bin ich auch von C weg.

----------

## l3u

Um mich hier auch mal einzuklinken ... ich bin auch der Meinung, daß man die Struktur des Portage-Baums mal überdenken sollte. Ich meine, es sind einfach dermaßen viele Programme mittlerweile in Portage gelandet, daß das ganze meines Erachtens etwas schwerfällig geworden ist.

Ein Sync dauert hier (Athlon XP 1800+, 512 MB RAM) schon ziemlich lang, das darauffolgende Cache-Update legt im Prinzip das System lahm. Der Portage-Baum hat hier grad 131.355 Dateien und 474 MB (wohlgemerkt ohne Distfiles!).

Ich hab keine Ahnung von Portage an sich. Ich hab mir auch noch nie den Quellcode angeschaut. Aber könnte man die Sache nicht folgendermaßen lösen: es gibt ja eix. Das ist rasend schnell beim Durchsuchen der Paketdatenbank. Man könnte doch hergehen und statt des gesamten Portage-Baums einfach den eix-Cache synchronisieren. Da sind gerade mal 2,9 MB im Moment. Die Mirror-Server stellen einfach einen aktuellen eix-Cache bereit, der wird dann mit dem lokalen verglichen. Daraus sieht man dann, was sich getan hat, welche Updates es gibt, etc.

Wenn man jetzt ein Programm installieren will, dann holt Portage die dafür notwendigen ebuilds und legt sie in einem ebuild-Repository ab. Gibt es Abhängigkeiten, dann werden diese ebenfalls von den Servern geholt. So hat man wirklich nur die ebuilds auf dem Rechner, die man tatsächlich braucht und der Traffic dürfte sich auch reduzieren, da ja nicht immer der komplette Baum synchronisiert wird, den man zu 90 % (?) nicht braucht.

Die Performance von Portage an sich ist nochmal ne andere Sache ...

----------

## firefly

 *Libby wrote:*   

> Um mich hier auch mal einzuklinken ... ich bin auch der Meinung, daß man die Struktur des Portage-Baums mal überdenken sollte. Ich meine, es sind einfach dermaßen viele Programme mittlerweile in Portage gelandet, daß das ganze meines Erachtens etwas schwerfällig geworden ist.
> 
> Ein Sync dauert hier (Athlon XP 1800+, 512 MB RAM) schon ziemlich lang, das darauffolgende Cache-Update legt im Prinzip das System lahm. Der Portage-Baum hat hier grad 131.355 Dateien und 474 MB (wohlgemerkt ohne Distfiles!).
> 
> Ich hab keine Ahnung von Portage an sich. Ich hab mir auch noch nie den Quellcode angeschaut. Aber könnte man die Sache nicht folgendermaßen lösen: es gibt ja eix. Das ist rasend schnell beim Durchsuchen der Paketdatenbank. Man könnte doch hergehen und statt des gesamten Portage-Baums einfach den eix-Cache synchronisieren. Da sind gerade mal 2,9 MB im Moment. Die Mirror-Server stellen einfach einen aktuellen eix-Cache bereit, der wird dann mit dem lokalen verglichen. Daraus sieht man dann, was sich getan hat, welche Updates es gibt, etc.
> ...

 

naja es gibt schon die Möglichkeit bei einem sync des portage-baums bestimme Bereiche auszuklammern, siehe https://forums.gentoo.org/viewtopic-t-173433.html

----------

## l3u

Is mir klar, aber woher will ich denn wissen, ob ich nicht doch mal was aus irgendeinem Bereich brauche? Ich weiß nicht, inwiefern das, was ich da geschrieben hab realisierbar wäre, aber das wär halt mal ne grundlegende Neuerung ...

----------

## Treborius

 *Anarcho wrote:*   

> 
> 
> Gleichfalls sind die üblichen Vorurteile gegen Perl oder Java nicht immer zutreffend. Gerade im Vergleich zu C++ schneidet Java nicht schlechter ab. Einzig der erste Start ist langsamer weil dort nämlich der Bytecode noch nachkompiliert wird und voher die JVM geladen wird.
> 
> Siehe z.B.: http://kano.net/javabench/
> ...

 

auf der selben seite findet man auch diesen link :

http://bruscy.multicon.pl/pages/przemek/java_not_really_faster_than_cpp.html

will sagen : mist kann man in jeder sprache schreiben, aber in C++ hab ich wenigstens die möglichkeiten, den mist zu finden und besser zu machen

und portable is c++ genau wie java, halte dich an den standard, und alles läuft

mach was system-abhängiges, dann bist in java verloren, und in 

C/C++ machste eben 

```

#ifdef

#endif

```

Beispiel : 

schonmal versucht in java daten vom mikrophon zu bekommen? 

Hab das noch mit der jdk1.5 versucht und dann aufgegeben,vielleicht gehts jetzt besser. 

Aber dann nehm ich mir lieber C++ // portaudio her....

zu dem portage problem :

ich finde, man sollte alles so lassen wie es ist, 

ein system ist zum arbeiten da, und nicht zum updaten, pakete suchen, etc

und bei dem zeitaufwand einer installation fällt sync und search nun wirlich nicht ins gewicht

ich freue mich aber auf paladius, mal sehen ob das projekt was wird

----------

## Inte

 *Treborius wrote:*   

> ein system ist zum arbeiten da, und nicht zum updaten, pakete suchen, etc. und bei dem zeitaufwand einer installation fällt sync und search nun wirlich nicht ins gewicht

 Vollzeitadministratoren und notorische "emerge -uDN world im loop"-Nutzer mögen das anders sehen, aber als ordinärer Desktop-Nutzer bleibt mir nur eins zu sagen: "Amen Bruder".  :Wink: 

----------

## hoschi

 *Think4UrS11 wrote:*   

>  *Knieper wrote:*   Ich nicht. Solange es da draussen nur halbwegs brauchbare Sprachen bzw. Compiler gibt, werde ich nicht aufhoeren zu noergeln.  
> 
> Ausschließlich nörgeln widerspricht aber dem Communitygedanken.
> 
> Bring doch mal ein besser konzeptioniertes 'new-portage' auf den Tisch.. 
> ...

 

Suchen unterhalb von 3 Minuten waere ja schon ein Vorteil...

Ausserdem koennte man ganz einfach damit anfangen Ebuilds eines Pakets in einer Datei zu sammeln. Was Portage in erste Linie lahm legt sind unglaublich unnoetig viele winzige Dateien...

Warum zehn Ebuild-Dateien fuer gcc? Wie waere es mit einer Datei in der die zehn Ebuilds zusammengefasst werden?

Programmieraufwand nahe Null - Ergebnis: Schneller

----------

## Jokey_

so manches davon wurde schon versucht

hat aber mehr nachteile als vorteile gebracht

bin jedoch immer für solche tests zu haben  :Smile: 

----------

## hoschi

 *Necoro wrote:*   

>  *Knieper wrote:*    *Necoro wrote:*   Denn wo ist jetzt genau das Problem an Python als Abhängigkeit? (bitte was anderes antworten als "weil es nicht sein sollte") 
> 
> Gern:
> 
> ```
> ...

 

Nun ja. Der Unterschied von Java zu anderen Sprachen ist, dass jemand (Sun) die Leute zwingt bestimmte Librarys/Compiler/Interpreter zu verwenden und man die Performance dem Bytecode opfert.

C/C++ ist sehr portabel und sehr effizent.

Java ist sehr portabel und sehr effizent.

Ist alles eine Frage der Definition.

Ein Systemprogrammierer und Programmierer mit hohen Leistungsanforderung (die selbst moeglichst schlanke Arbeit liefern sollen) werden Java verteufeln. Programmiere von breit gestreuten Clientanwendung die auch noch das hinterletzte Billighandy erreichen wollen, aber genauso ihre App auf einem Server sehen wollen, werden C/C++/D verteufeln.

----------

## think4urs11

 *hoschi wrote:*   

> Warum zehn Ebuild-Dateien fuer gcc? Wie waere es mit einer Datei in der die zehn Ebuilds zusammengefasst werden?
> 
> Programmieraufwand nahe Null - Ergebnis: Schneller

 

Eher noch genereller - _ein_ Paket -> _ein_ File (und eines fürs manifest wenns sein soll)

Alles schön mit XML strukturiert, von den metadata über die diversen (un)stable ebuilds und die diversen patches usw.; würde sich ja beinahe schon aufdrängen und der Tree wäre von jetzt auf gleich noch ca. 10% seiner derzeitigen Größe (bezogen auf Anzahl Dateien) und dank der größeren Dateien auch wesentlich besser in Bezug auf realer-Platz-auf-HD-belegt.

Das ganze dann noch aufgebohrt um eine Art Master-Portage-UI (zentrale Updates auf 'x' Maschinen wenigstens für gleiche arch) mit entsprechendem Logging etc. - so ganz grob ala Landscape für Klickbuntu ... hachja

----------

## return13

Das der Portage Baum sich in die falsche Richtung bewegt, muss man denk ich nicht drüber streiten.

Und das man den Paketmanager und die API mal grundlegend überarbeiten müsste ist wohl auch nicht neu.

Ob man C/C++ oder eine andere Sprache hierfür benutzt wäre mir persönlich recht egal. Jedoch darf man denk ich nicht einfach ignorieren das ein grundsätzlicher Bedarf herrscht den Portagebaum/Paketmanager zu bewegen.

Sicher - das System läuft zur Zeit und "never touch a running system", aber ich liebe Gentoo und sehe einfach wie es sich immer weiter in eine Einbahnstraße bewegt, und teilweise sich die Leute vehement wehren wenn es darum geht den Paketmanager anzufassen.

Der Kern einer jeden Distribution ist nunmal sein Paketmanger. Und am ende ist jede Distribution nur so gut wie der Paketmanger den er per default anbietet.

Gruß

Ender

----------

## artbody

Im prinzip finde ich portage nicht schlecht.

Klar das weiter oben beschriebene Verfahren mit mehr auf dem server lassen und nur das was ich brauch runterzuladen macht Sinn

Ob das mit portage aktualisieren nun 1min oder 10 min dauert ist mir egal.

Ein --sync wird in der Mittagspause gestartet

und -uDN über die Nacht laufen lassen.

Für mich sind viele Dinge die für Linux entwickelt wurden ein echtes Rätsel, aber wahrscheinlich liegt es daran, daß manche Entwickler gerne das Rad neu erfinden.

Wieviele Räder fast gleiches tun kann man an den unzähligen lib* sehen.

Dieser Zustand verhölt sich in etwa wie die Evolution 

Immer mehr unzusammenhängendes Zeug wird produziert.

Solange bis es fast nicht mehr zu verwalten ist.

Und dann von einem Entwickler zu verlangen er soll die Verwaltung neu programmieren mit noch mehr features für noch mehr unzusammenhängendes Zeug, das grenzt schon an Revolution

Ein normaler Laie wäre schon froh, wenn er nach einem Update

noch alle In/Output Geräte in der zugedachten Funktion wiederfindet.

Hier wäre meines Erachtens eher der richtige Ansatz für eine gute Distribution

die MASKED tabelle um einige Stufen zu erweitern

devel

masked

test

stable

hardened

damit könnte ein user doch echt mehr anfangen, denn ich käme nicht auf die Idee "devel -test " auf meinem Arbeitssystem zu installieren

aber bei stable möchte ich davon ausgehen, daß meine Maus noch tut, sowie der Drucker druckt, das keyboard deutsch schreibt....und der nvidiatreiber auch noch geht.

Letzteres ist bei derzeitiger Verfahrensweise bei Gentoo nicht gegeben.

Es dürfte sich so ungefähr wie beim Mandrake cooker verhalten.

Alles immer testsoftware für die user.

Ich möchte hier aber auch erwähnen, daß ich zur Zeit 3 Gentoosysteme auf 3 Festplatten installiert habe

Eins wird upgedatet, wenn alles tut dann das nächste.

Das 3. ist für mich zum "WEB"-spielen sozusagen und gibt im großen und ganzen meinen onlineserver wieder.

Aber ein update ohne vorher diesen auf system 2 getestet zu haben ist zur Zeit undenkbar.

Das ist ein ARMUTSZEUGNIS für Gentoo

Es ist der einzige Punkt der mich an Gentoo seit 3 Jahren stört

Sowas ließe sich mit einer feineren Staffelung von MASKED sicher vermeiden.

Sorry falls das jetzt nicht zu portage gehört, aber gesagt werden muss es ab und zu

----------

## franzf

 *artbody wrote:*   

> Für mich sind viele Dinge die für Linux entwickelt wurden ein echtes Rätsel, aber wahrscheinlich liegt es daran, daß manche Entwickler gerne das Rad neu erfinden.
> 
> Wieviele Räder fast gleiches tun kann man an den unzähligen lib* sehen.
> 
> Dieser Zustand verhölt sich in etwa wie die Evolution 
> ...

 

Nur die Existenz von vielen lib* heißt doch nicht dass alle das selbe tun, oder? Außerdem gibt es verschiedene Gründe warum sich evtl. ein Entwickler hinsetzt und das selbe nochmal schreibt:

* Der originäre Autor die Entwicklung auf eigene Faust betreibt und auf Feature-Requests gar nicht oder mit einem NEIN! antwortet, man das aber unbedingt haben will - dann forkt man eben (wenn es die Lizenz erlaubt). Oder im Falle XFree86 -> X.org waren es die Lizenzen, weshalb geforkt wurde.

* Die Wartung des Codes ist eine Qual, neue Features nur mit ziemlicher Akrobatik möglich (den Diskussionen zu entnehmen ist/war das so bei Portage). Aus diesem Missstand hat sich beispielsweise paludis entwickelt.

Und es gibt sicher noch mehr Punkte, würde aber Zeit kosten nachzudenken und der Post wird dann auch zu lang  :Wink: 

Das mit dem "immer mehr unzusammenhängendes Zeug" versteh ich nicht. Das ist bei einem so schönen System wie linux einfach so. Viele kleine Libs für viele kleine unterschiedliche Aufgaben. Wenn dem nicht so wäre hätte man Zustände wie bei Windows! Da wird dann einfach wenn man mehr braucht als das was Windows anbietet komplette libs (z.B. libxml) statisch ins binary gelinkt oder separat als lib mit in das eigene Programmverzeichnis kopiert. Das ist Platzverschwendung (in meinen Augen schlimmer als das was portage macht...) und bei den teueren Lizenzen auch ein Sicherheitsrisiko - Gibts einen Bug in einer der mitgelieferten Bibliotheken bleibt einem fast nix anderes übrig als sich eine Version der Software zu besorgen die den Fehler behebt - außer man hat noch Ansprüche auf updates...

 *Quote:*   

> ="artbody"Ein normaler Laie wäre schon froh, wenn er nach einem Update
> 
> noch alle In/Output Geräte in der zugedachten Funktion wiederfindet.
> 
> Hier wäre meines Erachtens eher der richtige Ansatz für eine gute Distribution
> ...

 

Sorry, aber das versteh ich jetzt echt nicht! Deine Probleme mit der Tastatur sind definitiv NICHT auf Gentoo zurückzuführen, sondern eben auf eindeutig als "Testing" markierte Pakete:

 *https://forums.gentoo.org/viewtopic-t-646679.html wrote:*   

> @musv 
> 
>  du hattest recht 
> 
>  hal und seine Schikane machens möglich 
> ...

 

hal-Useflag gibt's nur beim x11-base/xorg-server-1.4.0.90-r2 - und der ist testing.

Der beschriebene Bug samt fix (im verlinkten Thread) bezieht sich auf x11-drivers/xf86-input-evdev-1.2.0 - ebenfalls Testing.

Also entweder weißt du nicht so recht was du tust - oder was du sagst... Denn dein Vorschlag mit noch feinerer Staffelung der Maskierungen würde in deinem Fall auch nicht weiter helfen!

Ich hatte auch schon Probleme mit Tastatur - schuld war ebenfalls xorg-server-1.4.0... Downgrade auf stable und alles war gegessen!

Grüße

Franz

----------

## Knieper

 *Think4UrS11 wrote:*   

>  *hoschi wrote:*   Warum zehn Ebuild-Dateien fuer gcc? Wie waere es mit einer Datei in der die zehn Ebuilds zusammengefasst werden? Eher noch genereller - _ein_ Paket -> _ein_ File (und eines fürs manifest wenns sein soll)

 

Noch eine Variante: Mein obiger Ansatz (eine Beschreibungsdatei.bz2 aller Pakete, Verzeichnisbaum nur installierter Pakete) und nur die Ebuild-Dateien, die nach Keyword installierbar sind (keine maskierten Pakete).

 *Quote:*   

> Alles schön mit XML strukturiert

 

*kotz - wozu das denn nun schon wieder? Und das ganze dann von Python parsen lassen und sich wundern, wieso es wieder lahm ist?

 *Quote:*   

> würde sich ja beinahe schon aufdrängen und der Tree wäre von jetzt auf gleich noch ca. 10% seiner derzeitigen Größe (bezogen auf Anzahl Dateien) und dank der größeren Dateien auch wesentlich besser in Bezug auf realer-Platz-auf-HD-belegt.

 

Nur dass noch mehr Zeit vergeudet wird und das Problem nicht bestehen wuerde, wenn man die Dateien ueberhaupt nicht erst runterladen muesste.

----------

## artbody

@franzf

 *Quote:*   

> hal-Useflag gibt's nur beim x11-base/xorg-server-1.4.0.90-r2 - und der ist testing.
> 
> Der beschriebene Bug samt fix (im verlinkten Thread) bezieht sich auf x11-drivers/xf86-input-evdev-1.2.0 - ebenfalls Testing.
> 
> 

 

WIESO ist er dann nicht MASKED   :Question:   :Rolling Eyes:   :Embarassed: 

Ich glaub du wiedersprichst dir da selbst.

Oder du hast nicht verstanden was ich meinte.

Ich versuche es nochmal nur für dich als NICHTLAIE

 :Idea:  ein Software Packet wird neu dazugenommen oder weiterentwickelt   :Arrow:  Status DEVEL

sollte also bei einem Update mit einer auf STATUS "stable" gesetzten Maschine nicht automatisch installiert werden,und   ich als enduser hätte dann auch nie ein Problem damit.

 :Idea:  ein Software Packet ist noch mitten in der Entwicklung aber einiges tut schon aber bugy etc....  :Arrow:  Status MASKED

 :Idea:  ein Software Packet ist fast fertig und der/die Entwickler geben es zum testen frei.  :Arrow:  Status TEST

ich als enduser hätte dann immer noch kein Problem damit.

 :Idea:  ein Software Packet ist fertig . Keine bekannten Bugs und es läßt sich installieren  :Arrow:  Status STABLE

 :Idea:  ein Software Packet ist fertig und hat sich bewährt . Keine bekannten Bugs und es läßt sich installieren  :Arrow:  Status HARDENED

Stable wäre für eine Workstation sicher ausreichend

Status HARDENED wäre für Mehrbenutzer und Server sicher die bessere Alternative

Dazu folgendes

Ich habe als einziges in dieser Sache ein update gemacht.

emerge --sync

emerge -uDNav world

emerge -euavDN world

revdep-rebuild

...

ohne irgendwo maskierte Packete zu verwenden.

Also genau wie in der Instalationsdocu beschrieben.

Ich folgere daraus daß diese Packete NICHT TEST sind.

Wenn das dann am Endpunkt des Netzwerkes in irgendeiner DB steht, und vom Entwickler nicht so gemeint war, bringt das wenig.

Ich frage dich also wie es möglich ist, daß Testsoftware dann auf mein Rechner kommt?

 *Quote:*   

> 
> 
> Also entweder weißt du nicht so recht was du tust - oder was du sagst... Denn dein Vorschlag mit noch feinerer Staffelung der Maskierungen würde in deinem Fall auch nicht weiter helfen! 

 

A: 

ich bin kein Häcker - sondern fallls erlaubt - ein einfacher seit 92 freischaffender Künstler (davor FH Konstrukteur Maschinenbau) mit etwas Erfahrung was Linux angeht.(habe seit 1998 kein Windows mehr)

Grob gesagt ein PHP/Perl-spagetticode und mein Webserver zu administrieren bekomme ich meist ohne fragen hin .

Mir jetzt hier die Mühe zu machen alle deine kleinen Fragen und Problemchen mit deinem Rechner ... nachzuforschen,

um daraus eine eventuell ableitbare Fehlbarkeit deinerseits zu beleuchten, erspare ich mir

Bringt ja auch nichts. Mir und dir stiehlt es nur die Zeit.

Zurück zum eigentlichen Problem

B:

Mit dem Vorschlag der feineren Staffelung wären 

Spontane Testsoftwareausfälle wie derzeit nach fast jedem update seltener.

Kurzes Beispiel:

NEUINSTALATION nach Anleitung Gentoo Linux AMD64 Handbook

```
gdm enlightenment......

USE -kde ....

.....

emerge --sync

emerge -ueavDN world

.....

und dann [b]100[/b] mal, wenn's reicht

emerge --skipfirst --resume 

* ERROR: gnome-base/libgnome-2.20.1.1 failed.

emerge --skipfirst --resume

.....
```

Man wiederhole mehrmals emerge -ueavDN world mit * emerge --skipfirst --resume 

bei jedem Durchgang verringert sich die Fehlerquote

Klingt ganz schön M$ oder?

Man beachte Neuinstalation - gnome und dessen Abhängigkeiten läßt sich nicht ohne Fehler installieren

...

Dies ist nicht als Frage warum, sondern nur als Beweiß anzusehen, daß hier Nachbesserungsbedarf am Grundkonzept von Masked besteht.

Sehe das jetzt also auch nicht als Angriff, sondern wirklich als Verbesserungsvorschlag

Was spräche dagegen Masked zu staffeln?

Auch andere Distributionen haben gestaffelte Systeme

Es würde Laien wie mich davor bewahren die Götter des Systems mit meiner eigenen Unfähigkeit zu belästigen

und mir pro Monat mindestens 3 Arbeitstage Zeit sparen.

Es gibt als durchaus auch normale Anwender, welche mit etwas Aufwand ein gutes Linux zu schätzen wissen.

Und auch wenn ich Laie bin, dafür kämpfe daß es noch besser wird

----------

## pablo_supertux

 *artbody wrote:*   

> @franzf
> 
>  *Quote:*   hal-Useflag gibt's nur beim x11-base/xorg-server-1.4.0.90-r2 - und der ist testing.
> 
> Der beschriebene Bug samt fix (im verlinkten Thread) bezieht sich auf x11-drivers/xf86-input-evdev-1.2.0 - ebenfalls Testing.
> ...

 

es ist MASEKD, masked by keyword (siehe letzte Zeile)

```

# Copyright 1999-2008 Gentoo Foundation

# Distributed under the terms of the GNU General Public License v2

# $Header: /var/cvsroot/gentoo-x86/x11-base/xorg-server/xorg-server-1.4.0.90-r2.ebuild,v 1.1 2008/01/18 21:31:33 dberkholz Exp $

# Must be before x-modular eclass is inherited

#SNAPSHOT="yes"

inherit x-modular multilib

OPENGL_DIR="xorg-x11"

MESA_PN="Mesa"

MESA_PV="7.0.2"

MESA_P="${MESA_PN}-${MESA_PV}"

MESA_SRC_P="${MESA_PN}Lib-${MESA_PV}"

SRC_URI="${SRC_URI}

    mirror://sourceforge/mesa3d/${MESA_SRC_P}.tar.bz2

    http://xorg.freedesktop.org/releases/individual/xserver/${P}.tar.bz2"

DESCRIPTION="X.Org X servers"

KEYWORDS="~alpha ~amd64 ~arm ~hppa ~ia64 ~mips ~ppc ~ppc64 ~sh ~sparc ~x86 ~x86-fbsd"

```

und wenn ich versuche es zu emergen:

```

yanezp@klingsor:~> emerge =x11-base/xorg-server-1.4.0.90-r2 -pv

Password:

These are the packages that would be merged, in order:

Calculating dependencies -

!!! All ebuilds that could satisfy "=x11-base/xorg-server-1.4.0.90-r2" have been masked.

!!! One of the following masked packages is required to complete your request:

- x11-base/xorg-server-1.4.0.90-r2 (masked by: ~x86 keyword)

```

----------

## Knieper

 *artbody wrote:*   

> 
> 
> Ich habe als einziges in dieser Sache ein update gemacht.
> 
> emerge --sync
> ...

 

Und wieso mit emptytree? Steht das in der Doku? Und es heißt "Installation" und "Pakete", um Deine Spitzenreiter zu verbessern.  :Wink: 

----------

## Gibheer

@artbody: ich habe jetzt mal kurz gesucht, aber kein emerge --info von dir gefunden. Kannst du uns die Ausgabe mal geben, damit wir wissen, was wir einstellen muessen um deine Probleme nachvollziehen zu koennen?

----------

## artbody

@Gibheer

Das eine Problem x11-base/xorg-server-1.4.0.90-r2 ... existiert momentan wegen Neuinstalation nicht mehr

Die Neuinstalation hängt aber immer wieder... Soll aber nicht hier behandelt werden.

Ich werde dazu ein passendes Thema aufmachen, wenn erforderlich.

Hier möchte ich im Prinzip nur den gestaffelten MASKED Vorschlag machen.

Das war es eigentlich

----------

## franzf

 *artbody wrote:*   

> Ich versuche es nochmal nur für dich als NICHTLAIE
> 
>  ein Software Packet wird neu dazugenommen oder weiterentwickelt   Status DEVEL
> 
> sollte also bei einem Update mit einer auf STATUS "stable" gesetzten Maschine nicht automatisch installiert werden,und   ich als enduser hätte dann auch nie ein Problem damit.
> ...

 

Grundsätzlich ist der Gedanke ja nicht schlecht, wobei in meinen Augen einzig sinnvoll der zusätzliche "HARDENED"-Status. Einen Unterschied zwischen DEVEL und MASKED erkenne ich nicht (bzw. dessen Notwendigkeit). Hardmasked werden Pakete, bei denen es bekannt ist, dass sie Probleme bereiten, oder komplett neu im Tree sind (z.B. aktuell kde-4.0.0). Insgesamt hoffe ich ja schon dass Software weiterentwickelt wird, sonst hätte ich hier ja gar nix mehr zum emergen  :Smile:  Dafür aber einen neuen MASKED-Slot härter als HARDMASKED einzuführen finde ich übertrieben.

Und dass du ein "fast fertiges Softwarepaket" in Testing legen willst finde ich recht selbstironisch, da genau das dein Problem war - denn xorg-server > 1.3 == TESTING (also ~x86, ~amd64, ...). Und genau hier wird jetzt ein emerge --info deinerseits sehr interessant. Denn wenn du ohne eigenes Zutun und nur durch ein emerge -uDN world diese Software aufs System bekommen hast bedeutet dies dass du ein komplettes Testing-System fahren musst - ergo steht in deiner make.conf irgendwo ein ACCEPT_KEYWORDS="~x86" (oder eben ~amd64, oder was auch immer). Dass dies böse ist und auch so enden kann ist sehr wohl bekannt. Darum kann und wird es kein Fehler seitens Gentoo sein und auch ein feiner abgestuftes MASKING-System wird dich nicht vor Problemen schützen!

Aber das Argument schlechthin dagegen: Wer soll das verwalten? Hat sich doch eh schon gezeigt dass es im Moment bei Gentoo kriselt, Hilferufe seitens der Devs wegen Überarbeitung war auch schon hier und da zu hören.

Und zum Schluss noch die Aufforderung bei Problemen mal ein kleines Statement auf https://bugs.gentoo.org hinterlassen. Denn wenn du Probleme hast kannst du damit sicherlich am ehesten auf eine Lösung deiner Probleme hoffen (b.g.o hat grundsätzlich eine recht hohe Dev-Dichte  :Wink: ) und auch andere werden gewarnt/sehen dass sie nicht die einzigen sind. So trägst du am Ende auch noch dazu bei das System Gentoo besser zu machen  :Smile: 

----------

## artbody

Nun das mit dem 

#ACCEPT_KEYWORDS="~amd64" ist eigentlich nur auf meinem Testsystem auskommentiert.

Da aber das oben genannte system, wegen coreutils abgeschossen, nicht mehr existiert, kann ich dir auch das emerge --info nicht mehr geben

https://forums.gentoo.org/viewtopic-t-650240.html

naja ein zusätzliche "HARDENED"-Status wäre schon was.

Im Prinzip teste ich ja gerne mal die eine oder andere Software, nur reichen meine Programmierkenntnisse nicht weit genug um an größeren Sachen aktiv mitzumachen.

Als Tester sicher, das mach ich ja eh immer mal wieder.

Bugbericht schreiben   :Arrow:  zu geringe English Kenntnisse um diesen vernünftig und allgemeinverständlich zu verfassen. (englische Texte lesen und verstehen geht so - aber verfassen   :Embarassed:  setzen 5   :Crying or Very sad:  )

Meine letzte Englischstunde hatte ich so mit 20, also fast vor 25 Jahren.

----------

## think4urs11

 *artbody wrote:*   

> Mit dem Vorschlag der feineren Staffelung wären 
> 
> Spontane Testsoftwareausfälle wie derzeit nach fast jedem update seltener.
> 
> ...
> ...

 

Du übersiehst dabei nur eine ziemlich wichtige Kleinigkeit - wo ist der Schrank den wir mal schnell aufmachen aus dem dann die ganzen qualifizierten, motivierten Developer springen und sich an die Arbeit machen?

 *Quote:*   

> Gentoo is made up of 275 active developers, of which 42 are currently away.

 

 *Quote:*   

> 12355 Packages / 25279 Ebuilds

 

Dazu kommen noch sagen wir ¨50 User die via sunrise regelmäßig aktiv sind und ~2.000 ebuilds/Pakete in den diversen anderen overlays oder auf diversen Websites verteilt.

... abgesehen davon sind wir inzwischen meilenweit vom eigentlichen Thema weg ....

----------

## Finswimmer

 *Knieper wrote:*   

> und nur die Ebuild-Dateien, die nach Keyword installierbar sind (keine maskierten Pakete).

 

find|grep ebuild|xargs grep -i keywords|grep -i x86|wc:

25108

find|grep ebuild|wc:

25659

Bei x86 ist die Differenz nicht so groß -> 551

pcc hat da schon: 6234

Tobi

----------

## Knieper

 *Finswimmer wrote:*   

> 
> 
> find|grep ebuild|xargs grep -i keywords|grep -i x86|wc:
> 
> 25108
> ...

 

Und bei der Zahl kamen Dir keine Zweifel? Du suchst selbst auskommentierte KEYWORD-Zeilen und nur danach, ob ein x86 vorkommt. Egal ob x86, ~x86, x86-fbsd oder ~x86-fbsd. Wenn ich das mal durchgehe (ohne jetzt auf 100% Korrektheit zu achten):

maskiert:

```

>grep  -R --include=*.ebuild -e "^KEYWORDS=.*~x86[^-]" /usr/portage/* | wc -l

12002

```

unmaskiert:

```

>grep  -R --include=*.ebuild -e "^KEYWORDS=.*[^~]x86[^-]" /usr/portage/* | wc -l

13763

```

dann ist das der halbe Tree.

----------

## Finswimmer

 *Knieper wrote:*   

>  *Finswimmer wrote:*   
> 
> find|grep ebuild|xargs grep -i keywords|grep -i x86|wc:
> 
> 25108
> ...

 

Hmm. x86-fbsd habe ich in meiner Überlegung vergessen.

Aber: Ich als stable x86 User möchte natürlich auch ab und zu ein unstable (~x86) Paket nutzen. Daher hab ich aus gutem Grund nicht zwischen stable und unstable unterschieden.

Tobi

PS: Auskommentierte Keywords? Nach was wird dann entschieden, auf welcher Architektur das läuft?

(Bin grad an einem Win-Rechner)

----------

## Knieper

 *Finswimmer wrote:*   

> Aber: Ich als stable x86 User möchte natürlich auch ab und zu ein unstable (~x86) Paket nutzen. Daher hab ich aus gutem Grund nicht zwischen stable und unstable unterschieden.

 

Das steht ja dann zB. in /etc/portage/package.keywords und kann dementsprechend behandelt werden. Du willst doch nicht 12000 Ebuilds kopieren, nur weil Du 10 ~x86 Pakete installierst?

 *Quote:*   

> PS: Auskommentierte Keywords? Nach was wird dann entschieden, auf welcher Architektur das läuft?

 

Du hast die Faelle doppelt gezaehlt, bei denen:

```

#KEYWORDS="..."

KEYWORDS="..."

```

im Ebuild steht. Sind nur knapp 70 Faelle. Ich habe ja auch die leeren Keywords ("") weggelassen (auch ~70) oder "-*" (0).

----------

## Finswimmer

 *Knieper wrote:*   

>  *Finswimmer wrote:*   Aber: Ich als stable x86 User möchte natürlich auch ab und zu ein unstable (~x86) Paket nutzen. Daher hab ich aus gutem Grund nicht zwischen stable und unstable unterschieden. 
> 
> Das steht ja dann zB. in /etc/portage/package.keywords und kann dementsprechend behandelt werden. Du willst doch nicht 12000 Ebuilds kopieren, nur weil Du 10 ~x86 Pakete installierst?
> 
> 

 

Hmm. Dann braucht man aber eine veränderte Suche, damit man die Pakete(+Versionen) angezeigt bekommt, die es gibt, und die man nicht auf dem Rechner hat.

 *Knieper wrote:*   

> 
> 
>  *Quote:*   PS: Auskommentierte Keywords? Nach was wird dann entschieden, auf welcher Architektur das läuft? 
> 
> Du hast die Faelle doppelt gezaehlt, bei denen:
> ...

 

Ja... Da hast du natürlich recht, das habe ich nicht beachtet.

Auf jedenfall ein guter Ansatz. 

Tobi

----------

## hoschi

Schaut euch mal die aktuellen News an, die haben doch beinahe genau das gemacht, was ich schon laenger wollte.

Einfach mal die Information mehrere Dateien in eine Packen!

Jetzt noch die Ebuilds verschmelzen, bitte  :Very Happy: 

----------

## Necoro

 *hoschi wrote:*   

> Schaut euch mal die aktuellen News an, die haben doch beinahe genau das gemacht, was ich schon laenger wollte.
> 
> Einfach mal die Information mehrere Dateien in eine Packen!

 

Naja ... soo neu ist das nicht  :Smile:  ... die GLEP stammt aus 2005 ... die mussten halt u.a. 1 Jahr warten um nix kaputt zu machen  :Wink: 

----------

## Knieper

 *hoschi wrote:*   

> Jetzt noch die Ebuilds verschmelzen, bitte 

 

Ich finde die Idee fast so krank, wie die xml-Idee. Zwei unterschiedliche Paketversionen koennen zwei vollkommen verschiedene Ebuilds besitzen. Wieso sollte man diese Daten zusammenlegen? Das widerspricht jeglicher Unixphilosophie. Die paar kB wuerden den Braten nicht fett machen, wenn man unnoetige Paketinformationen gar nicht auf dem Rechner haette. Womit wir wieder bei meinem Vorschlag waeren... Aber der wird wahrsch. erst 2011 umgesetzt, wenn es andere Distris gibt. Mal sehen, wie sich Arch und T2 entwickeln...

----------

## hoschi

 *Necoro wrote:*   

>  *hoschi wrote:*   Schaut euch mal die aktuellen News an, die haben doch beinahe genau das gemacht, was ich schon laenger wollte.
> 
> Einfach mal die Information mehrere Dateien in eine Packen! 
> 
> Naja ... soo neu ist das nicht  ... die GLEP stammt aus 2005 ... die mussten halt u.a. 1 Jahr warten um nix kaputt zu machen 

 

Nach dem Edit der News klingt das auch nicht mehr so neu...seit einem Jahr.

----------

## hoschi

 *Knieper wrote:*   

>  *hoschi wrote:*   Jetzt noch die Ebuilds verschmelzen, bitte  
> 
> Ich finde die Idee fast so krank, wie die xml-Idee. Zwei unterschiedliche Paketversionen koennen zwei vollkommen verschiedene Ebuilds besitzen. Wieso sollte man diese Daten zusammenlegen? Das widerspricht jeglicher Unixphilosophie. Die paar kB wuerden den Braten nicht fett machen, wenn man unnoetige Paketinformationen gar nicht auf dem Rechner haette. Womit wir wieder bei meinem Vorschlag waeren... Aber der wird wahrsch. erst 2011 umgesetzt, wenn es andere Distris gibt. Mal sehen, wie sich Arch und T2 entwickeln...

 

kB? Wer redet davon Speicherplatz einzusparen?

Die Anzahl der Dateien in Portage liegt weiter ueber 100.000, Portage ist so lahm, weil es so viele Dateien gibt. Viele kleine Dateien sind Gift fuer jede Datenverarbeitung.

Portage ist wie ein Schrank mit Leitz-Ordnern, und in jedem Ordner ist genau EIN Blatt abgeheftet.

----------

## Max Steel

es stimmt schon, so wie er ist, kann der PRotage-Baum nicht bleiben, aber wie will man es anders machen, wenn man die Dateien parsen muss um die benötigten Infos rauszusuchen wird das ganze auch nicht schneller, nein mann muss es irgendwie anders machen, aber bisher weis man nicht wie.

WEnn man gleiche zusammenfasst, wäre es schon einfacher, aber dann muss man für Versionen die komplett unterschiedlich gebaut werden wieder diese Datei wieder mit 2Dingern vollschreiben die eigentlich dasselbe machen, oderaber 2 Dateien für diese Versionen, wodurch das ganze nicht viel weniger wird, außer einigen Versiondumps lassen sich da wenige EBuilds zusammenfassen.

Aber davon mal abgesehen geht es hier doch darum Portage in eine andere Proggersprache zu bringen, und nicht den Portage-Baum anders zu gestalten.

----------

## Knieper

 *hoschi wrote:*   

> kB? Wer redet davon Speicherplatz einzusparen?
> 
> Die Anzahl der Dateien in Portage liegt weiter ueber 100.000, Portage ist so lahm, weil es so viele Dateien gibt. Viele kleine Dateien sind Gift fuer jede Datenverarbeitung.

 

 *Quote:*   

> Portage ist wie ein Schrank mit Leitz-Ordnern, und in jedem Ordner ist genau EIN Blatt abgeheftet.

 

S. oben. Das Problem ist nicht das Prinzip der Dateien, sondern wirklich nur ein Problem der Anzahl und des Aufbaus selbiger.

 *Max Steel wrote:*   

> es stimmt schon, so wie er ist, kann der PRotage-Baum nicht bleiben, aber wie will man es anders machen, wenn man die Dateien parsen muss um die benötigten Infos rauszusuchen wird das ganze auch nicht schneller, nein mann muss es irgendwie anders machen, aber bisher weis man nicht wie.

 

Das Parsen macht man sich selbst schwer durch das ulkige Format. Die Anzahl kann man ganz einfach reduzieren, das habe ich aber alles weiter oben schon geschrieben.

 *Quote:*   

> Aber davon mal abgesehen geht es hier doch darum Portage in eine andere Proggersprache zu bringen, und nicht den Portage-Baum anders zu gestalten.

 

Den beknackten Thementitel hat ein Moderator gewaehlt. Mein Beitrag ist nur der erste und der Hauptkritikpunkt richtete sich an Python als Abhaengigkeit.

----------

## Finswimmer

 *Knieper wrote:*   

>  *Quote:*   Aber davon mal abgesehen geht es hier doch darum Portage in eine andere Proggersprache zu bringen, und nicht den Portage-Baum anders zu gestalten. 
> 
> Den beknackten Thementitel hat ein Moderator gewaehlt. Mein Beitrag ist nur der erste und der Hauptkritikpunkt richtete sich an Python als Abhaengigkeit.

 

Moep. Dein "Thread", dein Titel.   :Wink:  Darfst ihn gerne aendern, mir ist damals nichts besseres eingefallen, und hat die letzten 3 Seiten auch gut gepasst  :Wink: 

Man koennte das natuerlich auch trennen, wenn weiterhin Diskussionsbedarf bei dem Portagetree besteht...

Ontopic:

Ich denke es ist sehr schwer, Portage auf eine neue Sprache umzubiegen. Da ist der Ansatz mit Paludis schon besser. Einfach zwei "Systeme" nebeneinander, das Bessere wird sich durchsetzen.

Allerdings sehe ich den ganzen "Stress" nicht. Dann dauert ein komplettes Update berechnen mal 2 Min. Na und. Das Kompilieren dauert locker das 20-fache...

Tobi

----------

## Knieper

 *Finswimmer wrote:*   

> Allerdings sehe ich den ganzen "Stress" nicht. Dann dauert ein komplettes Update berechnen mal 2 Min. Na und. Das Kompilieren dauert locker das 20-fache...

 

Aber es dauert es ja ueberfluessigerweise. Und nun rechne mal zusammen, wieviele Minuten alle Nutzer zusammen warten und wieviele TB an Daten unnuetz ueber das Netz geschaufelt und auf Nutzerplatten gespeichert werden.  :Smile:  Ich frage mich echt, was ich mit all den Paketdaten und Ebuilds soll. Ein - zwei Verzeichnisdateien und den Rest auschecken wenn man ihn braucht. Das koennte man durchaus stufenweise implementieren.

----------

## think4urs11

 *Knieper wrote:*   

> Aber es dauert es ja ueberfluessigerweise.

 

Zugegeben aber wirklich stören muß es einen nicht. Auch Männer sind multitaskingfähig. Früher hat man sich einen Kaffee geholt während Windows bootet, heute läuft in der Zeit ein Sync - Zeitverlust 0.

Oder für die ganz coolen: Der Sync wird durch den Bluetooth Annäherungssensor gestartet sobald man mit seinem Handy morgens das erste Mal in Reichweite des Rechners kommt. Bis die Jacke am Haken hängt und man seine Gräten in den Stuhl sortiert hat ist die Maschine bereit.

 *Knieper wrote:*   

> Und nun rechne mal zusammen, wieviele Minuten alle Nutzer zusammen warten

 

Kann man alles so und so sehen - zynisch betrachtet: wer einem emerge --sync passiv beiwohnt hat kein sonderlich aufregendes Restleben.  :Smile: 

 *Knieper wrote:*   

> und wieviele TB an Daten unnuetz ueber das Netz geschaufelt und auf Nutzerplatten gespeichert werden. 

 

Datenmengenmäßig ist es sicher eine Hausnummer aber im Vergleich zu dem was Max Muster sonst so durchs Netz bläst auch irrelevant.

Und bei mehreren Maschinen im eigenen LAN entfällt das Zeitargument sowieso komplett; kompletter sync gegen lokalen Mirror im Schnitt <=~30 Sekunden - wer hier unbedingt noch meint es ist (zu) langsam ist ein ricer  :Wink: 

Traffic im LAN ist eh uninteressant (wenn das Netz gescheit designt ist, in einem ARCNet würde es mich auch stören)

 *Knieper wrote:*   

> Ich frage mich echt, was ich mit all den Paketdaten und Ebuilds soll. Ein - zwei Verzeichnisdateien und den Rest auschecken wenn man ihn braucht.

 

Hätte u.a. den Nachteil das man bei offline-Systemen nicht alle nötigen Daten direkt vorliegen hat und ggf. (Stichwort auschecken) sich eine Abhängigkeit zu svn/git/foo einhandelt die man vielleicht nicht möchte.

Und das Argument für die paranoiden unter uns - was geht es den Admin eines tree-mirrors an was ich mir wann installiere? Schlimm genug das es der Admin des sources-mirrors weiß.

Und ob man nun _ein_ File pro Paket hat das in XML oder Suaheli oder als binary-blob hat oder wie jetzt zwischen 3 und ~100 je nachdem wieviele Versionen mit entsprechenden Patches usw. im Tree sind macht schon einen Unterschied. XML ist nicht immer schlecht - wenn mans gescheit macht  :Wink: 

Abgesehen davon ist die Diskussion sowieso müßig.

Es wird niemand portage auf c++/mono/java oder sonstwas umschreiben. Viel wahrscheinlicher wird portage irgendwann/vielleicht/möglicherweise durch pkgcore, paludis oder portato on speed ersetzt.

----------

## hoschi

 *Max Steel wrote:*   

> es stimmt schon, so wie er ist, kann der PRotage-Baum nicht bleiben, aber wie will man es anders machen, wenn man die Dateien parsen muss um die benötigten Infos rauszusuchen wird das ganze auch nicht schneller, nein mann muss es irgendwie anders machen, aber bisher weis man nicht wie.
> 
> WEnn man gleiche zusammenfasst, wäre es schon einfacher, aber dann muss man für Versionen die komplett unterschiedlich gebaut werden wieder diese Datei wieder mit 2Dingern vollschreiben die eigentlich dasselbe machen, oderaber 2 Dateien für diese Versionen, wodurch das ganze nicht viel weniger wird, außer einigen Versiondumps lassen sich da wenige EBuilds zusammenfassen.
> 
> Aber davon mal abgesehen geht es hier doch darum Portage in eine andere Proggersprache zu bringen, und nicht den Portage-Baum anders zu gestalten.

 

Ich wuerde erst mal gar nicht versuchen irgendwas zusammen zu fassen, einfach nur die einzelnen Ebuilds eines Pakets in einer Datei nacheinander auflisten. Mehr nicht.

----------

## mv

 *hoschi wrote:*   

> Die Anzahl der Dateien in Portage liegt weiter ueber 100.000, Portage ist so lahm, weil es so viele Dateien gibt.

 

Falcsh. Dort bremsen höchstens die ca. 23000 Dateien in /usr/portage/metadata/cache - und die auch kaum, wie eix beim Lesen aller dieser Daten bei update-eix beweist. Der Rest ist schon Portage-spezifisch: Die Dateien in /var/db/pkg (statt einer vernünftigen Datenbank) sind eine deutlichere Bremse. Und ohne das lahme Python sondern in einer vernünftigen Compilersprache wäre Portage schon um einige Faktoren schneller (ich schätze so 3-4 mal), selbst bei den selben Algorithmen und Daten.

----------

