I’ve recently realized that I’ve never written about how I’m running my desktop setup on Linux. Triggered by having to revamp one of my Gentoo portage ebuilds for my desktop, let me remedy this and tell you a bit about what my personal computing outside the Homelab looks like.

My Linux journey started back in 2007. I was about to start my computer science degree. And I had allowed myself one month between finishing the then mandatory military service and some jobs to bridge the time before University and my program starting in October. At the beginning of September, I got my first University laptop, an Acer TravelMate 5720 Core 2 Duo with an ATI GPU and Windows Vista. Receiving that laptop, I thought to myself: Any real CS student should be running Linux.

Yes, dear reader, I’m ashamed that I was that particularly annoying kind of nerdy CS student.

Leaning even more into being that annoying kind of CS student, I also thought: I need a real, hardcore Linux distribution. So I ended up with Gentoo. It was the “I’m running Arch, by the way” distro back then. I would definitely be rolling my eyes pretty hard at past me if we were to meet today.

But it was what it was, and having an entire month to do basically nothing else but prepare the machine, I actually got it up and running with everything I cared about, including WiFi and working graphics.

Trigger warning for people who ran ATI/AMD back in the day.

The word fglrx still gives me shudders to this day. Linux has come a loooooong way since that time. Don’t let anyone tell you otherwise.

It honestly worked out reasonably well, all told. I stayed with Linux as my main driver during my entire study time. Over the years, the occasions where I felt the need to boot into the parallel Windows install for anything else than gaming became fewer and fewer.

Like every student at University, I also experimented. No, not with drugs of course (Dear reader, there were drugs. 😁). With desktop environments. Many a semester, I realized my desktop setup wasn’t ideal. Surprisingly, that always happened during exam time.

I spend most of the initial few years switching between KDE and Gnome on a regular basis. I even experimented a bit with tiling window managers, mainly i3wm if I recall correctly. But tiling window managers never really clicked with me and I always returned to either Gnome and KDE. With the years, both KDE and Gnome became ever nicer and got more features, but also became slower and slower on my aging laptop. So one day I ended up on XFCE, and haven’t changed since then.

Surprisingly, in hindsight, I never did any distro hopping at all. I honestly have no idea why. I always stayed with Gentoo for my main driver. I even went with Gentoo for my first Homelab machine, but that’s a different story I will definitely tell one day.

Overall, I like both Gentoo and XFCE. When it comes to Gentoo, I no longer believe in the “ricing” mindset from 2010. I do know for a very detailed, very well researched and tested fact that yes, non-generic compile options with an march, mtune and mcpu for your specific chip can make a massive, unbelievable difference. But not on the desktop. What I do continue to like about Gentoo is its excellent wiki, its ability to control a package’s configure flags and building only the features I want and the fact that it’s a rolling release distro, which I do like on the desktop. Another reason I’ve stayed with Gentoo for my desktop: It is a rather welcome excuse to get myself a shiny new CPU from the high performance segment of the product stack every once in a while. 😁 Gentoo has also been really stable. I’ve been running the ~amd64 keyword for ten years now, without issue. That’s Gentoo’s equivalent of the testing branch in other distros.

Since 2021, I’m even running my gaming on Linux and got rid of my Windows partition. Here I must admit I’m not using Gentoo’s packages for Steam, though. Those need “multilib” functionality, because it’s all still 32bit. And that was just a tad bit too much for my taste, so I’m using Steam via Flatpak instead.

My current install is from 2017, when I got my first desktop PC in 10 years after finishing (ahem…) University and starting to earn real money. It’s currently a beQuiet! tower with an AMD Ryzen 9 3900X and an AMD RX 580.

It will be time for a proper upgrade soon though, as building qtwebkit (aka Chromium) takes about 1.5h now.

As you can see, I’ve been pretty conservative in my Linux daily driver usage for a long time. I’m sometimes wondering whether that’s because I came across the DistroTube YouTube channel one day, watched three of his videos and then nope’d out of the entire “my Linux desktop is more than just a tool” community. The next change will likely be the switch to something which supports Wayland, so I’m not caught unprepared when X11 disappears from the Gentoo repos.

For a time, I’ve been a lot more experimental on my laptops, which I’m now only using when traveling. I started out with Arch there to see what all the fuss is about, and then went for Manjaro, because I was hoping it would be a lower maintenance variant of Arch. Being pretty severely disappointed with both, I ended up with Fedora Workstation. Good, stable system that doesn’t fall apart when you update it.

I did a few experiments with desktop environments on the laptops too. I had XMonad for a while, then used Awesome WM for a time. But at some point I realized that I just wasn’t happy with the laptop as an experimental platform. I use it only when traveling, which happens perhaps 10 times a year or so. And each time I have to adapt to a different WM than what I’m using on my desktop, so I just stopped. I now have Fedora with Sway running, and that’s perfectly fine for me.

