# Mein Abschied von Gentoo auf'm Desktop ... hallo Arch Linux

## misterjack

Mein MPD-Rechner, noch Gentoo Linux, braucht alleine für die Zusammenstellung der Updates 'ne Viertelstunde.

```
time emerge -pvquDN @world

Local copy of remote index is up-to-date and will be used.

[binary  rR   ] net-print/cups-filters-1.26.0  USE="dbus foomatic jpeg png postscript tiff zeroconf -ipp_autosetup -ldap -pclm -pdf -perl -static-libs -test" 

[binary     U ] dev-qt/designer-5.14.0 [5.13.2] USE="declarative -debug -test -webkit" 

[binary     U ] dev-qt/qtvirtualkeyboard-5.14.0 [5.13.2] USE="spell xcb -debug -handwriting -test" 

[binary  rR   ] kde-frameworks/kwidgetsaddons-5.65.0  USE="nls -debug -designer -doc -test" 

[binary  rR   ] kde-frameworks/kitemviews-5.65.0  USE="nls -debug -designer -doc -test" 

[binary   R   ] app-portage/gemato-14.3  USE="blake2 bzip2 gpg lzma -sha3 -test -tools" PYTHON_TARGETS="python2_7 python3_6 python3_7 python3_8* -pypy -pypy3 -python3_5" 

[binary     U ] dev-qt/qtquickcontrols2-5.14.0 [5.13.2] USE="widgets -debug -test" 

[binary     U ] dev-python/PyQt5-5.14.0 [5.13.2] USE="bluetooth dbus declarative gui network opengl printsupport ssl svg widgets -debug -designer -examples (-gles2) -help -location -multimedia -networkauth -positioning -sensors -serialport -sql -testlib -webchannel -webkit -websockets -x11extras -xmlpatterns" PYTHON_TARGETS="python2_7 python3_6 python3_7 python3_8* -python3_5" 

[binary     U ] net-p2p/qbittorrent-4.2.1 [4.2.0] USE="X dbus -debug -webui" 

[binary     U ] app-portage/portage-utils-0.83 [0.82] USE="nls openmp qmanifest qtegrity -libressl -static" 

[binary     U ] sys-apps/portage-2.3.84 [2.3.82] USE="(ipc) native-extensions rsync-verify xattr -build -doc -epydoc -gentoo-dev (-selinux)" PYTHON_TARGETS="python2_7 python3_6 python3_7 python3_8* -pypy -python3_5" 

[binary  rR   ] kde-frameworks/kirigami-5.65.0  USE="-debug -examples -test" 

[binary   R   ] app-portage/repoman-2.3.20  PYTHON_TARGETS="python2_7 python3_6 python3_7 python3_8* -python3_5" 

[binary  rR   ] kde-frameworks/kxmlgui-5.65.0  USE="-debug -designer -doc -test" 

[binary  rR   ] kde-frameworks/qqc2-desktop-style-5.65.0  USE="-debug -test" 

[binary     U ] app-text/texlive-core-2019-r5 [2019-r4] USE="X luajittex xetex -cjk -doc -source -tk" 

[binary  rR   ] kde-frameworks/kdeclarative-5.65.0  USE="-debug -doc" 

[binary     U ] kde-misc/kdirstat-3.2.0 [3.1.4] USE="-debug -handbook" 

[binary  rR   ] kde-frameworks/frameworkintegration-5.65.0  USE="X -appstream -debug -test" 

[binary  rR   ] kde-frameworks/plasma-5.65.0  USE="X wayland -debug -doc (-gles2) -test" 

[binary   R   ] media-gfx/graphviz-2.42.3  USE="X cairo gtk nls pdf postscript python qt5 svg -devil -doc -examples -gdk-pixbuf -gts -guile -java -lasi -perl -ruby -static-libs -tcl" PYTHON_SINGLE_TARGET="python3_7 -python2_7 -python3_5 -python3_6 -python3_8" PYTHON_TARGETS="python2_7 python3_6 python3_7 python3_8* -python3_5" 

[binary     U ] dev-qt/qtwebengine-5.14.0 [5.13.2] USE="alsa jumbo-build pulseaudio system-ffmpeg system-icu widgets -bindist -debug -designer -pax_kernel -test" 

[ebuild     U ] media-sound/mpd-0.21.18 [0.21.16-r1] USE="adplug alsa ao audiofile bzip2 cdio chromaprint cue curl dbus eventfd expat faad ffmpeg fifo flac fluidsynth gme icu id3tag inotify ipv6 jack lame libmpdclient libsamplerate libsoxr mad mikmod mms modplug mpg123 musepack network nfs openal opus pipe pulseaudio recorder sndfile sqlite systemd twolame udisks unicode upnp vorbis wavpack webdav wildmidi zeroconf zip zlib -debug -libav -oss -qobuz -samba (-selinux) -sid -signalfd -soundcloud -test -tidal" 

[binary  rR   ] kde-plasma/breeze-5.17.4  USE="X wayland -debug" 

[binary     U ] kde-plasma/plasma-integration-5.17.4-r1 [5.17.4] USE="-debug -test" 

[binary     U ] kde-plasma/kwin-5.17.4-r1 [5.17.4] USE="caps -debug (-gles2) -handbook -multimedia -test" 

[binary  rR   ] sci-visualization/gnuplot-5.2.7  USE="X cairo gd latex libcaca qt5 readline wxwidgets (-aqua) -bitmap -compat -doc -examples -ggi -libcerf -lua -regis (-svga)" 

[binary     U ] kde-plasma/plasma-workspace-5.17.4-r1 [5.17.4] USE="calendar geolocation qalculate semantic-desktop systemd -appstream -debug -gps -handbook -qrcode -test" 

[binary     U ] kde-plasma/plasma-desktop-5.17.4-r1 [5.17.4] USE="fontconfig semantic-desktop -debug -handbook -ibus -mouse -scim -test -touchpad" 

[binary     U ] kde-plasma/kdeplasma-addons-5.17.4-r1 [5.17.4] USE="share -debug -webengine"
```

real    16m29,548s

user    13m33,431s

sys     0m16,923s

kurze Eckdaten: i5-3570T, 8 GB Ram, SSD

–––

Mein Laptop dahingegen, für die Zusammenstellung der Updates:

