# ist gentoo noch zeitgemäß ?

## oliver2104

Hallo,

ich benutze gentoo schon seit ca. 15 Jahren und hab es lieben gelernt.

Gute Dokumentation, sehr gut für persönliche Bedürfnisse zu konfigurieren und

wirklich ausgezeichnete Unterstützung durch das deutsche Forum.

Aber langsam beginne ich an der Sinnhaftigkeit von gentoo zu zweifeln.

Das Prinzip ist ja die zentrale Bereitstellung von Source-Code,

die lauffähigen Programme müssen dann dezentral von jedem Benutzer selbst kompiliert werden.

Mein letztes Update hat mich nachdenklich gemacht.

Das hat sehr lang gedauert. Insbesonders die qtweb* Libraries

Selbst ein simples Firefox-Update braucht bei mir knapp 1 Stunde.

Der PC läuft natürlich nicht von allein, sondern verbraucht Strom.

Wenn zb. 1000 Gentoo User ihren Firefox updaten,

muß der Firefox 1000 mal kompiliert werden.

Das ist nicht gerade ressourcenschonend.

Welche Meinung habt Ihr dazu ?

----------

## haegar87

Hallo,

meiner Meinung nach ein notwendiges Übel. Habe dazu gerade ein passendes Beispiel aus meinem persönlichen Umfeld.

Habe mir Mitte des Jahres einen neuen Drucker gegönnt. Treiberinstallation war mit gentoo relativ problemlos (obwohl seltsamerweise alle Druckertreiber anscheinend nur in 32bit vorliegen).

Ein paar libs zusätzlich als 32bit Variante und schon lief alles.

Aufgrund dieser guten "Praxiserfahrungen" hat sich ein Bekannter ebenfalls besagten Drucker gekauft und versucht den zur Mitarbeit zu bewegen.

Da er allerdings eine der Binärdistributionen verwendet (für die es den Treiber direkt vom Distributor gibt) hätte er die komplette (!) 32bit Umgebung (mehrere hundert libs) installieren müssen.

Sein System wäre mit allen erdenklichen 32bit Libs vollgestopft worden. 

Ergebnis: Drucker wird über einen Raspi zusätzlich angesprochen, damit sein System nicht zu zugemüllt wird   :Rolling Eyes: 

Fazit: Ich möchte die Flexibilität von selbst gebauten (und teilweise selbst verwalteten Abhängigkeiten) nicht missen und nehme die Kompilierzeit (und eventuelle Fehlersuche) gerne in Kauf.

EDIT:

Man muss auch bedenken, dass gerade die "Monsterpakete" Firefox, (qt/gtk)webengine nicht die Regel, sondern eher die Ausnahme sind. Und für die "Unwilligen" gibts zumindest bei Firefox ja auch ein bin-Paket.

----------

## misterjack

 *oliver2104 wrote:*   

> Selbst ein simples Firefox-Update braucht bei mir knapp 1 Stunde.

 

Vor 5,10,15 Jahren hat das alles noch länger gedauert. Libreoffice 24h oder mehr. Damals hat man sich aber um die Umwelt noch nicht so wirklich Gedanken gemacht. Mein Tipp: Arch. Da haste Rolling Release aka Gentoo und auch 'n recht aktuelles System, ohne unnötig CO2 in die Athmosphäre zu pusten. Läuft testweise auf meinen Laptop, bisher ohne Probs.

 *haegar87 wrote:*   

> EDIT:
> 
> Man muss auch bedenken, dass gerade die "Monsterpakete" Firefox, (qt/gtk)webengine nicht die Regel, sondern eher die Ausnahme sind. Und für die "Unwilligen" gibts zumindest bei Firefox ja auch ein bin-Paket.

 

Ausnahme? Mindestens 1-3 Updates dieser pro Monat ist eher ziemliche regelmäßig.

----------

## LuxJux

Egal ob gentoo oder bin 

Es kommt darauf an, wie der PC benutzt wird.

Geht der Stromverbrauch in die Hoehe, weil gentoo compiled wird oder weil gleich Videos gerendert werden ist das

Jacke wie Hose.

Just my2centLast edited by LuxJux on Sun Nov 03, 2019 7:47 pm; edited 1 time in total

----------

## mike155

 *oliver2104 wrote:*   

> Das hat sehr lang gedauert. Insbesonders die qtweb* Libraries

 

Ja, die qtweb* Pakete brauchen zu lange. 

