Questions about Gentoo

Hi!

1. Does Gentoo automount to /media or to /run/$USER/media ?
2. If I exclude "gtk3" in USE flags, will it make all GTK apps GTK2-style? Like, I use gThumb, that is my fave photo viewer. And it switched to GTK3 about 2 years ago or so, which made the interface ugly. Is it possible in Gentoo to install GTK2 version of gThumb with "USE flags"? Modern version but with GTK2.
3. How do I manage services in Gentoo? Like in Arch in 2010? ("service httpd start" or "/etc/rc.d/httpd start")
4. In Arch there's no way to avoid systemd anymore, they basically hardcoded it into the whole thing. If you use Arch, you use systemd. No options available. Love it or leave it. Gentoo on the other hand still installes itself without systemd by default and has systemd as an option for those who want to use it. Is it possible for the distro in some near future to become like Arch — only systemd and no other options? (I'm not even interested in "options", I just want bash scripts ro run the whole thing like it has always been in the past with all our distros.)

Originally Posted by Mr. Alex Hi! Does Gentoo automount to /media or to /run/$USER/media ? If I exclude "gtk3" in USE flags, will it make all GTK apps GTK2-style? Like, I use gThumb, that is my fave photo viewer. And it switched to GTK3 about 2 years ago or so, which made the interface ugly. Is it possible in Gentoo to install GTK2 version of gThumb with "USE flags"? Modern version but with GTK2.

Don't know for the first one, answered the second one in a different thread, but here it goes again: If a specific software (in your case gThumb) is written against GTK version 3 you can't magically make it run with GTK version 2, those two are not interchangeable without doing some serious backporting work.

How do I manage services in Gentoo? Like in Arch in 2010? ("service httpd start" or "/etc/rc.d/httpd start")

For Gentoo's default init system (OpenRC) starting a service would be

rc-service servicename start

In Arch there's no way to avoid systemd anymore, they basically hardcoded it into the whole thing. If you use Arch, you use systemd. No options available. Love it or leave it. Gentoo on the other hand still installes itself without systemd by default and has systemd as an option for those who want to use it. Is it possible for the distro in some near future to become like Arch — only systemd and no other options? (I'm not even interested in "options", I just want bash scripts ro run the whole thing like it has always been in the past with all our distros.)