```
:: Starte vollständige Systemaktualisierung...

Löse Abhängigkeiten auf...

Suche nach in Konflikt stehenden Paketen...

:: python-pyqt5 und pyqt5-common stehen miteinander in Konflikt. pyqt5-common entfernen? [j/N] j

Pakete (201) akonadi-19.12.0-3  apr-1.7.0-2  apr-util-1.6.1-6  archlinux-keyring-20191219-1  attica-5.65.0-2  baloo-5.65.0-2  bluez-5.52-2  bluez-libs-5.52-2  bluez-qt-5.65.0-2  breeze-icons-5.65.0-2  cmake-3.16.2-1  cups-2.3.1-1  cups-filters-1.26.0-1  darktable-2:3.0.0-1  device-mapper-2.02.186-4  dhcpcd-8.1.4-1

             expat-2.2.9-3  frameworkintegration-5.65.0-2  fuse-common-3.9.0-1  fuse3-3.9.0-1  git-2.24.1-4  glib2-2.62.4-1  grantlee-5.2.0-2  groff-1.22.4-3  grub-2:2.04-4  hexchat-2.14.3-1  hwinfo-21.67-1  imagemagick-7.0.9.10-1  intel-tbb-2020.0-1  kactivities-5.65.0-2  kactivities-stats-5.65.0-2

             karchive-5.65.0-2  kauth-5.65.0-2  kbookmarks-5.65.0-2  kcalendarcore-5.65.0-2  kcmutils-5.65.0-2  kcodecs-5.65.0-2  kcompletion-5.65.0-2  kconfig-5.65.0-2  kconfigwidgets-5.65.0-2  kcontacts-1:5.65.0-2  kcoreaddons-5.65.0-2  kcrash-5.65.0-2  kdbusaddons-5.65.0-2  kdeclarative-5.65.0-2  kded-5.65.0-2

             kdelibs4support-5.65.0-2  kdesu-5.65.0-2  kdnssd-5.65.0-2  kemoticons-5.65.0-2  kfilemetadata-5.65.0-2  kglobalaccel-5.65.0-2  kguiaddons-5.65.0-2  kholidays-1:5.65.0-2  ki18n-5.65.0-2  kiconthemes-5.65.0-2  kidletime-5.65.0-2  kinit-5.65.0-2  kio-5.65.0-2  kirigami2-5.65.0-2  kitemmodels-5.65.0-2

             kitemviews-5.65.0-2  kjobwidgets-5.65.0-2  kjs-5.65.0-2  kjsembed-5.65.0-2  knewstuff-5.65.0-2  knotifications-5.65.0-2  knotifyconfig-5.65.0-2  kpackage-5.65.0-2  kparts-5.65.0-2  kpeople-5.65.0-2  kpty-5.65.0-2  kross-5.65.0-2  krunner-5.65.0-2  kservice-5.65.0-2  ktexteditor-5.65.0-2

             ktextwidgets-5.65.0-2  kunitconversion-5.65.0-2  kwallet-5.65.0-2  kwayland-5.65.0-2  kwidgetsaddons-5.65.0-2  kwin-5.17.4-4  kwindowsystem-5.65.0-2  kxmlgui-5.65.0-2  kxmlrpcclient-5.65.0-2  libakonadi-19.12.0-3  libcloudproviders-0.3.0-4  libcups-2.3.1-1  libde265-1.0.4-1  libedit-20191211_3.1-1

             libevdev-1.8.0-2  libevent-2.1.11-4  libheif-1.6.1-1  libice-1.0.10-2  libmagick6-6.9.10.80-1  libmbim-1.20.4-1  libnm-1.22.2-1  libtirpc-1.2.5-1  libva-2.6.0-1  libvpx-1.8.2-1  libwacom-1.2-1  libx11-1.6.9-6  libxau-1.0.9-2  libxcomposite-0.4.5-2  libxdamage-1.1.5-2  libxdmcp-1.1.3-2  libxext-1.3.4-2

             libxfixes-5.0.3-3  libxfont2-2.0.4-2  libxi-1.7.10-2  libxinerama-1.1.4-2  libxrandr-1.5.2-2  libxrender-0.9.10-3  libxss-1.2.3-2  libxtst-1.2.3-3  libxv-1.0.11-3  libxxf86vm-1.1.4-3  linux-5.4.6.arch3-1  linux-firmware-20191220.6871bff-1  lvm2-2.02.186-4  md4c-0.4.2-1  mesa-19.3.1-1

             modemmanager-qt-5.65.0-2  nano-4.7-1  networkmanager-1.22.2-1  networkmanager-qt-5.65.0-2  nextcloud-client-2.6.2-1  nodejs-13.5.0-1  openmp-9.0.0-2  pcre2-10.34-3  perl-encode-locale-1.05-5  perl-file-listing-6.04-6  perl-html-parser-3.72-8  perl-html-tagset-3.20-8  perl-http-cookies-6.08-1

             perl-http-daemon-6.01-7  perl-http-date-6.05-1  perl-http-message-6.18-3  perl-http-negotiate-6.01-6  perl-io-html-1.001-5  perl-libwww-6.43-1  perl-lwp-mediatypes-6.02-6  perl-net-http-6.19-2  perl-uri-1.76-2  perl-www-robotrules-6.02-6  perl-xml-parser-2.45-1  php-7.4.1-1  plasma-framework-5.65.0-4

             plasma-integration-5.17.4-2  prison-5.65.0-2  purpose-5.65.0-2  pyqt5-common-5.13.2-3 [Entferne]  python-3.8.1-1  python-pyparsing-2.4.6-1  python-pyqt5-5.14.0-3  python-setuptools-1:42.0.2-1  qqc2-desktop-style-5.65.0-3  qt5-base-5.14.0-1  qt5-declarative-5.14.0-2  qt5-graphicaleffects-5.14.0-1

             qt5-imageformats-5.14.0-1  qt5-location-5.14.0-1  qt5-multimedia-5.14.0-1  qt5-networkauth-5.14.0-1  qt5-quickcontrols-5.14.0-1  qt5-quickcontrols2-5.14.0-1  qt5-script-5.14.0-1  qt5-sensors-5.14.0-1  qt5-serialport-5.14.0-1  qt5-speech-5.14.0-1  qt5-svg-5.14.0-1  qt5-tools-5.14.0-1

             qt5-wayland-5.14.0-3  qt5-webchannel-5.14.0-1  qt5-webengine-5.14.0-1  qt5-webkit-5.212.0alpha3-8  qt5-x11extras-5.14.0-1  qt5-xmlpatterns-5.14.0-1  qtkeychain-0.10.0-1  rhash-1.3.9-1  s-nail-14.9.15-3  solid-5.65.0-2  sonnet-5.65.0-2  stellarium-0.19.3-1  syndication-5.65.0-2

             syntax-highlighting-5.65.0-2  systemd-244.1-1  systemd-libs-244.1-1  systemd-sysvcompat-244.1-1  talloc-2.3.1-1  telegram-desktop-1.8.15-4  threadweaver-5.65.0-2  tigervnc-1.10.1-1  v4l-utils-1.18.0-1  vulkan-icd-loader-1.1.130-1  xorg-server-1.20.6-2  xorg-server-common-1.20.6-2

             xorg-server-xwayland-1.20.6-2  xorg-xdpyinfo-1.3.2-3  xorgproto-2019.2-2  xvidcore-1.3.6-1

Gesamtgröße des Downloads:            686,92 MiB

Gesamtgröße der installierten Pakete:  2242,62 MiB

Größendifferenz der Aktualisierung:    35,45 MiB

:: Installation fortsetzen? [J/n] n
```

real    0m3,677s

user    0m0,378s

sys     0m0,024s

kurze Eckdaten: i7-3520M, 8 GB Ram, SSD

Weniger als 4 Sekunden !!!!!!11111elfelfelf

---

Inklusive der Installation auf dem Laptop?

real    3m16,497s

user    1m13,128s

sys     0m24,288s

Was macht emerge bitteschön in der Viertelstunde? Da ist keine einzige Kompilation dabei – mir ist meine Lebenszeit einfach zu schade für so unzulänglichen Müll und ich werde in Konsequenz jetzt zu Arch wechseln, das hab ich 'nen guten Monat lang auf dem Laptop angetestet und mir gefällts. Wenn Gentoo bei den 4s angekommen ist, wäre ich vielleicht für einen Wechsel zurück zu haben. Ich hab da aber so meine Vermutungen ^^

---

Wer die Sektkorken knallen lassen hat, das ich jetzt weg bin, der hat sich zu früh gefreut  :Laughing:   :Laughing:   :Laughing:  Ich werde euch erhalten bleiben, im Serverbereich bleib ich bei Gentoo, da ist es bezahlte Arbeitszeit  :Wink: 

----------

## asturm

Gut für dich, soll jeder verwenden was er oder sie mag.

 *misterjack wrote:*   

> Was macht emerge bitteschön in der Viertelstunde?

 

Ganz offensichtlich wesentlich mehr als Arch, das ja überhaupt keine Build-Abhängigkeiten prüfen muss. Eine Viertelstunde hat es bei mir allerdings noch nie gedauert (um nicht zusagen das ist absonderlich lang), die Wartezeit ist bei mir ziemlich irrelevant. Zur Abwechslung vielleicht auf das unnötige -N verzichten, -D muss auch nicht immer sein.

----------

## misterjack

 *asturm wrote:*   

> Gut für dich, soll jeder verwenden was er oder sie mag.
> 
>  *misterjack wrote:*   Zur Abwechslung vielleicht auf das unnötige -N verzichten, -D muss auch nicht immer sein. 
> 
> Das werde ich nochmal testen, sobald wieder genügend Updates anstehen.

 