Brauchst Du sie überhaupt? Oder werden sie nur installiert, weil sie von anderen Paketen reingezogen werden? Falls das Letztere der Fall sein sollte, gibt es eine einfache Lösung: Abhängigkeiten anschauen, 1 oder 2 Use Flags ändern - und schon wird qtweb* wird nicht mehr reingezogen. Ein befreiendes "emerge --depclean" löscht sie dann.

So habe ich dieses Ärgernis beseitigt. Nie wieder qtwebengine!  :Smile: Last edited by mike155 on Sun Nov 03, 2019 8:11 pm; edited 1 time in total

----------

## LuxJux

Lesenswert

Mesa meckert. Wegen der nvidia.  Edit: Hilfe hat nicht geholfen 

( KDE hatte bei der Erstinstallation einen Bug. Untermenus konnten nicht angeklickt werden. ) 

Werde berichten boing

boinc darf bei mir nur mit 15 %

----------

## LuxJux

.

----------

## ChrisJumper

Hi oliver2104,

für mich sind verschiedene Punkte entscheident. Zum einen ist man sich bei Binärpaketen nie sicher ob das Ergebnis auch dem Entspricht, was der Sourcecode verspricht. Bei Gentoo ist das zwar auch nicht so aber es kommt dem schon sehr nahe. Auch das Recht darauf zu verstehen wie Software funktioniert.

Wer bedenken hat nutzt die alternativen oder baut sich seine Pakete Zentral und verteilt sie auf X Systeme. Das könnte noch ein wenig komfortabeler gestaltet werden.

Der Vorteil liegt aber auch auf der Hand. Du kannst einfach den Source Code Patchen, wenn du Probleme oder Fragen hast, es selber kompilieren und alles ist gut. Eben weil alles so transparent ist. Wegen der Klimafrage: Das lässt sich auch einfach lösen: Nimm Strom aus erneuerbaren Energien. Ist zwar teurere aber dann wieder ok. Wichtig ist das du deine Systeme schlank hällst und darüber nachdenkst was du mit der Energie und Zeit anfängst und da sind wir dann bei einem Punkt der sowohl der Datenhygiene als auch dem Sourcecode zu gute kommt, wie ich finde.

Daher war und ist Gentoo noch nie so aktuell und wichtig gewesen wie jetzt.

Es geht aber darum auch alle möglichen Vorteile bereit zu stellen.

Viele Grüße

Chris

----------

## forrestfunk81

 *mike155 wrote:*   

>  *oliver2104 wrote:*   Das hat sehr lang gedauert. Insbesonders die qtweb* Libraries 
> 
> Ja, die qtweb* Pakete brauchen zu lange. 
> 
> Brauchst Du sie überhaupt? Oder werden sie nur installiert, weil sie von anderen Paketen reingezogen werden? Falls das Letztere der Fall sein sollte, gibt es eine einfache Lösung: Abhängigkeiten anschauen, 1 oder 2 Use Flags ändern - und schon wird qtweb* wird nicht mehr reingezogen. Ein befreiendes "emerge --depclean" löscht sie dann.
> ...

 

qtweb* hatte ich mir auch schon mal entledigt. Aber irgendwie rutscht es immer wieder rein. Aktuell zieht die stable Version von nextcloud-client-2.5.2 die qtwebengine wieder als Abhängigkeit rein. Man kann es nicht per USE Flag abschalten und es erschließt sich weder aus den Release Notes, noch aus der Benutzung für was diese Dependency benötigt wird. Vielleicht muss ich Nextcloud doch endlich mal ersetzen.

----------

## mike155

 *forrestfunk81 wrote:*   

> qtweb* hatte ich mir auch schon mal entledigt. Aber irgendwie rutscht es immer wieder rein. Aktuell zieht die stable Version von nextcloud-client-2.5.2 die qtwebengine wieder als Abhängigkeit rein. Man kann es nicht per USE Flag abschalten und es erschließt sich weder aus den Release Notes, noch aus der Benutzung für was diese Dependency benötigt wird. Vielleicht muss ich Nextcloud doch endlich mal ersetzen.

 

Ersetzen ist das richtige Vorgehen! Aber nicht nextcloud-client, sondern qtwebengine!

Wenn es so ist, dass qtwebengine von nextcloud-client gar nicht gebraucht wird, dann könntest Du 'dev-qt/qtwebengine-<Versionsnummer>' hinzufügen zu  

```
/etc/portage/profile/package.provided
```

Lösche qtwebengine danach. Vorher könntest Du mit 'quickpkg' noch ein Binär-Paket von qtwebengine erstellen - für den Fall, dass Du es doch noch brauchst. Installiere nextcloud-client-2.5.2 erneut. Entweder gibt es dann einen Fehler, weil nextcloud-client qtwebengine doch braucht. Oder aber alles läuft prima und Du bist qtwebengine los. In diesem Fall könntest Du noch einen Bug eröffnen und den nextcloud-client ebuild-Maintainer bitten, die Dependency zu qtwebengine zu entfernen.