The Gentoo developers are doing some hard work on making it possible to run Gentoo without systemd, for example with forking udev into eudev, providing an alternative for upower since it is systemd-only, ... . I for one have only systemd-udevd (haven't bothered yet to try eudev), but no other part of systemd on my systems.

TobiSGD, thanks, got your answers in both threads.

For Gentoo's default init system (OpenRC) starting a service would be rc-service servicename start

What about typing in the path of service binary? Like "/etc/rc.d/httpd start"? Arch had that. Does Gentoo?

Also: is OpenCDE present in Gentoo's repositories?

Originally Posted by Mr. Alex TobiSGD, thanks, got your answers in both threads. What about typing in the path of service binary? Like "/etc/rc.d/httpd start"? Arch had that. Does Gentoo?

You can do that, but you may have problems with the service inheriting root's environment (this can by the way also happen with other init systems.

Also: is OpenCDE present in Gentoo's repositories?

Currently not, as it seems.

Originally Posted by Mr. Alex Does Gentoo automount to /media or to /run/$USER/media ?

Mounts on /run/media/$USER/

Originally Posted by Mr. Alex How do I manage services in Gentoo? Like in Arch in 2010? ("service httpd start" or "/etc/rc.d/httpd start")

Depends on the init system. If using systemd, we use systemctl commands. If using openrc, rc-service <service> start|stop or /etc/init.d/<service> start|stop... can be used.

Some bits here and there...

Regarding starting and managing services, you can just take a look at the handbook, which is the only supported method to get Gentoo installed. In that process you will learn how to do all that stuff. The default init system for Gentoo is OpenRC. However, the handbook includes a link to a separate document on how to use systemd instead (you probably don't want that, but it's there for those who do).

As for Gtk+3, that entirely depends on the package, as someone said above. First, the software has to support it upstream; and then, the ebuild needs to contemplate that possibility (to choose between gtk+2 or gtk+3. Sometimes, the application doesn't have support for one or the other gtk+ version. Sometimes the ebuild doesn't offer the USE flags. The later can be solved by opening a bug report, which will get more love if it includes a patch, a modified ebuild with the USE flags, or, at least, a confirmation that it can be done (meaning that you know beforehand that that version of the application compiles against the two gtk+ versions unmodified or with trivial patches, and that you know it before you already did it and it worked ).

Note however that everything is moving towards gtk+3. I know first hand because I maintain myself a local overlay where I save modified ebuilds and patch things like evince, bluefish and some xfce components to keep them running with gtk+2. That can only get worse in the future unless I freeze my install and never update again.

Regarding the device managing stuff, for now you can go the systemd route, the consolekit/policykit route, or even maintain a static /dev using mdev. You can find docs about all that stuff around, and the official gentoo forums are full of posts about that. I also have a patched version of bashmount that works fine with udevil, so if you are paranoid about udisks-*kit*-udev you can live without all that.

For now, the default Gentoo installation will be with OpenRC, and it still uses the *kits to manage multiuser, permissions on devices and that stuff.

And no, no OpenCDE there, not even in any overlay (that I know of). I am not sure it's even usable.

Will it help to improve speed of programs if I add certain USE flags of CPU instructions globally like adding "sse sse2 sse3 ssse3 sse4_1"? And if yes, which to add aside from these?

Originally Posted by Mr. Alex Will it help to improve speed of programs if I add certain USE flags of CPU instructions globally like adding "sse sse2 sse3 ssse3 sse4_1"? And if yes, which to add aside from these?

Short answer: yes.

But those flags are only applicable to a very small subset of the packages (mplayer comes to mind). Note that those USE flags activate some special code paths in those programs. That is, some alternative code is used instead of the standard (generic) code path which will work for all the cpus.

This is quite different from what CFLAGS with similar names do (and these days you don't need to use those anyway, usually). CFLAGS will apply to all the packages, with a few exceptions.

As for which others to add, don't worry, you'll discover over time. A big part of it is to always run emerge with -va and carefully watch at the output, then ask for help if you have doubts.

Originally Posted by Mr. Alex Will it help to improve speed of programs if I add certain USE flags of CPU instructions globally like adding "sse sse2 sse3 ssse3 sse4_1"? And if yes, which to add aside from these?

cat /proc/cpuinfo will show you which flags your cpu supports, just copy and paste into the USE= section in make.conf

Originally Posted by Mr. Alex Hi! [*] In Arch there's no way to avoid systemd anymore, they basically hardcoded it into the whole thing. If you use Arch, you use systemd. No options available. Love it or leave it. Gentoo on the other hand still installes itself without systemd by default and has systemd as an option for those who want to use it. Is it possible for the distro in some near future to become like Arch — only systemd and no other options? (I'm not even interested in "options", I just want bash scripts ro run the whole thing like it has always been in the past with all our distros.)[/LIST]

Christian Neukirchen prepared ignite which will switch Arch to runit and also get back the old rc.conf for configuring it. I don't know if he still uses Arch, as Void Linux now uses his work and switched from systemd to runit, and he also works on packages there. As for Void Linux: if you liked Arch, you might like VoidLinux. It uses xbps, which is a binary package manager similar to pacman.

Gentoo should still have upower-0.9.23 available. I think this was the last release that was system agnostic.

Originally Posted by mrbassie cat /proc/cpuinfo will show you which flags your cpu supports, just copy and paste into the USE= section in make.conf

Not quite.

Most cpu flags don't have a matching USE, and some others are worded in a different way. As an example, the 'pni' cpu flag means that your cpu has sse3 support and matches the 'sse3' USE (not to be mixed with the 'ssse3' one).

Originally Posted by i92guboj Not quite. Most cpu flags don't have a matching USE, and some others are worded in a different way. As an example, the 'pni' cpu flag means that your cpu has sse3 support and matches the 'sse3' USE (not to be mixed with the 'ssse3' one).

I didn't know that. Is there something I can look at to compare/translate?

Not really (that I am aware of).

However, there are not that much USEs that relate to this. I can only remember mmx, 3dnow, 3dnowext, ssse3 and all the sse* derivatives. Note that I can only speak about x86 and x86_64. No idea about other architectures.

And those affect a very small subset of packages.

About "pni", it stands for "prescott new instructions", honoring the first cpu that shipped that instruction set (or so I believe). It was a new version of the old sse and sse2 sets, so it was only natural that people started calling it "sse3" rather than "pni". Don't quote me on that though. It's been long since I stopped caring about all this stuff and about knowing about every single chip in the market, and wikipedia probably knows better than I do anyway