Dass Updates heutzutage stellenweise wieder über 10h dauern (wie hier gepostet: https://forums.gentoo.org/viewtopic-p-8386356.html#8386356) ist ebenso Ansporn zum Wechsel.

Ich bin jetzt seit 2004 Gentooanwender und ich muss mir auch eingestehen, in den letzten Jahren ist das Interesse verflogen, mehr Zeit in den Rechner zu investieren als nötig, mit dem Älterwerden haben sich meine Prioritäten verschoben. Jetzt muss ich mir nur noch 'n WE Zeit nehmen, um die Kisten auf Arch umzuziehen – kann dauern, weil hat keine Priorität ^^

----------

## mike155

Den Frust über "Desktop unter (Gentoo) Linux" kann ich nachvollziehen - den habe ich auch. Allerdings nicht wegen langer Emerge- oder Kompilier-Zeiten, sondern wegen der Instabilität, wegen der vielen Dinge die nicht gehen, wegen der fehlenden Anwender-Software, wegen der gelegentlichen Abstürze und vor allem wegen des Gefühls, dass es nicht besser, sondern eher schlimmer wird.

Andererseits sehe ich es als sehr großen Vorteil, dass man bei Gentoo Linux den Source Code hat und ggf. nachschauen kann was passiert und ggf. auch etwas ändern kann. Deshalb bleibe ich dann doch bei Gentoo Linux - und wechsle nicht zu macOS, obwohl der mac mini bereits auf dem Schreibtisch steht und ich ihn für alles verwende, was mit DTP zu tun hat.

Was die langen "Nachdenk-Zeiten" von Emerge angeht (16 Minuten): das ist wirklich außerordentlich lange. Bei mir dauert die von Dir genannte Emerge-Anweisung zwischen 20 und 60 Sekunden (je nach Rechner). Möglicherweise kannst Du die Anweisung bei Dir deutlich beschleunigen:

Hast Du Overlays installiert? Vielleicht ist eines von denen daran schuld?

Hast Du viele USE-Flags in make.conf definiert? Meines Erachtens sollten dort nur die wichtigsten USE-Flags definiert werden: die USE-Flags, die viele für Pakete gleichzeitig benötigt werden. Alle anderen USE-Flags sollte man auf einer per-Package Basis in package.use definieren. Insgesamt sollte man so wenig USE-Flags wie möglich verwenden. Je näher man an den Default-Werten bleibt, desto besser.

Ebenfalls Grund für lange "Nachdenk-Zeiten" von emerge kann eine suboptimale world-Datei (/var/lib/portage/world) sein. Auch hier kann man aufräumen und alle Pakete entfernen, die Teil von @system sind oder die bereits durch andere Pakete reingezogen werden. Möglicherweise stehen dort auch Pakete, die Du mal installiert hast, die Du aber gar nicht benutzt? Auch diese sollten entfernt werden.

Was lange Kompilier-Zeiten angeht: mit "--newuse" werden häufig bereits installierte Pakete neu übersetzt, die gar nicht übersetzt werden müssten. "--changed-use" ist fast immer ausreichend: 

```
emerge --update --deep --changed-use -av @world
```

Und selbst "--changed-use" übersetzt mehr Pakete als notwendig...

Häufiges Kompilieren und lange Kompilier-Zeiten sind nicht verwunderlich, wenn man auf "unstable/testing" geht. Dann bekommt man halt jedes kleine Update reingedrückt. Warum machen das so viele User? Ob man nun die neuste Version von sed, grep oder make hat - oder eine etwas ältere: das macht doch überhaupt keinen Unterschied! Meines Erachtens sollte auf man auf "stable" bleiben und sich dann über package.accept_keywords die "unstable/testing" Version von den paar Paketen holen, mit denen man wirklich arbeitet und bei denen es dann auch nicht stört, wenn sie häufiger mal aktualisiert werden. 

Was qtwebengine angeht: die lange Kompilier-Zeit dieses Pakets ist ärgerlich. Allerdings könn(t)en viele User ihre Konfiguration so anpassen, dass dieses Paket erst gar nicht installiert wird.

----------

## misterjack

 *mike155 wrote:*   

> Den Frust über "Desktop unter (Gentoo) Linux" kann ich nachvollziehen - den habe ich auch. Allerdings nicht wegen langer Emerge- oder Kompilier-Zeiten, sondern wegen der Instabilität, wegen der vielen Dinge die nicht gehen, wegen der fehlenden Anwender-Software, wegen der gelegentlichen Abstürze und vor allem wegen des Gefühls, dass es nicht besser, sondern eher schlimmer wird.

 

mmh, mein Gentoo ist sehr stabil – an den letzten Absturz kann ich mich nicht erinnern.

 *mike155 wrote:*   

> ndererseits sehe ich es als sehr großen Vorteil, dass man bei Gentoo Linux den Source Code hat und ggf. nachschauen kann was passiert und ggf. auch etwas ändern kann.

 

Kann man bei Arch auch: https://wiki.archlinux.org/index.php/Arch_Build_System – das mit dem MacOS hab ich mal gekonnt überlesen.  :Razz: 

 *mike155 wrote:*   

> Was die langen "Nachdenk-Zeiten" von Emerge angeht (16 Minuten): das ist wirklich außerordentlich lange. Bei mir dauert die von Dir genannte Emerge-Anweisung zwischen 20 und 60 Sekunden (je nach Rechner). Möglicherweise kannst Du die Anweisung bei Dir deutlich beschleunigen:
> 
> Hast Du Overlays installiert? Vielleicht ist eines von denen daran schuld?

 

Hab vor dem Rant die Hälfte der Overlays ausgemacht, da änderte sich nichts an den Zeiten.

 *mike155 wrote:*   

> Hast Du viele USE-Flags in make.conf definiert? Meines Erachtens sollten dort nur die wichtigsten USE-Flags definiert werden: die USE-Flags, die viele für Pakete gleichzeitig benötigt werden. Alle anderen USE-Flags sollte man auf einer per-Package Basis in package.use definieren. Insgesamt sollte man so wenig USE-Flags wie möglich verwenden. Je näher man an den Default-Werten bleibt, desto besser.

 

Globale hab ich der make.conf und in der package.use die lokalen. Wenn viele Useflags zu dermaßen Performanceeinbrüchen führt, ist das System Useflags Schrott. Btw, aus meiner make.conf – von Hand einzeln ausgewählt:

```
USE="aacplus amr amrenc ao archive audiofile avahi bash-completion cacert caps cdio css djvu dmx dri3 dssi \

    egl fat fbcon ffmpeg fluidsynth fontconfig fuse gdu geolocation gimp glamor gles gles2 gme gmp gnuplot \

    gphoto2 graphviz hddtemp hid icq id3tag idn imagemagick inotify iproute2 iptables jack \

    jbig jpeg2k jumbo-build kms ladish ladspa lame latex libass libcaca libsamplerate lm_sensors lv2 \

    lzma lzo matroska midi mmap modemmanager mtp musepack networkmanager nfs openal opencv openexr opus oscar plotutils \

    postscript projectm pulseaudio rar raw realtime samba sbsms scanner sdl-image sid sndfile soundtouch speex \

    suid symlink taglib theora thinkpad threads tremor twolame upnp upnp-av vaapi vamp vdpau vim-syntax vlc vlm \

    vnc vpx vst wavpack wayland webp wifi wireless wma wma-fixed wmf x265 xattr xinerama xmp xvmc zeroconf zip \

    -gstreamer -ldap -gtk -handbook -xscreensaver -telepathy"
```

(Disclaimer: Mein Desktop-PC dient ebenso als Binaryhost für den Medienrechner und für den Laptop zu seinen Gentoozeiten – falls das ein oder andere Flag irritiert bei einen Medienrechner)

 *mike155 wrote:*   

> Ebenfalls Grund für lange "Nachdenk-Zeiten" von emerge kann eine suboptimale world-Datei (/var/lib/portage/world) sein. Auch hier kann man aufräumen und alle Pakete entfernen, die Teil von @system sind oder die bereits durch andere Pakete reingezogen werden. Möglicherweise stehen dort auch Pakete, die Du mal installiert hast, die Du aber gar nicht benutzt? Auch diese sollten entfernt werden.

 

Ich verwende sauber aufgeräumte Portage-Sets, die /var/lib/portage/world ist leer.

 *mike155 wrote:*   

> Was lange Kompilier-Zeiten angeht: mit "--newuse" werden häufig bereits installierte Pakete neu übersetzt, die gar nicht übersetzt werden müssten. "--changed-use" ist fast immer ausreichend: 
> 
> ```
> emerge --update --deep --changed-use -av @world
> ```
> ...

 

Das teste ich noch aus, wieviel das ausmacht.

 *mike155 wrote:*   

> Häufiges Kompilieren und lange Kompilier-Zeiten sind nicht verwunderlich, wenn man auf "unstable/testing" geht. Dann bekommt man halt jedes kleine Update reingedrückt. Warum machen das so viele User? Ob man nun die neuste Version von sed, grep oder make hat - oder eine etwas ältere: das macht doch überhaupt keinen Unterschied! Meines Erachtens sollte auf man auf "stable" bleiben und sich dann über package.accept_keywords die "unstable/testing" Version von den paar Paketen holen, mit denen man wirklich arbeitet und bei denen es dann auch nicht stört, wenn sie häufiger mal aktualisiert werden. 

 

Stable ist mir zu alt, ich habe gern alles in aktuellen Versionen installiert. Bei Arch bekomme ich alles ebenso aktuell wie Gentoo Testing – in einem Bruchteil der Zeit.

 *mike155 wrote:*   

> Was qtwebengine angeht: die lange Kompilier-Zeit dieses Pakets ist ärgerlich. Allerdings könn(t)en viele User ihre Konfiguration so anpassen, dass dieses Paket erst gar nicht installiert wird.

 

Ich mag kontact & kmail doch so sehr, dass ich lieber die Distro wechsel  :Smile: 

----------

## asturm

 *misterjack wrote:*   

>  *mike155 wrote:*   ndererseits sehe ich es als sehr großen Vorteil, dass man bei Gentoo Linux den Source Code hat und ggf. nachschauen kann was passiert und ggf. auch etwas ändern kann. 
> 
> Kann man bei Arch auch: https://wiki.archlinux.org/index.php/Arch_Build_System

 

Das ist schon okay, aber nicht einmal ansatzweise vergleichbar.

----------

## l3u

Gentoo muss man wollen. Ich hab auch meine persönliche Hassliebe zu Gentoo, aber es ist dann eben doch das, was ich mir persönlich (als Hobby-Programmierer und -KDE-Dev) unter „Linux“ vorstelle. Aber man muss es wie gesagt wollen.

----------

## misterjack

 *l3u wrote:*   

> Gentoo muss man wollen.

 

Naja, nach 15 Jahren Gentoo darf man was neues wollen  :Smile: 

Einen wesentlichen Faktor an der Performance-Überlegenheit von Pacman ist die Wahl der richtigen Programmiersprache: C

Python ist hoffnungslos unterlegen, exemplarisch anhand Python 3: https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/python3-gcc.html

Dann sind seit 2006 Mehrkernprozessoren vorherschend im PC-Bereich & emerge -p rödelt im Jahr 2019 nachwievor lediglich auf einem Kern herum. Es könnten anstelle 16 Minuten wesentlich weniger sein, wenn emerge die 4 echten Kerne des i5-3570T effektiv nutzen würde.

----------

## franzf

 *misterjack wrote:*   

>  *l3u wrote:*   Gentoo muss man wollen. 
> 
> Naja, nach 15 Jahren Gentoo darf man was neues wollen 
> 
> Einen wesentlichen Faktor an der Performance-Überlegenheit von Pacman ist die Wahl der richtigen Programmiersprache: C

 

Hanoi... paludis war (ist, scheint sich aber irgendwie erledigt zu haben) in C++ geschrieben. Hatte ursprünglich einen guten Geschwindigkeitsvorteil, was devs und Anwender auf die Wahl der Programmiersprache geschoben haben.

Portage-devs haben dann an den Algorithmen geschraubt und der Vorteil war dahin.

Was dann gleich wieder wettgemacht wurde durch SubSlots und die ganzen netten auto-rebuilds uswusf. Geht wahrscheinlich in C auch nicht so viel flotter.

Und soweit ich mich erinner war das Auflösen der Abhängigkeiten nur bedingt threadable.

@topic:

Ich muss gestehen dass ich auch gerade auf Abwege gerate. Ein alter Laptop wurde wiederbelebt und da ich schon mit meiner 4GB-Kiste Probleme (Swappen, Überhitzung) habe wurde da flugs arch installiert.

Installation ähnlich Gentoo, etwas schneller. Pakete installieren ist aber so viel einfacher und schneller.

Ich werde das jetzt beobachten und wenns gut geht kommt (leider) Gentoo von meinem Laptop und wahrscheinlich auch vom Desktop meines Vaters runter.

Dann kann ich auch wieder mit webkit u.Ä. rumspielen, auch programmieren. Weil das hab ich alles deaktiviert wegen unmergebarkeit auf allen Rechnern hier...

Probleme mit Arch hatte ich aber auch schon. Z.B. Oopste der Kernel beim Suspend. pm_async=0 hat das aber behoben, seitdem ist Friede.  :Smile: 

----------

## Josef.95

Naja, mit den Subslot change rebuilds hast du dir aber auch ein Extrembeispiel rausgesucht, welches extrem viel Zeit zum berechnen braucht -- sowas kommt idR nur selten vor.

Auf dem alten Laptop mit 3,6 GHz (i7-3720QM) CPU geht das berechnen eines @world Updates hier idR deutlich schneller: 

```
time emerge -pvquDN @world

real    0m24,513s

user    0m24,209s

sys     0m0,294s
```

 (mit aktuell 1112 installierten Paketen)

Ich denke wenn misterjack nur wollte, dann könnte auch er sein Gentoo wieder flott bekommen :)