Ich habe den package.provided-Trick schon ein paar Mal erfolgreich angewendet und bin so einige störende Pakete losgeworden.   :Smile:   Die ebuild-Maintainer definieren manchmal mehr Abhängigkeiten, als notwendig sind.

----------

## kurisu

Nach über 10 Jahren Gentoo möchte ich es nicht mehr missen. Ja, die Kompilierzeiten sind mit Blick auf Chromium oder QtWebEngine in letzter Zeit rapide gestiegen. Aber das braucht man ja auch nicht unbedingt, wie bereits andere dargelegt haben. Ich fahre auch sehr gut ohne. Zudem hat das auch nicht Gentoo verschuldet. Ferner hat früher so einiges noch sehr viel länger gedauert. Unterm Strich bietet mir Gentoo hervorragende Flexibilität, Kompatibilität und vor allem Kontrolle, die ich woanders kaum vorzufinden vermag. Ich wäre beinahe geneigt zu sagen, Gentoo ist zeitgemäßer denn je. Wenn auch nur für Freaks wie uns :-)

----------

## l3u

 *kurisu wrote:*   

> Ferner hat früher so einiges noch sehr viel länger gedauert.

 

Man denke nur an die alten monolithischen kdelibs.

Trotzdem ist mir nicht ganz klar, wie ein HTML-Renderer so ein extrem dicker Brocken Quellcode sein kann. Ich meine, KHTML hat damals als erster den Acid2-Test bestanden, und war gefühlt 1/10.000 so groß wie QtWebEngine. Gut. Das ist eine andere Fragestellung.

Für mich persönlich muss ich sagen, dass ich eher so eine Hassliebe zu Gentoo habe ;-) Man muss es schon wollen. Aber die volle Kontrolle und Flexibilität ist super. Ich setze Gentoo auch auf Produktivsystemen (bei mir in der Praxis) ein, weil ich mich super damit auskenne und alles läuft. Fühlt sich zwar immer so ein bisschen an wie ein Tanz auf dem Vulkan, aber es ist noch nie was schiefgegangen (was ich nicht in den Griff bekommen hätte).

Und das Bauen aus den Quelltexten hat definitv Vorteile. Beispielsweise war eines der Projekte, die ich nebenher entwickle, von einem Qt-Bug betroffen. Also hab ich einfach das qtwidgets-ebuild in mein lokales Overlay kopiert, den Patch aus dem Qt-Bugtracker reingeschrieben und das Paket neu gebaut. Bug weg. Ohne warten auf das Hinzufügen/Stabilisieren neuer Versionen. Auf anderen Distributionen geht das nicht so locker von der Hand.

----------

## Max Steel

 *l3u wrote:*   

> Und das Bauen aus den Quelltexten hat definitv Vorteile. Beispielsweise war eines der Projekte, die ich nebenher entwickle, von einem Qt-Bug betroffen. Also hab ich einfach das qtwidgets-ebuild in mein lokales Overlay kopiert, den Patch aus dem Qt-Bugtracker reingeschrieben und das Paket neu gebaut. Bug weg. Ohne warten auf das Hinzufügen/Stabilisieren neuer Versionen. Auf anderen Distributionen geht das nicht so locker von der Hand.

 

Und heutzutage lässt sich über /etc/portage/patches/ sehr viel leichter ein Patch für eine bestimmte Version einfügen ohne irgendwelche Ebuilds vorher kopieren zu müssen...

Ist zumidnest ein weiterer Vorteil.

----------

## l3u

 *Max Steel wrote:*   

> Und heutzutage lässt sich über /etc/portage/patches/ sehr viel leichter ein Patch für eine bestimmte Version einfügen ohne irgendwelche Ebuilds vorher kopieren zu müssen...

 

Was diese jungen Leute mittlerweile nicht alles machen :-O Ich sollte mal wieder paar Wikis oder sowas lesen … zu meiner Zeit gab's sowas noch nicht …

----------

## misterjack

 *kurisu wrote:*   

> Ferner hat früher so einiges noch sehr viel länger gedauert.

 

Ich weiß nicht, der Trend kehrt sich wieder um. Aktuell hat mein letztes Update knapp 10 Stunden gedauert – mir echt zu lange – und das ganze mit NVME-SSD, 32 GB Ram und einer i7-4790K CPU @ 4.00GHz. Ich überlege ernsthaft den Wechsel auf Arch, da wäre dieses Update 10 Minuten in durch gewesen. Ach ja: 3h und 10min für qtwebengine. Ich nutze aktiv kmail, ist davon abhängig.

 *Quote:*   