Finally, I think Gentoo even has a little bit to do with the fact that I ended up as a Build and Release engineer. What separated me from my colleagues was that I didn’t just know C++, I also knew CMake and autotools and Make and so on and so forth, because I had to touch all of them over the course of running Gentoo. And we’re using Yocto for dependencies and general builds at work, and Bitbake was inspired by Gentoo’s portage.

Alright, enough personal Linux lore, let’s get to the actual trigger for this blog post, creating ebuilds for Gentoo.

An ebuild for ceph-common

I’ve been using Ceph for the storage in my Homelab for a while now. One of the use cases is for a large “archive” filesystem I’m making available to my desktop via CephFS. To mount it, I’m using something like the following in /etc/fstab:

:/volumes/_nogroup/foo/bar       /mnt/warehouse/         ceph    name=mycephuser,nofail,_netdev,secretfile=/etc/my-ceph-secret,conf=/etc/ceph/ceph.conf 0 0

To use this style of fstab entry, you need a mount helper, so there’s something to interpret the ceph.conf and my-ceph-secret files and you don’t have to put the secrets into the fstab itself.

The problem now is: Gentoo’s portage does have a Ceph package, but that’s the entire enchilada, including all Ceph components. And I really only want the mount helper.

So I took the official Ceph ebuild and reduced it to the following:

EAPI=8

inherit cmake

DESCRIPTION="Common Parts of Ceph for clients only"
HOMEPAGE="https://ceph.com/"
SRC_URI="https://download.ceph.com/tarballs/ceph-${PV}.tar.gz -> ${P}.tar.gz"

S=${WORKDIR}/ceph-${PV}
LICENSE="Apache-2.0"
SLOT="0"
KEYWORDS="~amd64"
RESTRICT="mirror"

DEPEND="app-arch/lz4
	sys-apps/keyutils
	sys-libs/libcap-ng
	dev-libs/boost
	dev-libs/libfmt
	dev-libs/openssl
	dev-python/cython
	sys-apps/util-linux
	sys-apps/systemd-utils
	sys-libs/zlib
	app-arch/bzip2
"
RDEPEND="${DEPEND}"

PATCHES=(
  "${FILESDIR}/ceph-19.2.1-uuid.patch"
  "${FILESDIR}/ceph-19.2.1-graylog.patch"
)

src_prepare() {
	cmake_src_prepare
}

src_configure() {
	local mycmakeargs=(
	  -DWITH_MANPAGE=OFF
	  -DENABLE_SHARED=ON
	  -DCMAKE_POSITION_INDEPENDENT_CODE=ON
	  -DCMAKE_BUILD_WITH_INSTALL_RPATH=ON
	  -DWITH_RBD=OFF
	  -DWITH_OPENLDAP=OFF
	  -DWITH_GSSAPI=OFF
	  -DWITH_XFS=OFF
	  -DWITH_ZFS=OFF
	  -DWITH_BLUESTORE=ON
	  -DWITH_KVS=OFF
	  -DWITH_KRBD=OFF
	  -DWITH_RADOSGW=OFF
	  -DWITH_MGR=OFF
	  -DWITH_LTTNG=OFF
	  -DWITH_BABELTRACE=OFF
	  -DDEBUG_GATHER=OFF
	  -DWITH_TESTS=OFF
	  -DWITH_SEASTAR=OFF
	  -DWITH_MGR_DASHBOARD_FRONTEND=OFF
	  -DWITH_SYSTEMD=OFF
	  -DWITH_RDMA=OFF
	  -DWITH_SYSTEM_BOOST=ON
	  -DWITH_LIBCEPHSQLITE=OFF
	  -DWITH_JAEGER=OFF
	)
	cmake_src_configure
}

src_compile() {
	cmake_src_compile mount.ceph
}

src_install() {
	into "/usr"
	dosbin "${BUILD_DIR}/bin/mount.ceph"
	dolib.so "${BUILD_DIR}/lib/libceph-common.so.2"
	insinto "/usr/$(get_libdir)"
	doins "${BUILD_DIR}/lib/libceph-common.so"
}

This requires two patches for building on a Gentoo system, which I took from the official ebuild as well:

• ceph-19.2.1-graylog.patch
• ceph-19.2.1-uuid.patch

I stuck the ebuild into my own overlay, configured like this in /etc/portage/repos.conf/my_repo.conf:

[my_repo]
auto-sync = true
location = /usr/local/portage
sync-type = git
sync-uri = https://git.example.com/admin/gentoo_overlay.git
sync-user = portage:portage

With that, I could sync the repo with the following command:

emaint sync -r my_repo

After adding a new ebuild, some metadata needs to be generated, like this:

ebuild ceph-common-19.2.2.ebuild manifest clean fetch unpack compile

Once the new ebuild has been synced, I can install it as usual:

emerge -uva ceph-common

And with that, I get the mount.ceph mount helper and can use the Ceph-specific options in the fstab, without having to install the full Ceph package.