----------

## Tyrus

Also ich habe grade auch noch mal aktuell gemessen.

System ist

```

Linux luthien 5.4.6-gentoo-luthien #1 SMP Mon Dec 23 11:22:30 CET 2019 x86_64 Intel(R) Core(TM) i3-6100 CPU @ 3.70GHz GenuineIntel GNU/Linux

```

Ein emerge mit --newuse Option an liefert grade noch  app-office/libreoffice - den Rest, der wegen dem USE-Flag Maskierung für python 3.5 da reinkam, hab ich schon mitlaufen lassen ...  :Wink: 

```

[ebuild   R   ] app-office/libreoffice-6.2.8.2  USE="accessibility branding cups dbus gstreamer gtk java kde ldap mariadb odk pdfimport postgres -bluetooth (-coinmp) -debug -eds (-firebird) -googledrive -gtk2 -test" LIBREOFFICE_EXTENSIONS="nlpsolver scripting-beanshell scripting-javascript wiki-publisher" PYTHON_SINGLE_TARGET="python3_6 -python2_7 (-python3_7) (-python3_5%)" PYTHON_TARGETS="python2_7 python3_6 (-python3_7) (-python3_5%)" 

real    1m39,675s

user    1m37,585s

sys     0m0,823s

```

Das selbe nochmal und dann auch noch mit "--changed-deps" dauert auch nicht wesentlich länger:

```

[ebuild   R   ] app-office/libreoffice-6.2.8.2  USE="accessibility branding cups dbus gstreamer gtk java kde ldap mariadb odk pdfimport postgres -bluetooth (-coinmp) -debug -eds (-firebird) -googledrive -gtk2 -test" LIBREOFFICE_EXTENSIONS="nlpsolver scripting-beanshell scripting-javascript wiki-publisher" PYTHON_SINGLE_TARGET="python3_6 -python2_7 (-python3_7) (-python3_5%)" PYTHON_TARGETS="python2_7 python3_6 (-python3_7) (-python3_5%)" 

real    1m41,104s

user    1m40,595s

sys     0m0,461s

```

Ich hab relativ viel installiert mit aktuell 2289 Paketen.

Bei einem Update von KDE dauert der emerge dann auch schon mal etwas länger. Aber auf mehr als gefühlte 3-4 Minuten, wenn es wirklich lang braucht, komm ich eigentlich nie. Und emerge hat dann auch eben wirklich eine recht lange Liste die abgearbeitet werden soll als Ergebnis. Ich lasse mittlerweile meistens erst einen Lauf ohne --newuse und ohne --changed-deps drüber laufen. Der zweite Schritt ist dann, das auch noch zu machen und zu schauen, ob man das wirklich sofort machen will oder damit noch etwas wartet. Einzelne größere Pakete kann man auch einfach mal via '--exclude' aufschieben bis sie sowieso wieder fällig werden. Die kleineren Sachen stören mich nicht wirklich, wenn ich das nochmal neu bauen lasse. 

Häufiger finde ich grade deswegen kleine "Nicklichkeiten" wie jetzt erst wieder mit dev-python/urllib3. Das Ebuild dort hat bei den Abhängigkeiten dev-python/mock, nur wenn man USE-Flag "test" aktiviert. Der Durchlauf vorhin beim Rebuild hat aber ergeben, das dev-python/mock immer gebraucht wird zum bauen. Sonst bricht das ab mit Python-Fehler das Modul mock fehlt. Möglicherweise ist es (bei mir) vorher nicht aufgefallen, weil es von was anderem installiert wurde das ich nicht mehr benutze und dann über den depclean entfernt wurde.  Jedenfalls wäre das mal ein Beispiel, wo es sich (zumindest für mich) durchaus lohnt, gelegentlich auch diese oft nicht zwingenden Rebuilds zu machen die von '--newuse' und '--changed-deps' ausgelöst werden.

Edit:

Als Ergänzung - ich sehe eigentlich schon nach dem 'eix-sync' ob der emerge etwas länger braucht. Wenn das Ergebnis da schon viele Updates anzeigt dann rechnet auch der emerge eben mal statt 1-2 Minuten dann eben doppelt so lange.

----------

## misterjack

 *Josef.95 wrote:*   

> Ich denke wenn misterjack nur wollte, dann könnte auch er sein Gentoo wieder flott bekommen 

 

Haha, Witzbold. Wenn genau 0 Pakete zu updaten sind, hab ich auch nur:

```
time emerge -pvquDN @world

Local copy of remote index is up-to-date and will be used.

real    0m36,395s

user    0m30,019s

sys     0m1,316s

```

Das trifft auf den Post von Tyrus ebenso zu. Verarschen kann ich mich alleine  :Wink: 

----------

## Josef.95

 *misterjack wrote:*   

> Haha, Witzbold. Wenn genau 0 Pakete zu updaten sind, hab ich auch nur: [...]

 

Hehe, ja ok, du hast dir ein Beispiel mit Subslot-Changes herausgesucht, welches extrem viel Zeit zum berechnen braucht,

und ich mir eines das extrem wenig Zeit braucht  :P 

Nee im ernst - ich denke die Realität liegt idR meist irgendwo dazwischen. Auf dem Desktop-System hier mit meist ~1200 installierten Paketen braucht das berechnen eines @world Updates idR so bei 1 bis 2,5 Minuten -- damit kann ich gut leben.

Aber ja zugegeben, wenn sich Subslots ändern (zb bei boost, poppler, icu, xorg-server, oder hier eben qtcore),

dann kann das berechnen schon mal ein wenig länger dauern. Das kommt aber idR nur selten vor.

Und falls es beim @world auflösen mit Sublot changes mal Probleme gibt, und man da testen und nachjustieren muss, dann gibt es zum testen auch immer noch die emerge Option --ignore-built-slot-operator-deps Die sollte man aber am besten nur mit --pretend nutzen.