> 
> 
>  Mon Nov  4 04:16:25 2019 >>> dev-libs/ell-0.26
> 
>      Mon Nov  4 04:16:35 2019 >>> app-crypt/openpgp-keys-gentoo-release-20191030
> ...

 

----------

## mike155

 *Misterjack wrote:*   

> Ach ja: 3h und 10min für qtwebengine. Ich nutze aktiv kmail, ist davon abhängig. 

 

qtwqebengine ist wirklich eine Plage! Ich kann nur jedem empfehlen, es NICHT zu installieren - selbst wenn man dafür den Mail-Reader wechseln muss.  :Smile: 

Andererseits scheint Du ja freiwillig unstable gewählt zu haben. Dann ist es kein Wunder, dass Du dauernd Updates "reingedrückt" bekommst  :Smile: 

----------

## Josef.95

 *misterjack wrote:*   

> NVME-SSD, 32 GB Ram und einer i7-4790K CPU @ 4.00GHz
> 
> 3h und 10min für qtwebengine

 

Mit der Hardware sollte das bauen deutlich schneller gehen -- vermutlich hast du vergessen USE=jumbo-build zu enablen.

https://code.qt.io/cgit/qt/qtwebengine.git/commit/?id=188f1a64d27dd88950c212484e03dc23b817e1c3

Aber ja, chromium ist ein Monster geworden -- schaut bei webkit-gtk aber vermutlich kaum anders aus :-/

----------

## kurisu

 *l3u wrote:*   

> Ich setze Gentoo auch auf Produktivsystemen (bei mir in der Praxis) ein, weil ich mich super damit auskenne und alles läuft. Fühlt sich zwar immer so ein bisschen an wie ein Tanz auf dem Vulkan, aber es ist noch nie was schiefgegangen (was ich nicht in den Griff bekommen hätte).

 

Kann ich voll bestätigen. Rückblickend auf die letzten Jahre kann ich mich an nichts erinnern, das meine Systeme auch nur im Ansatz zerschossen hätte. Stable wohlgemerkt. Falls es beim Experimentieren dennoch irgendwo hakt, weiß ich ganz genau wo ich hinschauen muss. Es mag krude anmuten, aber für mich  ist Gentoo sehr viel wartungsfreundlicher als Arch oder auch Debian.Last edited by kurisu on Fri Nov 08, 2019 1:49 am; edited 1 time in total

----------

## kurisu

 *Josef.95 wrote:*   

> Aber ja, chromium ist ein Monster geworden -- schaut bei webkit-gtk aber vermutlich kaum anders aus :-/

 

Nicht ganz. WebKitGTK müsste in deutlich weniger als der Hälfte der Zeit, die für QtWebEngine respektive Chromium nötig ist, gebaut werden können.

----------

## LuxJux

Und gcc darf sich mit einreihen

Und Open-RC (OpenRC manages the services, startup and shutdown of a host)

----------

## franzf

 *LuxJux wrote:*   

> Und gcc darf sich mit einreihen
> 
> Und Open-RC (OpenRC manages the services, startup and shutdown of a host)

 

openrc?!? 

```
genlop -i openrc

 * sys-apps/openrc

   Total builds: 75

   Global build time: 50 minutes and 18 seconds.

   Average merge time: 40 seconds.

   Info about currently installed ebuild:

   * sys-apps/openrc-0.41.2

   Install date: Sat Sep  7 14:17:59 2019

   USE=""

   CFLAGS="-march=sandybridge -mno-aes -O2 -pipe -ggdb"   CXXFLAGS="-march=sandybridge -mno-aes -O2 -pipe -ggdb"   LDFLAGS="-Wl,-O1 -Wl,--as-needed"
```

75 mal Bauen hat insgesamt 50 Minuten gedauert. Auf nem ollen Laptop mit 4GB und 2 Kern i3. Das System ist schon relativ ziemlich ganz schön alt. Noch keine Neuinstallation seit Erstinstallation.

Gab in der Zeit mehr qtcore builds als openrc...

----------

## Erdie

Ich finde die Frage etwas kurios. Vor knapp 20 Jahren, als die Rechner noch Steinzeit waren, hat man fürs Kompilieren ewig warten müssen. Damals hätte man uns alle für verrückt halten müssen. Seit dem arbeitet die Zeit für uns und es geht zunehmend schneller, so dass die Wartezeit kaum noch eine Rolle spielt. Über die Vorteile der Flexibilität braucht man ja nicht zu reden.