(Siehe dazu zb auch im https://wiki.gentoo.org/wiki/Project:Portage/FAQ#What_should_I_do_when_emerge_reports_a_lot_of_dependency_conflicts_involving_built_slot-operator_.28foo.2Fbar:X.2FY.3D.29_dependencies.3F ) - (das kann sehr viel Zeit sparen).

Aber hey, du bist schon groß, und musst es selbst wissen -- mir würden beim Arch-Linux zb die Useflags (mit denen man viele deps fein steuern kann) fehlen.

/Edit: Und eix würde mir auch fehlen (und vermutlich noch einiges mehr).

----------

## misterjack

Ich kann Leute nicht ernst nehmen, die hier die Angabe eines emerge mit 0 oder 1 Paketen präsentieren und dann etwas von 1-2 Minuten ohne genaue Messung daherlabern. Beim besten Willen nicht *plonk*

----------

## Max Steel

Ich hab folgendes:

```
$ time emerge -pvuDN -tv --with-bdeps=y --keep-going --quiet-build=y @world

[...]

Total: 786 packages (509 upgrades, 4 new, 7 in new slots, 266 reinstalls), Size of downloads: 3.461.779 KiB

Conflict: 4 blocks

[...]

real    4m46,790s

user    4m45,694s

sys     0m0,870s

```

Das ist mein Arbeitssystem dessen gestriger Updateversuch wegen fehlendem Platz in distfiles irgendwo abbrach.

Find ich okay für so eine Art Upgrade mit solchem Status.

Edit: Nach Fireflys Vorbild schreib ich auch noch meine EMERGE_DEFAULT_OPTS dazu und die enthaltenen Overlays (meist alles deaktiviert per package.mask)

- AlexandreFournier

- rion

- ssnb

- MSteel

- genpi64

----------

## firefly

Bei mir ist es folgendes:

 *Quote:*   

> $ time emerge -uDUvp --keep-going --with-bdeps=y @world
> 
> . done!
> 
> [package list]
> ...

 

Das ist auf einem i7-4790 mit 16 GB Ram

Und mit folgenden overlays

 qt

 kde

 gamerlay

 local portage

----------

## forrestfunk81

@firefly: Bei dir fehlt im Befehl noch ein --newuse im Vergleich zu misterjack

Ich kann so lange Laufzeiten aber auch nicht bestätigen:

```
time emerge -uNDUvp --keep-going --with-bdeps=y world

Total: 117 packages (6 upgrades, 1 downgrade, 4 new, 106 reinstalls), Size of downloads: 198.746 KiB

real    1m24,686s

user    1m23,765s

sys     0m0,705s
```

Auf einem i7-6500U mit 1064 installierten Paketen. Und sogar der Raspberry 4 schafft das bei 808 Paketen in 7 min. Beide mit zwei zusätzlichen Repos, wobei ebenfalls das meiste daraus maskiert wurde.

```
time emerge -uNDUvp --keep-going --with-bdeps=y world

Total: 20 packages (10 upgrades, 10 reinstalls, 4 binaries), Size of downloads: 45.740 KiB

real    7m8,717s

user    7m6,028s

sys     0m1,940s
```

Außerdem sind für mich weder die Zeiten dieser Kalkulation noch die Update Zeiten wichtig. Emerge anstoßen, Kaffee machen, Emerge Output prüfen, akzeptieren und wichtigere Dinge tun. Aber jeder hat so seinen eigenen Workflow  :Wink: 

----------

## firefly

 *forrestfunk81 wrote:*   

> @firefly: Bei dir fehlt im Befehl noch ein --newuse im Vergleich zu misterjack

 

Stimmt dafür aber --changed-use, was "besser" ist da es keine Pakete zum re-install selektiert welche ein neues useflag haben aber dieses nicht aktiv ist (was vermutlich dann im ergebnis nichts ändert)

Hmm mit --newuse ist das ganze sogar schneller (Seit dem letzten run wurden keine pakete installiert)

Obwohl mehr Pakete zum re-install selektiert wurden

 *Quote:*   

> $ emerge -uDUvpN --keep-going --with-bdeps=y @world
> 
> Total: 223 packages (80 upgrades, 1 in new slot, 142 reinstalls), Size of downloads: 670,253 KiB
> 
> real	1m48.086s
> ...

 

Könnte daran liegen das hier die caches schon warm sind mit den daten von der Festplatte.

Oder daran das --newuse weniger arbeit erzeugt als --changed-use

Es ist eine kombination aus beidem. Beim zweiten run ohne zusätzlich --newuse dauert es etwas länger als mit --newuse ist aber schneller als mein ursprünglicher run.

 *Quote:*   

> $ emerge -uDUvp --keep-going --with-bdeps=y @world
> 
> Total: 123 packages (80 upgrades, 1 in new slot, 42 reinstalls), Size of downloads: 670,253 KiB
> 
> real	1m56.302s
> ...

 

Ich denke dass sich --newuse und --changed-use gegenseitig ausschließt -> es ist nur eine der beiden varianten aktiv

In deinem Falle @forrestfunk81 ist das --changed-use da es nach --newuse in der liste der parameter auftaucht

Selbst wenn man es schaffen würde die laufzeit von "emerge -p @world" auf dem problem rechner von misterjack zu lösen hätte er nicht viel davon.

Denn er hat ein "Problem" damit, dass viele pakete beim ihm recht lange brauchen zu bauen (sein Beispiel ist qtwebengine)

Das hat mehrere gründe:

1. Die komplexität einiger software komponenten hat über die Jahre stark zugenommen. Hauptsächlich im Bereich des Webrowsers.

    Dadurch dauert das bauen solcher software komponenten länger.

2. Sein Problemrechner verwendet eine CPU, welche Leistungstechnisch mittlerweile relativ schwach ist (bezogen auf das übersetzen von aktuellen software komponenten)

Aufgrund der gestiegenen Komplexität ist auch ein leistungstärkers System von nöten um die entsprechenden software komponenten wieder in kürzerer Zeit übersetzen zu können.

Das ist halt der große Nachteil eines Systems dessen Komponenten aus den Sourcen erstellt wird (beim user).

Bei binär Distributionen wird für ein Paket (mit version X) nur einmal der Aufwand erzeugt um das Paket zu bauen. Und nicht jedes mal wenn das Paket auf einem Zielsystem installiert wird.

Daher ist die Installation bei einer binär Distribution immer schneller als bei einer Distribution, wo auf dem System des users die Pakete aus den Sourcen gebaut werden.

Dafür ist die Flexibilität bei "Source based Distributionen" größer, da man die einzelnen Pakete besser auf die Bedürfnisse des Users/des Systems anpassen kann.

Und wie schon asturm gesagt hat. Jeder soll das nutzen was er mag bzw. was besser zu seinen Bedürfnissen passt.

----------

## ulenrich

Das soll man nicht machen: 

```
# time  emerge -auvN @installed

 * The @installed set is not recommended when updating

 * packages because it will often introduce unsolved blocker

 * conflicts. Please refer to bug #387059 for details.

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

Calculating dependencies  ..... ..... done!

Total: 0 packages, Size of downloads: 0 KiB

Nothing to merge; quitting.

real   1m11,892s

user   1m9,474s

sys   0m1,140s
```

 Wenn man sein System aber so genau vorkonfiguriert , dass man @installed statt @world nutzen kann, ist es schneller. Auf dem Weg dies nutzen zu können, werden Dir alle Sachen auffallen, die Dein Portage langsam machen. (Mein core2 Cpu ist auch veraltet)

----------

## ChrisJumper

Manchmal ist es halt einfach Pesch, das ein Update unglücklich liegt.

Ich würde dann folgendes machen misterjack:

Schauen welche Software in den letzten 3 Jahren verwendet wrude. Alle Daten aus Home speichern/backup. Dann das System minimal aufsetzen, vielleicht noch etwas schlanker als zuvor mit Wayland statt Xorg. Geht aber nur wenn man nicht spielen will glaub ich. Weiß noch nicht ob Steam auch mit Wayland geht, müsste ich noch mal schauen.

Gleichzeitig neue Hardware kaufe - weil man alle X Jahre auch mal was neues braucht. ;)

Sich dann drei Tage Urlaub/Zeit nehmen wo man sich das einrichtet und alles schön zurecht legt wie man es denn nun haben will.

Dann einfach los legen.

Alte Gentoo-Systeme sind über die Jahre mal, ich sag mal einfach: Überfüllt. Blöd auch wenn man zwischen drin noch mal "proprietäre Linux Software" versucht hat zu installieren. Duden Korrektur, Turboprint Drucker Treiber oder so was... davon muss man sich einfach mal Lösen, weil es mit der Zeit auch oft bessere Quelloffene Lösunge gibt!

Solche Probleme hat man eigentlich nur unter Windows.. dachte ich immer. Aber ich hab die jetzt auch unter Linux gehabt weil ich dank Rolling Releases immer noch Bestandteile von meinem System von 2006 hab! Also Daten in Config-Dateien oder eben E-Mails und Fotos etc.. wobei nein ich hab auch noch eine E-Mail von 2003. Aber die kann ja schon mal länger da gelegen haben! ;D

Viel Kram war bei mir auch von LGP, für Spiele mit eigenem DRM. Mittlerweile ist LGP Pleite und ich glaube die Spiele gehen nicht mehr weil DRM oder keine kompatiblen C oder Opengl Bibliotheken. Ich könnte das noch mal probieren...

Gewechselt hat sich bei mir eigentlich nur viel wenn ich von Openrc auf Systemd migriert bin, oder ich mein Python oder Emerge mal böse zerschossen habe oder sich die Hardware etwas umfangreicher verändert. Aber im Grunde hatte alles immer gut geklappt. Auch der Wechsel von 32 auf 64 Bit, wo ich mal eben die Useflags änderte und das ganze System aus sich heraus neu Compilierte. Teilweise aus Chroot mit einer 64 Bit Live-CD.

Mit anderen Systemen geht das so glaub ich nicht.. aber da hat man auch einfach dann das Backup was man einfach wieder nutzt.

Was ich noch schreiben wollte. Bei neuer Hardware ist dann die Compilerzeit auch wieder nicht so schlimm. Wenn einen das dann noch stört, muss man halt runter mit dem Speck/Fett und versuchen das System schlanker zu gestalten.

Aber ich kann es auch nachvollziehen aktuell hab ich wieder einen Blocker, den ich mir genauer anschauen muss:

Der Verzicht von Python Single Target, von 2.7 auf 3.6 - Zuvor war ich auf Python 3.5 weil das dieses Wiki zu Python empfahl. Jetzt gibt es da aber blöde Blocks beim emerge -avu world. Aber auch weil ich zum Beispiel den Window-Manager i3 probieren wollte und der zieht immer Pakete mit rein die entweder 2.7 Python als Single Target wollen (dabei war ich da mal runter).