Ich habe noch einen alten AMD Bulldozer und die Kompilierzeiten sind nur selten unangenehm lang. Ich will nicht wissen wir das auf einem modernen 16 Kern Ryzen flutscht. Wen interessieren da noch Kompilierzeiten?

----------

## SkaaliaN

 *Erdie wrote:*   

> Ich finde die Frage etwas kurios. Vor knapp 20 Jahren, als die Rechner noch Steinzeit waren, hat man fürs Kompilieren ewig warten müssen. Damals hätte man uns alle für verrückt halten müssen. Seit dem arbeitet die Zeit für uns und es geht zunehmend schneller, so dass die Wartezeit kaum noch eine Rolle spielt. Über die Vorteile der Flexibilität braucht man ja nicht zu reden.
> 
> Ich habe noch einen alten AMD Bulldozer und die Kompilierzeiten sind nur selten unangenehm lang. Ich will nicht wissen wir das auf einem modernen 16 Kern Ryzen flutscht. Wen interessieren da noch Kompilierzeiten?

 

Da ich Abends an meinem PC sowieso nebenbei arbeite, lasse ich meine Compiliervorgänge einfach nebenbei laufen. In der Regel muss ich den Rechner deswegen nicht extra eingeschaltet lassen. Ich nutze einen Ryzen7 1800X.

----------

## l3u

 *mike155 wrote:*   

> qtwqebengine ist wirklich eine Plage! Ich kann nur jedem empfehlen, es NICHT zu installieren - selbst wenn man dafür den Mail-Reader wechseln muss. :)

 

Ich will aber KMail und Falkon haben! Ansonsten unterschreib ich das.

Aber von wegen Kompilierzeiten: Ich krieg sogar auf meinem Raspberry Pi 1 und meinem Alix 3D2 mit einem AMD-Geode-Prozessor mit 500 MHz und 256 MB RAM Gentoo aktuell gehalten. genau wie auf meinem Eee PC und einem 14 Jahre alten Dell-Notebook mit dem ersten Core 2 Duo drin. Zwar mit Distcc-Unterstützung, aber eben doch. Also es geht schon. Und die beiden Steinzeit-Notebooks haben beide die allseits beliebte QtWebEngine drauf.

----------

## Tyrus

Maschine ist bei mir:

x86_64 Intel(R) Core(TM) i3-6100 CPU @ 3.70GHz GenuineIntel GNU/Linux

8GB Arbeitsspeicher

Länger brauchen:

 *Quote:*   

> 
> 
>  * dev-qt/qtwebengine
> 
>    Total builds: 45
> ...

 

So schrecklich find ich es nicht. Es ist natürlich sehr nervig, wenn der Bau von qtwebengine wegen Fehler scheitert und man das dann wiederholt nicht hinbekommt ... 

Wenn man es schneller haben will, hilft es btw die grafische Oberfläche komplett zu beenden und den emerge-Lauf grade bei qtwebengine dann einfach in der reinen Textkonsole, meinetwegen über Nacht, laufen zu lassen.

----------

## mike155

Danke für die Liste, Tyrus! Das ist sehr hilfreich!

Bei GCC, LLVM und clang bin ich gerne bereit, einige Zeit zu warten. Das sind tolle Programme, die sehr viel leisten, in die sehr viel Entwicklungsarbeit geflossen ist, und bei denen die Entwickler auch immer wieder bemüht sind, den Code zu optimieren.

Aber qtwebengine... Das ist eine Library, die ein bisschen HTML rendern soll. Warum ist das Ding so groß? Ich vermute unendlichen Code Bloat - in jeder Hinsicht. Vermutlich wird da Funktion um Funktion hinzugeklatscht und das Ding wächst einfach unkontrolliert immer weiter, wie ein Krebsgeschwür. Es kann doch nicht wahr sein, dass das Kompilieren dieser Library länger dauert, als der gesamte Rest von Qt und KDE! Es macht mich wütend, dass dieses Paket standardmäßig reingezogen wird und so viele Gentoo-Anwender frustriert.

----------

## Tyrus

Es gibt drei Gründe warum ich qtwebengine - leider - brauche ... 

 app-text/calibre

 app-text/sigil

 kde-apps/kmail

Das diese Bibliothek total überfrachtet ist, denke ich auch. Würde auch gerne drauf verzichten, aber diese Programme möchte ich weiter nutzen. Bleibt also da keine Wahl.

Edit:

Vielleicht sollte ich dazu sagen, das sowohl calibre (ab Version 4) wie auch sigil (ab Version 0.9.16) qtwebengine nutzen. Vorher gings ohne. Es werden also anscheinend mehr Programme die auf diese Bibliothek umstellen. Leider ...

----------

## l3u

Wir driften etwas ab, aber qtwebengine ist echt pervers. Ich meine, KHTML rendert auch HTML. Gut, wenn man mal den Konqueror installiert, und KHTML einstellt, dann merkt man, dass das nicht mehr den heutigen Anforderungen entspricht. Aber es rendert HTML. Die KHTML-Quelltexte sind laut cloc gut 346.000 Zeilen lang. Ein ganzer Haufen. Aber bei der qtwebengine kommt cloc auf knapp 18,8 Millionen(!!!), das ist 54 Mal so viel!!! Was um alles in der Welt ist in dieser Bibliothek?!

----------

## SkaaliaN

 *Quote:*   

> genlop -i qtwebengine
> 
>  * dev-qt/qtwebengine
> 
>    Total builds: 3
> ...

 

Finde ich jetzt nicht extrem lange.

----------

## mike155

Ich frage mich, ob man qtwebengine kleiner und schneller bekommt, wenn man ein paar Build-Optionen deaktiviert? 'WebRTC', 'proprietary codecs', 'geolocation support' und den 'webchannel support' bräuchte man wohl nicht, wenn man qtwebengine für kmail und Calibre verwendet?

----------

## franzf

Für simples HTML braucht es nichtmal KHTML, da reicht der RichText-Support von QTextEdit. Verwende ich ohne Probleme im Qt Assistant zum Anzeigen der Qt-Dokumentation.

Ich denke dass WebEngine meistens auch genau dafür verwendet wird: Direkte Einbindung der Hilfeseiten in das Programm. Dafür ist es wirklich Overkill.

Es wird auch nach Deaktivierung einiger Features nicht spürbar schneller kompilieren. Und Code-Bloat ist es eher weniger.

QtWebEngine ist einfach ein in ein Qt-Interface gepackter Chromium. Ohne dem Web-Browser-Fenster. Alles in C++, was einfach länger zum Kompilieren braucht.

Ich hab wegengine/webkit seit Ewigkeiten deaktiviert. Musste deshalb auch schon auf Programme verzichten (Calibre, LuminanceHDR, Astroid Mail (webkit-gtk), andere an die ich mich grad nicht erinner).

Irgendwann wars mir egal. Gibt ja genügend Alternativen.

----------

## oliver2104

Danke für die vielen Reaktionen zu dem Thema.

Ich würd mich schon freuen wenn ich qtwebengine loswerden könnte.

Möchte dazu aber einen neuen Thread benutzen.

----------

## misterjack

 *Josef.95 wrote:*   

> Mit der Hardware sollte das bauen deutlich schneller gehen -- vermutlich hast du vergessen USE=jumbo-build zu enablen.

 

Danke für den Tipp. Irgendsoein Hinterzimmer (=local) useflag, welches man übersah, warum ist das nicht default an? Ich mein:

```
     Mon Nov  4 10:43:13 2019 >>> dev-qt/qtwebengine-5.13.2

       merge time: 3 hours, 3 minutes and 51 seconds.

     Fri Nov  8 17:30:54 2019 >>> dev-qt/qtwebengine-5.13.2

       merge time: 1 hour, 20 minutes and 59 seconds.
```

Hach ja:

```
     Thu Sep  1 04:27:15 2016 >>> dev-qt/qtwebengine-5.6.1

       merge time: 33 minutes and 50 seconds.
```

----------

## firefly

 *misterjack wrote:*   

>  *Josef.95 wrote:*   Mit der Hardware sollte das bauen deutlich schneller gehen -- vermutlich hast du vergessen USE=jumbo-build zu enablen. 
> 
> Danke für den Tipp. Irgendsoein Hinterzimmer (=local) useflag, welches man übersah, warum ist das nicht default an? 

 

Vermutlich da jumbobuild eventuell mehr Arbeitsspeicher benötig? Und dadurch eventuell auf Maschinen 2-4GB Ram sich nicht übersetzen lässt?

----------

## misterjack

 *firefly wrote:*   

> Vermutlich da jumbobuild eventuell mehr Arbeitsspeicher benötig? Und dadurch eventuell auf Maschinen 2-4GB Ram sich nicht übersetzen lässt?

 

Dafür gibt's CHECKREQS_MEMORY – siehe: https://devmanual.gentoo.org/eclass-reference/check-reqs.eclass/index.html

Damit kann man problemlos im ebuild sagen: weniger als 8 GB? dann -jumbo-build bitte. Ganz einfach  :Wink: 