Für die meisten Sachen kann Gentoo nix. Das mit Openssl und Libressl, da muss man sich entscheiden und das neu Programmieren hat bei einigen Projekten sehr lange gedauert. Wie aktuell auch dieses Python Upgrade. Aber das liegt an den Skriptsparachen und Teilweise der Modernisierung. Andere Projekte haben da auch dran geknabbert. Hatten aber wahrscheinlich eine größere Community.

Aber ich sehe das unter Linux alles nicht als Konkurrenten, wir sind doch eine große Familie hier!

----------

## misterjack

 *ChrisJumper wrote:*   

> Gleichzeitig neue Hardware kaufe - weil man alle X Jahre auch mal was neues braucht. 

 

hahaha. An dem Punkt bin ich ausgestiegen. Es gibt genau einen einzigen Task, der mir zu lange dauert & das sind Gentoo Updates. In _allen_ anderen Belangen bin ich rundum zufrieden. Warum funktionsfähige Hardware deswegen aussortieren?

PS: Es ist ausschließlich Software installiert, die ich regelmäßig benutze. Darunter unter anderem auf dem Hauptrechner Steam + CSGO  :Smile: 

----------

## franzf

 *ChrisJumper wrote:*   

> Gleichzeitig neue Hardware kaufe - weil man alle X Jahre auch mal was neues braucht. 

 

Geht mir genauso wie misterjack. Meine Hardware funktioniert und ist schnell genug. Einzig RAM ist aufm Laptop manchmal knapp. Aber da ist noch ein slot frei...

 *Quote:*   

> Aber auch weil ich zum Beispiel den Window-Manager i3 probieren wollte und der zieht immer Pakete mit rein die entweder 2.7 Python als Single Target wollen (dabei war ich da mal runter).

 

Eigenen Tip beherzigen und auf wayland umsteigen  :Wink:  sway ist ein i3-kompatibler wayland window manager.

----------

## franzf

 *franzf wrote:*   

>  *ChrisJumper wrote:*   Gleichzeitig neue Hardware kaufe - weil man alle X Jahre auch mal was neues braucht.  
> 
> Geht mir genauso wie misterjack. Meine Hardware funktioniert und ist schnell genug. Einzig RAM ist aufm Laptop manchmal knapp. Aber da ist noch ein slot frei...
> 
>  *Quote:*   Aber auch weil ich zum Beispiel den Window-Manager i3 probieren wollte und der zieht immer Pakete mit rein die entweder 2.7 Python als Single Target wollen (dabei war ich da mal runter). 
> ...

 

Anscheinend hab ich das Forum kaputt gemacht  :Sad: 

----------

## mike155

Es gibt zurzeit noch mehr Anwender, die sich über lange Nachdenkzeiten von emerge wundern: https://forums.gentoo.org/viewtopic-t-1106724.html

----------

## misterjack

 *franzf wrote:*   

> Anscheinend hab ich das Forum kaputt gemacht 

 

lol, Seite 1 funktioniert aber anscheinend.

----------

## Klaus Meier

Also, jetzt habe ich wegen gentoo-kernel nach langer Zeit mal wieder vorbei geschaut und bin hierauf gestoßen. Ein Grund, warum ich so lange abwesend war, das ist die Tatsache, das mein Gentoo jahrelang ohne die geringsten Probleme geschnurrt hat. Klar, die Zeiten zum Kompilieren muss man einplanen, aber wen stören die denn? Das läuft doch im Hintergrund und stört die normale Nutzung nicht. Klar, neue Pakete laufen nicht immer durch, dann schreibt man halt einen Bugreport. Funzt bei Gentoo ziemlich gut. Bei KDE habe ich im April einen Bugreport geschrieben und es gibt bis heute keine Reaktion.

Ich hatte auch schon meinen Stress mit Gentoo und bin da auch schon mal ausgerastet. Aber unterm Strich ist es die Distro, bei der meine Vorstellungen umgesetzt werden. Das genialste sind die USE-Flags. Wenn ich mir die ganzen Diskussionen bei Debian anschaue, damit könnten sie ihre Probleme lösen.

Wer gehen will, der soll gehen. Aber wenn das Problem die Zeiten für ein Update sind, dann kann ich das nicht nachvollziehen.

----------

## misterjack

 *Klaus Meier wrote:*   

> Aber wenn das Problem die Zeiten für ein Update sind, dann kann ich das nicht nachvollziehen.

 

a) Darum hab ich dich auch nicht gebeten und b) hast du nicht richtig gelesen. In diesem Thread störe ich mich daran, dass es Ewigkeiten dauert, bis die zu aktualisierenden Pakete überhaupt angezeigt werden. Menschen, die nicht richtig lesen vor dem Posten kann ich besonders gut leiden.

----------

## ChrisJumper

misterjack ich kauf mir auch nicht immer neue Hardware. Vielleicht so alle zwei drei Jahre mal und alle anderen Geräte sind meistens auch noch im Einsatz bis wirklich mal was kaputt geht.

Wenn es mir dann doch zu langsam geht nutze ich Dist-CC und baue es auf der Hardware. Wollte mir das auch noch mal ordentlich aufsetzen, so das ein Build-Cluster die Pakete erstellt und ich die dann auf allen anderen Geräten einfach installieren kann. Das kann Gentoo, aber mir war der Druck noch nicht groß genug und die Zeit die ich dafür aufwenden muss um mir das ganze mit Cross-Compilation und Liste an installierten Paketen, logisch zeitsparend aufzusetzen.

Im Grunde wäre dafür ja eine VM gut, wo die VM quasi das Build-Target abbildet und dessen installierte Pakete.

Das steht noch auf meiner ToDo Liste.

Ich mag halt das man an Gentoo so viel Freiheit hat. Mit Archlinux hab ich schon öfter geliebäugelt aber es ist trotzdem eine Umgewöhnung oder ich muss mich ein wenig einarbeiten. Bei Gentoo kenne ich mich aber halbwegs aus und es hat mich noch nie im Stich gelassen, bis auf bei Fehlenden overlays und das manche Pakete nicht mehr so gut gepflegt werden. Aber dafür kann man sich im privaten ja einfach Ebuilds anlegen.

Neue Hardware nutze ich aber allein schon deswegen weil sie oft Sparsamer ist was den Energieverbrauch betrifft. Wenn das dann so in 50 bis 100 Euro Reichweite rückt greife ich schon mal zu.

----------

## misterjack

 *ChrisJumper wrote:*   

> Neue Hardware nutze ich aber allein schon deswegen weil sie oft Sparsamer ist was den Energieverbrauch betrifft. Wenn das dann so in 50 bis 100 Euro Reichweite rückt greife ich schon mal zu.

 

Wir reden hier von einem i5-3570T (siehe ersten Post) mit 45 W TDP. Den soll ich ersetzen?

https://www.computerbase.de/2012-04/intel-core-i5-3570t-wird-schnellster-stromsparer-seiner-klasse/

----------

## firefly

 *misterjack wrote:*   

> 
> 
> Wir reden hier von einem i5-3570T (siehe ersten Post) mit 45 W TDP. Den soll ich ersetzen?
> 
> https://www.computerbase.de/2012-04/intel-core-i5-3570t-wird-schnellster-stromsparer-seiner-klasse/

 

Selbst in dem bereich gibt es Neuerungen  :Wink: 

https://wccftech.com/amd-ryzen-7-2700e-ryzen-5-2600e-45w-tdp-cpus-leak/

Mit Zen2 cpus gibt es die neuen APUs (CPU + GPU) von AMD wobei wohl erst mal nur für mobile (e.g notbooks)

https://wccftech.com/amd-ryzen-4000-renoir-mobility-cpus-official-up-to-8-cores-16-threads-45w/

Bei intel gibt es den i9-9900T (der hat sogar nur 35W TDP)

https://www.anandtech.com/show/14256/intel-9th-gen-core-processors-all-the-desktop-and-mobile-45w-cpus-announced

Aber wenn die aktuelle CPU dir ansonsten mehr als ausreicht dann nutze sie solange wie du möchtest  :Smile: 

----------

## franzf

Es wird nicht bei 50-100 € eines neuen Prozessors bleiben. Wahrscheinlich ist ein neues Mainborad fällig. Und für optimalen Speed willst du auch neuen (schnelleren) RAM.

Selbst wenn es bei 50-100 € bleiben sollte kommt das wahrscheinlich nicht über die Stromrechnung wieder rein. Da spart man mehr wenn man nicht mehr selbst alles kompiliert.

Ich hab hier noch ältere Prozessoren am Start als misterjack, und für selber Programmieren reicht das eigentlich immer.

----------

## misterjack

 *firefly wrote:*   

> 
> 
> Bei intel gibt es den i9-9900T (der hat sogar nur 35W TDP)
> 
> 

 

Glatt mal den Markt gescheckt. Aktuelle Vorkommen: gebraucht für 240€ aus Schiena. Hey, wenn ich lachen will, geh ich normalerweise in den Keller. Und übrigens, was soll ein i9 dann überhaupt machen, wenn dieser i5 im RT-Betrieb und bei 11,6ms JACK-Latenz schon zu >80% Langeweile schiebt – Pullover stricken? Mit aktiven calculating emerge sind es drei statt vier Kerne, die je zu 80% am Rumdösen sind. Das Ding hat also weit mehr als genug Power  :Wink:  Und wenn ich 35W TDP möchte, rüste ich einfach auf i3-3250T ab.

```
top - 15:03:52 up 22:24,  5 users,  load average: 1,25, 2,26, 2,58

Tasks: 286 total,   2 running, 284 sleeping,   0 stopped,   0 zombie

%CPU0  :  9,6 us,  7,9 sy,  0,0 ni, 81,5 id,  0,0 wa,  1,0 hi,  0,0 si,  0,0 st

%CPU1  :  6,7 us,  9,4 sy,  0,0 ni, 82,3 id,  0,0 wa,  1,7 hi,  0,0 si,  0,0 st

%CPU2  :  7,3 us,  6,3 sy,  0,0 ni, 85,1 id,  0,3 wa,  1,0 hi,  0,0 si,  0,0 st

%CPU3  :  5,3 us,  8,0 sy,  0,0 ni, 86,0 id,  0,0 wa,  0,7 hi,  0,0 si,  0,0 st

MiB Spch:   7701,3 total,    526,6 free,    957,1 used,   6217,7 buff/cache

MiB Swap:      0,0 total,      0,0 free,      0,0 used.   6543,0 avail Spch

    PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     ZEIT+ BEFEHL                                                                                                                                                                               

  31341 mrjack    20   0  532876  69380  59924 S  24,3   0,9  55:27.08 jackdbus                                                                                                                                                                             

  31399 mrjack    20   0  477744 100260  80988 R  14,0   1,3  41:49.14 calfjackhost                                                                                                                                                                         

  31419 mrjack    20   0  841344  60016  56336 S  10,3   0,8  21:13.67 pulseaudio                                                                                                                                                                           

    806 mrjack   -98   0  876032  49844  25948 S   5,3   0,6   8:04.69 mpd                                                                                                                                                                                  

  31336 root     -51   0       0      0      0 S   4,7   0,0  15:40.99 irq/17-firewire                                                                                                                                                                      

  31384 mrjack    20   0  221796  55288  52712 S   3,3   0,7   6:48.86 a2jmidid                                                                                                                                                                             

    919 mrjack    20   0  741540  86812  48640 S   1,7   1,1   5:30.43 Xvnc                                                                                                                                                                                 

   1184 mrjack    20   0 2150884 276432 135440 S   1,3   3,5   8:32.08 plasmashell  
```

Ansonsten halte ich es mit der CO2-Bilanz so niedrig wie möglich: funktionierende Hardware tauschen erzeugt wieder einen riesigen Impact. Die neue musste extra für mich produziert werden – je öfter ich nachfrage, auch gebraucht, desto eher wird noch mehr produziert. Dann der Transport des neuen zu mir und des alten von mir weg ... ne, da spiel ich nicht mit und nutze bestehendes & dieses eben konsequent  :Smile: 

Siehe auch: Nutze, was du hast!

----

Edith hat mal neuerlich nachgemessen, dieses Mal auf meinen Hauptrechner – kurz zur Ausstattung: i7-4790K „Devil's Canyon”, 32 GB Ram, NVME SSD, GTX 1060 6GB (ausreichend für 2xx FPS @ 2560x1600 @ CS:GO):

 *time emerge -pvquDN @world // 216 Pakete wrote:*   

> 
> 
> real    9m4,624s
> 
> user    9m0,673s
> ...

 

 *time emerge -pvquD @world // 208 Pakete wrote:*   

> 
> 
> real    10m35,545s
> 
> user    10m30,957s
> ...

 

Ja, das weglassen von -D reduziert die Zeit auf 1m4,854s – es gab mal Zeiten, da war das mit -D so schnell. Egal, ohne -D könnte ich sogar leben. Aber kann mir jemand in verständlichen einfachen Sätzen erklären, warum -uDN anderthalb Minuten weniger braucht wie -uD? Übrigens mehrmals ausgeführt, nur um auszuschließen, dass irgendein Prozess die CPU weggefuttert hatte. Mir fällt nur einwas ein: Crap

Disclaimer: /etc/portage ist aufgeräumt, keine ungenutzte Software installiert & es werden Binaries gebaut, die der Medienrechner dann bezieht. Ich habe hier somit ‚lediglich’ auf Ivybridge optimiert.

----

Edith hat jetzt auch den Arch-Laptop aktualisiert. Hab mal so drüber geschaut, was da alles aktualisiert wurde, das entspricht definitiv einem -D. War mit Installation in 2m5,131s durch. 204 Pakete. Geil.

----------

## mike155

Nach dem heutigen 'eix-sync' habe ich Sakakis emtee ausprobiert:

Ergebnis:

```
time emerge --update --deep --newuse -p @world 

[ebuild   R    ] app-portage/layman-2.4.2-r1

[ebuild     U  ] app-text/iso-codes-4.4 [3.76]

[ebuild   R    ] app-office/unoconv-0.8.2 

[ebuild   R    ] net-analyzer/wireshark-3.0.7

[ebuild     U  ] www-client/firefox-68.4.1 [68.3.0]

[ebuild   R    ] gnome-base/libglade-2.6.4-r2

real    0m56.546s
```

```
time /tmp/emtee -pN

[ebuild   R    ] media-libs/libwebp-1.0.2 

[ebuild   R    ] app-portage/layman-2.4.2-r1 

[ebuild     U  ] app-text/iso-codes-4.4 [3.76]

[ebuild   R    ] app-office/unoconv-0.8.2 

[ebuild   R    ] net-analyzer/wireshark-3.0.7 

[ebuild   R    ] gnome-base/libglade-2.6.4-r2 

[ebuild     U  ] www-client/firefox-68.4.1 [68.3.0]

real    0m36.475s
```

Ergebnis: bei mir ist emtee nur ein etwas schneller. Ich kann mir aber gut vorstellen, dass es in Fällen, in denen emerge sehr lange zum Nachdenken braucht, deutlich schneller ist.

----------

## musv

Ich nutze Arch auf dem Notebook meines Vaters, was ich immer nur bei einem Besuch mal aktualisier. 

Das läuft dort schon seit Jahren "relativ" problemfrei. 

Wenn allerdings mal irgendwas durch ein Update zerschossen wird, dann kommt man ohne Google nicht weiter.

----------

## ulenrich

Und keiner probiert es mit  @installed

was ich empfohlen habe?

Vor allen Dingen: mit @installed wird man auf miskonfigurierte Verhältnisse gestoßen, die man lange zuvor angerichtet hat!

Und die bedingen dann das Rumgetrödel von emerge ....

----------

## franzf

 *ulenrich wrote:*   

> Und keiner probiert es mit  @installed
> 
> was ich empfohlen habe?

 

Das hier liest sich aber überhaupt nicht wie eine Empfehlung:

https://forums.gentoo.org/viewtopic-p-8405852.html#8405852

 *Quote:*   

> Das soll man nicht machen

 

----------

## Josef.95

Und schneller ist damit wahrscheinlich auch nix: 

```
# time  emerge -puvN @installed

 * The @installed set is not recommended when updating

 * packages because it will often introduce unsolved blocker

 * conflicts. Please refer to bug #387059 for details.

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

Calculating dependencies... done!

Total: 0 packages, Size of downloads: 0 KiB

real    0m14,248s

user    0m13,668s

sys     0m0,275s

# time  emerge -puvN @world

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

Calculating dependencies... done!

Total: 0 packages, Size of downloads: 0 KiB

real    0m5,181s

user    0m5,037s

sys     0m0,125s
```

Und --deep weglassen ist idR vermutlich auch keine gute Idee.

----------

## misterjack

 *Josef.95 wrote:*   

> Total: 0 packages

 

Das ist 0 aussagekräftig. Ich warte hier gerade wieder auf min 200 upzudatende Pakete für neue Tests  :Wink: 

----------

## Josef.95

 *misterjack wrote:*   

>  *Josef.95 wrote:*   Total: 0 packages 
> 
> Das ist 0 aussagekräftig. Ich warte hier gerade wieder auf min 200 upzudatende Pakete für neue Tests ;)

 

Das ist schon aussagekräftig -- die deps der aktuell 1091 installierten Pakete müssen dabei ja auch berechnet werden.

Und hey ja, ich warte meist nicht so lang mit Updates (ich mache die idR täglich), da sind das dann meist nicht so viele.

----------

## mike155

 *misterjack wrote:*   

> Ich warte hier gerade wieder auf min 200 upzudatende Pakete für neue Tests 

 

Wenn Du die 200 upzudatenden Packete hast (oder wieder eine Situation, in der emerge außerordentlich lange nachdenkt): könntest Du dann bitte Sakakis kleines Script emtee (s.o.) probieren? Ich werde es natürlich auch selbst testen, wenn mein emerge wieder mal lange brauchen sollte. 

Das kleine Script ruft übrigens auch emerge auf, aber mit Parametern für ein andere Strategie. Es würde mich interessieren, ob es tatsächlich deutlich schneller ist, wenn der normale emerge-Aufruf lange Zeit zum Nachdenken braucht. Und natürlich würde mich auch interessieren, ob "das Richtige" dabei herauskommt...