----------

## l3u

Ich nehme an, die Devs wissen das? Wie wär's mit einem Bugreport (Feature Request)?

----------

## mike155

Unglücklicherweise wurde das "Feature" "Jumbo/Unity-Builds" bei Chromium gerade entfernt. Siehe: https://forums.gentoo.org/viewtopic-p-8388710.html#8388710

Dann wird's das bei qtwebengine auch nicht mehr lange geben...

----------

## Erdie

Um das hier mal aufzuwärmen: Ich baue die qt-webengine gerade auf einem i686 Centrino Duo - das läuft schon seit ein paar Stunden. Inzwischen habe ich den Ryzen 9 24 Kerner, der machen das in ein paar Minuten   :Very Happy: 

----------

## ManfredB

Hallo zusammen,

ich habe alle Meinungen in diesem Thread gelesen und bin überzeugt, daß vieles korrekt ist.

Ich bin auch schon sehr lange mit gentoo beschäftigt, allerdings wurde mir immer empfohlen,

stable zu nutzen und nicht unstable.

Eben habe ich gentoo-stable komplett neu installiert dank binpkgs, die bei anderen Installationen zuvor erstellt worden sind.

Das hat nur wenig Zeit benötigt, etwas weniger als 2 Stunden.

Außerdem habe ich Empfehlungen in diesem Forum erhalten:

zB auf MAKEOPTS zu verzichten und den Computer entscheiden zu lassen, wie er seine Potenzen einsetzt.

32 GB RAM stehen mir zur Verfügung.

So schnell, wie ich inzwischen eine komplette NeuInstallation von gentoo-stable hinbekomme (diesmal ohne binpkgs),

habe ich in der Vergangenheit noch nie erlebt. Es geht wirklich rasant.

Übrigens: qtwebengine kommt bei mir überhaupt nicht vor. Grund:

Ich installiere schon seit Jahren nur die Pakete, die qtwebengine nicht benötigen.

Hier einmal meine Installations-Reihenfolge:

dev-vcs/git sys-kernel/linux-firmware sys-kernel/gentoo-sources/gentoo-kernel-bin (je nach Lust) sys-boot/grub

emerge -avuDU @world - seit ich stage3-amd64-desktop-systemd-20220320T170531Z.tar.xz nutze,

ist das Basis-Update deutlich geringer.

app-misc/mc eix gentoolkit genfstab

kde-plasma/plasma-meta kdeadmin-meta kdegraphics-meta kdemultimedia-meta kdeutils-meta kdialog kmahjongg krusader kshisen kwrite gparted gutenprint inxi xsane alsa-tools alsa-utils firefox-bin phonon-gstreamer thunderbird-bin

libreoffice-bin libreottice-l10n

Wie gesagt, bei mir kommt qtwebengine nicht vor, worüber ich sehr froh bin.

Warum ich bei gentoo bleibe? Weil ich immer mehr dazugelernt habe dank dieses Forums und der WIKIs.

Ich wünsche allen weiterhin viel Freude an gentoo.

Gruß

Manfred

----------

## arfe

 *ManfredB wrote:*   

> Ich bin auch schon sehr lange mit gentoo beschäftigt, allerdings wurde mir immer empfohlen,
> 
> stable zu nutzen und nicht unstable.
> 
> 

 

Laut Forum bist Du hier seit 2007 angemeldet. Das weiß Du also erst nach 15 Jahren?

 *Quote:*   

> Eben habe ich gentoo-stable komplett neu installiert dank binpkgs, die bei anderen Installationen zuvor erstellt worden sind.
> 
> Das hat nur wenig Zeit benötigt, etwas weniger als 2 Stunden.
> 
> 

 

Diese Erkenntnis willst Du uns mitteilen? Ich glaube die Meisten werden wissen, dass Binary-Distributionen schneller installiert sind als Gentoo oder von Scratch.

 *Quote:*   

> Außerdem habe ich Empfehlungen in diesem Forum erhalten:
> 
> zB auf MAKEOPTS zu verzichten und den Computer entscheiden zu lassen, wie er seine Potenzen einsetzt.
> 
> 

 

Steht in Gentoo Wikis und auch im Handbook von Gentoo. Hättest Du nur Mal lesen müssen.

 *Quote:*   

> 32 GB RAM stehen mir zur Verfügung.
> 
> So schnell, wie ich inzwischen eine komplette NeuInstallation von gentoo-stable hinbekomme (diesmal ohne binpkgs),
> 
> habe ich in der Vergangenheit noch nie erlebt. Es geht wirklich rasant.
> ...

 