Sakaki arbeitet u.a. mit Raspberrys - die einen Faktor 10 langsamer sind als "normale" PCs. Da kann ich schon verstehen, dass ihn die Wartezeiten auf emerge so genervt haben, dass er ein Script entwickelt hat, um es zu beschleunigen.

----------

## misterjack

 *Josef.95 wrote:*   

> Das ist schon aussagekräftig -- die deps der aktuell 1091 installierten Pakete müssen dabei ja auch berechnet werden.

 

Nein. Ich zitiere mich selbst:

 *misterjack wrote:*   

>  *Josef.95 wrote:*   Ich denke wenn misterjack nur wollte, dann könnte auch er sein Gentoo wieder flott bekommen  
> 
> Haha, Witzbold. Wenn genau 0 Pakete zu updaten sind, hab ich auch nur:
> 
> ```
> ...

 

----------

## ChrisJumper

misterjack, ich glaub da ist aber auch das python update mit dabei, oder hast du dies schon hinter dich gebracht?

Also der wechsel von python 2.7 auf den neuen default python 3.6?

Das ist vor allem deswegen komplizierter weil es noch einige veraltete 2.7er Pakete gibt die noch nicht das neue 3.6er unterstützen. Insofern ist das eine Ausnahmesituation.

Generell ist es natürlich trotzdem so das eine Linux-Distribution mit mehreren Entwicklern/Unterstützern und Nutzern auch zwangsläufig schneller die Pakete aktuallisiert bekommt.

----------

## ulenrich

 *Josef.95 wrote:*   

> Und schneller ist damit wahrscheinlich auch nix: 
> 
> ```
> # time  emerge -puvN @installed
> 
> ...

  Eben!

Du vergleichst ein tiefes/vollständiges Upgrade mit einem flachen:

time emerge -puvU @installed; time emerge -puvUD @world

must du vergleichen!

----------

## misterjack

edith: bloedsinn gelöscht  :Smile: 

----------

## franzf

Sodele, hab ja jetzt schon einige Zeit Arch am Laufen. Drum ein kleiner Kommentar:

Läuft. Aus User-Perspektive ist eigentlich nichts zu beanstanden.

AAAAAAber...

 Pacman ist in keinster Weise flexibel wie emerge. Und ich meine jetzt nicht die ganzen package.* Dateien.

    emerge hat so viele Optionen, mit denen man die Ausgabe steuern kann. In pacman muss das Wenige was man anpassen kann per config-Datei regeln.

   Aber gut, man gewöhnt sich dran.

 Schlimmer ist, dass binaries gestripped sind, debug-Pakete werden nicht angeboten!!!

    Um debug-Symbole zu bekommen darf man wieder selber kompilieren...

    Das war mir leider nicht klar. Zum Programmieren brauch ich aussagekräftige Backtraces.

 Ein Kernel-Update entfernt den alten Kernel samt Module.

    Natürlich ist das der Kernel, der gerade läuft. Ähem...

    Alles, was Module benötigt, die gerade noch nicht geladen sind, wird nicht funktionieren.

    Lösungen reichen von manueller Intervention über IgnorePkg bis zu eigenem Scriptgebastel.

    Natürlich gibt es einen bugreport dazu: https://bugs.archlinux.org/task/16702

    Der ist jetzt über 10 Jahre alt, und nix ist passiert! MMn. unglaublich.

Ich weiß jetzt leider grad nicht, warum Arch so beliebt ist. Als upstream-Developer brauch ich debug-symbole, muss also selber kompilieren. Dafür ist Gentoo aber viel besser geeignet da flexibler.

Für den Durchschnittsuser ist die Installation und Administration über Konsole unbequem und fehleranfällig. Da ist Ubuntu&Co besser geeignet.

Und wenn ich regelmäßig nach Updates das System neustarten muss kapier ich nicht, warum man überhaupt Linux verwendet. Kann man gleich bei Windows bleiben.

Ich bin jetzt genau da angekommen, wo ich immer gelächelt hab, wenn andere davon erzählt haben: monatliches Distri-Wechseln.

Mal schauen ob ich fündig werde. Gentoo ist auf meinen alten Rechnern leider kein Thema mehr, das jedenfalls ist mir mit Arch klar geworden. Weil beim Update regelmäßig die Rechner für Stunden unbenutzbar waren.

Mir gefällt Rolling Release, als nächstes kommt mir Suse Tumbleweed auf meinen Laptop. Mal schauen wann. Installation sollte ja schnell gehen.

[rant]Und wenn alle Stricke reißen muss halt doch ein neuer Rechner her, mit neuestem, buzgverseuchtem Prozessor und 128GB RAM (man will ja länger was davon haben, nicht wieder nur 5 Jahre) und SSDs und neuestes Super-USB uswusf... Gut, gibt halt 2-3 Jahre keinen Urlaub, dafür ist das Update halt bei einer Tasse Kaffe erledigt.[/rant]

----------

## mike155

franzf, mit Gentoo ist es wie mit dem Hotel California: "you can checkout any time you like, but you can never leave!"   :Smile: 

Gentoo hat einfach zu viele Vorteile! Man gewöhnt sich an die Vorteile und nimmt sie als gegeben hin - ärgert sich aber gleichzeitig über die Nachteile, die es natürlich auch gibt! Wenn man dann andere Distributionen ausprobiert, ist man erst einmal begeistert - aber nach und nach merkt man, was einem fehlt. Und irgendwann kommt man dann wieder zu Gentoo zurück  :Smile: 

----------

## firefly

 *franzf wrote:*   

> 
> 
>  Schlimmer ist, dass binaries gestripped sind, debug-Pakete werden nicht angeboten!!!
> 
>     Um debug-Symbole zu bekommen darf man wieder selber kompilieren...
> ...

 

Das bieten debian/radhat basierte Distries als separate pakete an. Das ist dann doch etwas schwach von Arch

 *franzf wrote:*   

> 
> 
>  Ein Kernel-Update entfernt den alten Kernel samt Module.
> 
>     Natürlich ist das der Kernel, der gerade läuft. Ähem...
> ...

 

Und auch hier sind debian/redhat besser aufgestellt. Bei denen wird die alte version nicht gleich entfernt sondern als fallback im bootloader hinterlegt.

Und zu mindestens bei Debian werden alte kernel versionen auch nicht automatisch bei einem update entfernt, selbst wenn die installierte version nicht mehr im repository enthalten ist. Es gibt nur ein Hinweis dass eine "veraltete" Version installiert ist und wie man diese version deinstalliert bekommt.

----------

## l3u

 *franzf wrote:*   

> [rant]Und wenn alle Stricke reißen muss halt doch ein neuer Rechner her, mit neuestem, buzgverseuchtem Prozessor und 128GB RAM (man will ja länger was davon haben, nicht wieder nur 5 Jahre) und SSDs und neuestes Super-USB uswusf... Gut, gibt halt 2-3 Jahre keinen Urlaub, dafür ist das Update halt bei einer Tasse Kaffe erledigt.[/rant]

 

Ach naja, mein Ryzen 5 3600 mit nur 32 GB RAM (10 davon als tmpfs für portage), einer 500 GB-nmve-SSD und einer 500-GB-oldschool-HD läuft ganz akzeptabel eigentlich ;-) Und sooo teuer ist der Kram ja nicht mehr. Wenn man ne Graphikkarte für 50 € reinbaut.

----------

## misterjack

 *l3u wrote:*   

> Und sooo teuer ist der Kram ja nicht mehr.

 

Dieses Nichtargument ist sowas von ausgelutscht – ich zitiere mich mal selbst:

 *misterjack wrote:*   

> Ansonsten halte ich es mit der CO2-Bilanz so niedrig wie möglich: funktionierende Hardware tauschen erzeugt wieder einen riesigen Impact. Die neue musste extra für mich produziert werden – je öfter ich nachfrage, auch gebraucht, desto eher wird noch mehr produziert. Dann der Transport des neuen zu mir und des alten von mir weg ... ne, da spiel ich nicht mit und nutze bestehendes & dieses eben konsequent 
> 
> Siehe auch: Nutze, was du hast!

 

----------

## l3u

Naja, also ich hab z. B. noch ein mittlerweile 15 Jahre altes Dell-Notebook mit Gentoo drauf laufen. Mittlerweile nicht mehr mit KDE, sondern mit LXQt. Und mein Raspberry Pi der 1. Generation (von Anfang 2012, wenn ich mich recht erinnere), ebenfalls mit Gentoo. Ist jetzt nicht so, dass ich meine Hardware jährlich tausche …

Ich kann mich nur noch lebahft daran erinnern, als ich damals 8 MB RAM als Upgrade in unseren Pentium-90-Familiencomputer gesteckt habe, um auf summa summarum 16 MB RAM zu kommen. Und die ein kleines Vermögen gekostet haben. Das hab ich eigentlich eher damit gemeint, dass der Kram nichts mehr kostet.

----------

## ChrisJumper

Im Grunde ist es egal was man einsetzt, solange man den Source Code hat, weiß wie man mit Compiler Fehlern umgehen kann um Lösungen zu finden und zeitgleich seie Wünsche realisieren kann. Die parallele Nutzung von Gentoo, Archlinux, Debian und Android oder noch besser ein Linux auf dem Smartphone steht dem nichts im wage. Man muss halt nur wissen was man tut und man muss es nachvollziehen können. Gentoo war da bisher immer sehr zuvorkommend.

----------