Ist klar. Wenn Deine vorherige Hardware weniger Kerne (CPU) und RAM hatte, ist es jetzt durch Deine neue Hardware schneller geworden.

 *Quote:*   

> Übrigens: qtwebengine kommt bei mir überhaupt nicht vor. Grund:
> 
> Ich installiere schon seit Jahren nur die Pakete, die qtwebengine nicht benötigen.
> 
> 

 

Und was soll das zur Diskussion beitragen?

 *Quote:*   

> Warum ich bei gentoo bleibe? Weil ich immer mehr dazugelernt habe dank dieses Forums und der WIKIs.
> 
> 

 

Du solltest mehr lesen und verstehen, bevor Du fragst. Vor allem den Willen zeigen Probleme selber zu lösen, die eigentlich in der Dokumentation von Gentoo sehr leicht selber zu lösen sind.

----------

## pietinger

Moderator Note: Ich habe diesen Thread in das Diskussionsforum verschoben, da er bereits von Anfang an hier her gehört hätte. Der vorhergehende Post von arfe spricht ebenso für sich selbst. Kommentare dazu sind wie immer erwünscht.

----------

## Erdie

Ich möchte auf die ursprüngliche Frage aus aktuellem Anlass nochmal meinen Standpunkt darlegen:

"Ist Gentoo noch zeitgemäß" lautete die Frage. 

Wie einige aus meinen Posts wissen, installiere ich gerade ein x86 stable auf 15 Jahre alter Hardware und darüberhinaus hatte ich mir vor nicht all zu langer Zeit neue Hardware gegönnt. Bei kämpft also David gegen Goliath - Ein x86 Centrino Duo mit 2,5G Ram gegen eine Ryzen 9 5600X mit 12 bzw 24 Kernen.

Der Unterschied ist so extrem, dass ich aus dem Stand sage: "Gentoo wird immer zeitgemäßer", denn Größe und Umpfang der Pakete sind nicht in dem Maße gewachsen wie die Leistung der Hardware. Bei den Kompilerzeiten liegen Faktoren geschätzt von ca. 50 - 100 dazwischen. Ich frage mich machmal: "Wie habe ich das damals nur ausgehalten .."

Für mich ein Grund bei Gentoo zu bleiben auch wenn es manachmal mal knarzt. Aber das ist dann so gut wie immer meine Schuld  :Wink: 

Grüße

Erdie

----------

## Schattenschlag

Zitat:	

Außerdem habe ich Empfehlungen in diesem Forum erhalten:

zB auf MAKEOPTS zu verzichten und den Computer entscheiden zu lassen, wie er seine Potenzen einsetzt.

Steht in Gentoo Wikis und auch im Handbook von Gentoo. Hättest Du nur Mal lesen müssen.

https://wiki.gentoo.org/wiki/Handbook:AMD64/Installation/Stage#MAKEOPTS

Hmm also ich find da nix... wo steht das man auf makepots verzichten sollte !?

----------

## ChrisJumper

Wir waren auf der Höhe einer Zeit, wo Menschen noch Informationen verstanden verarbeiteten und in der Gruppe entsprechende Wunder vollbrachten. Aktuell ist es eher eine Artifizielle Intelligenz, oder eine Gruppe von Menschen die von einer AI angetrieben und unterstützt wird.

Ich denke dieser Peak bei Gentoo in den 2000er bis 2010er Jahren wird so nicht mehr erreicht, weil sich die Menschen verändert haben. Oder weil die Menschen durch die Nutzung dieser Dienstleistungen eben ihre Verhalten verändert haben.

Aber ich glaube auch das Gentoo immer Zeitgemäßer wird, eben weil es eine einmalige Chance ist, bestimmte Hardware noch auf individuelle Weise minimal from the Scretch selber logisch nachvollziehbar erstellen zu können, wie sie wahrscheinlich nie wieder in Zukunft erfolgt.

Ich hoffe wir leben noch lange genug um die Ebuilds und Hardware fort zu führen.

----------

## Erdie

@chrisjumper Ja, da stimme ich zu. Allerdings sehe ich in der Gesellschaft eine zunehmende Tendenz der Verblödung IMHO u. a. getrieben durch die Verwendung von mobile devices bzw. der Fortentwicklung der Technik, welche es möglich macht, dem user immer mehr Verantwortung (und Mündigkeit) abzunehmen. "Wir", also der Rest und eben auch Gentoo Nutzer, werden immer mehr zu Exoten. Ich sehe es z. B. an meinem Kindern. Aber das Gute ist, man wird uns trotzdem oder erst jecht weiter brauchen.

----------

