Bit Cannon wesonlinux

A Month on Chimera Linux

wes@wezm.net (Wesley Moore) — Sat, 15 Jul 2023 09:20:06 +1000

I installed Chimera Linux</a> on my laptop a month ago and have been using it daily since then. This post details the experience so far.

</a>

Chimera Linux on HP Aero 13 laptop</h4> </figcaption> </figure>
Note 07 Jul 2024: Keep in mind that this was written in July 2023 and the distro has continued to improve. So the following does accurately represent the current state of things.

What Is Chimera Linux?</h2> Chimera Linux</a> is a unique from-scratch Linux distribution created in 2021 by q66</a> that combines the Linux kernel</a>, musl libc</a>, FreeBSD</a> userland, apk package manager</a>, and dinit binary init system</a>. The whole system is built with the LLVM</a> toolchain. The homepage says:

It aims to be clean and usable while addressing the various shortcomings of an average Linux distribution.
It does so by liberating itself from the common baggage of most Linux-based systems and doing its own thing. Software is sourced from different places and sometimes written from scratch. </blockquote>
Notably this unholy combination yields a Linux system that is not GNU/Linux. From the about page</a>:

This means Chimera is not a GNU/Linux system, as it utilizes neither GNU utilities, nor GNU libc, nor GNU toolchain. The system is bootstrappable almost entirely without any GNU components (other than make</code>) and is capable of booting without them (however, most people will have some). </blockquote>
To build Chimera q66 also implemented a package build tool called cbuild</a> and ports tree, cports</a>. cbuild and cports are implemented in Python (using only the standard library). This allows the package building architecture to make use of the niceties of a full-featured programming language instead of shell scripts or Makefiles which are commonly used by other ports trees. Additionally cbuild builds in a sandbox that isolates the build from the host system. This avoids undiscovered dependencies and allows the system to bootstrap on a non-Chimera Linux systems.
Why?</h3> When picking any tool or software out of the ordinary a common question I see is: Why would you subject yourself to additional hurdles, bugs etc. I think this usually comes down to personal technology values and preferences. I'm not going to get into the specifics there but Chimera feels very close the distro I would build (and started building), so it's like my ideal distro. Update 4 Jul 2024: I expanded on this a bit more in: Why Chimera Linux</a>. Installation</h2> I have been closely following Chimera's progress towards a release that is deemed stable enough for daily use. With the announcement of the alpha phase</a> on June 11 that happened: Simply put, having entered the alpha phase means that the project is somewhat more ready to deal with users and potential repository expansion. In summary, the current state of the project means it’s daily-driveable and can be gradually updated without significant manual fixups, but there may still be bugs, missing documentation, and some things may still change at conceptual level. </blockquote> With the official go-ahead (despite travelling at the time) I wasted no time installing it on my laptop. My laptop is not my primary computer, it's more an ancillary device that I use kinda like an iPad — if you could actually code on an iPad too. I use it most days for web-browsing, email, chat, YouTube, but also coding (in Rust mostly) or writing blog posts like this one! I already had a spare partition to install into and while the docs</a> are adequate I do recommend reading them in their entirety (including the non-installation sections) before starting an installation. I deviated from the standard install by eschewing Grub as bootloader and using systemd-boot, which was already installed for the Arch Linux installation that Chimera boots alongside. My boot entry (/boot/loader/entries/chimera.conf</code>) looks like this: title Chimera Linux linux /vmlinuz-6.1.35-0-generic initrd /initrd.img-6.1.35-0-generic options root=PARTUUID=5ebb7ccb-5349-414c-bf1a-7bc8fb07aefb rw </code></pre> An unresolved issue with this is that unlike Arch, which uses filenames that don't include the kernel version the Chimera kernel and init RAM disk include a version. This means I have to tweak the bootloader entry whenever the kernel version changes. The installation target was a HP Pavilion Aero 13</a>, which I am using to write this post (from Chimera). This is a surprisingly capable computer for the price (AU$1079, approx $740 USD), mainly owing to the 8 core AMD Ryzen CPU. It's main drawback is 8Gb of non-upgradable RAM. The appeal of it for me was that it weighs only 966g. That puts it well into iPad with keyboard territory (iPad Air 461g + Logitech Cobo Touch keyboard 574g = 1035g) without the arbitrary limitations on what I'm allowed to do with the computer that come with iPadOS — it even has multiple USB-A ports! Basic specs are: CPU: AMD Ryzen™ 7 5800U (up to 4.4 GHz max boost clock, 8c/16t) RAM: 8 GB DDR4-3200 MHz RAM Storage: 1Tb NVMe Display: 13.3" diagonal, WQXGA (2560 x 1600), IPS Graphics: Integrated Radeon Graphics WiFi: Realtek Wi-Fi 6 My normal desktop environment is the Awesome window manager</a> but since that's not packaged yet (I have it working but need to clean it up) I went with the default GNOME 44 desktop. What Works</h3> HiDPI (I run the display @2x)</li> Wi-Fi</li> Audio</li> Bluetooth headphones</li> Web cam</li> Brightness and volume controls on keyboard</li> Trackpad, including multi-touch gestures</li> </ul> The whole system is smooth and responsive and has been totally reliable. I've had no crashes or application instability. It sleeps and wakes perfectly. Battery life seems to be about the same as I get in Arch: 4 or 5 hours depending on what I'm doing (an iPad certainly wins here). What Doesn't Work</h3> Fingerprint scanner — doesn't work in Arch either.</li> </ul> Experience Report</h2> With the installation done I set about installing my usual collection of software. The package manager is apk</code> from Alpine Linux</a>. My server runs Alpine</a> so I was already familiar with it. Firefox is in the package repo and includes a sub-package that has a desktop entry with the right arguments to make it run natively on Wayland. Firefox works great, including using the webcam and mic. I quickly missed CopyQ</a> for clipboard history and it looked a bit challenging to port so I opted for the gnome-clipboard-history</a> GNOME extension. None of the browser integration things would work to install the extension so I did it manually. One thing that stumped me for a bit but isn't really Chimera specific was how to enable the Compose key</a> in GNOME. Previously I'd done this in GNOME Tweaks but that isn't in the repos. After dealing with multiple pages of outdated</a> info</a> on the GNOME website I eventually discovered that you can now just set it in the Keyboard pane of the Settings app. </a> Compose key settings in GNOME Settings</h4> </figcaption> </figure> Being proprietary apps 1Password</a>, Obsidian</a>, and CLion</a> all would not run due to depending on glibc but fortunately they are all available as Flatpaks</a> on Flathub</a>. Installation was a simple flatpak install</code>. Later Flatpak also saved the day when it came to Prusa Slicer</a>, which despite being open-source depends on a specific patched development version of wxWidgets. 1Password isn't quite as integrated as usual due to the browser extension and application being separated by the Flatpak sandbox. This means that choosing Edit on an item in the browser opens 1Password on the web instead of the application. There's also no synchronisation of the lock state of the extension and application, meaning if you unlock with your password in one the other remains locked. I manage my dotfiles with dot</a>, which was easy enough to install with the packaged Rust toolchain (see below for notes on rustup). On the command line zsh</code> git</code>, and Neovim</code> were in the repos but other tools I commonly use were not: ripgrep</a>, fd</a>, tig</a>, bat</a>, zoxide</a>, git-grab</a>, fzf</a>, zenith</a>, and exa</a>. exa</code> seems unmaintained so I swapped it for lsd</a>, which had been recently added to the repos. A glace at the open PRs showed there were ports for zoxide</code> and bat</code> in progress. I set about building ports for ripgrep</a>, fd</a>, tig</a>, and fzf</a>. These were all easy enough although I had to tweak both ripgrep and fd to prevent them switching the Rust global allocator to jemalloc, since the jemalloc crate</a> fails to build on Chimera so far. git-grab</a> is a tool I wrote so wasn't sure it was popular enough to package right now. I settled for a simple cargo install git-grab</code>. zenith</code> failed to build for uninteresting reasons. I bumped a dependency to fix that and submitted a PR</a>. Once they publish a new release with that fix I might create a Chimera port for it. Some other notable tooling choices in the base system: Wi-Fi is managed with iwd</a>.</li> Pipewire</a> is the audio server.</li> doas</a> is the privilege escalation tool.</li> dinit</a> init system. Nothing to really say here. It's fast and has worked fine.</li> </ul> What's Missing</h3> Some things that I tried to install but hit roadblocks. Not necessarily insurmountable ones, just ones I haven't taken the time to tackle yet. Docker</a>/Podman</a> is not currently available but there is a work-in-progress PR for Podman</a>. This means that I currently can't use Chimera to build new images for my server</a>. I didn't dig too deeply but I'm not sure if there's a story for running VMs on Chimera at the moment. Normally I use virt-manager</a> but it's not packaged yet. Websites using Widevine DRM (like Netflix) don't work. It's likely that a backup Flatpak browser will work around this. I wanted to install Deno</a> to deal with a broken dependency on my very important website: mistakes.computer</a>. The pre-compiled binaries they publish use glibc so I tried building from source with: cargo install deno --locked</code>. That failed because a dependency (rusty_v8</a>) tries to avoid building V8 using a pre-compiled library that it fails to find for Chimera. Downloading https://github.com/denoland/rusty_v8/releases/download/v0.74.2/librusty_v8_release_x86_64-chimera-linux-musl.a... HTTP Error 404: Not Found </code></pre> You can tell it to build V8 from source: V8_FROM_SOURCE=1 cargo install deno --locked</code> but that also fails because building V8 depends on some Google specific build tool</a> that I haven't bothered trying to build/package so far. Rustup</a> installs and runs. It installs a stable-x86_64-unknown-linux-musl</code> toolchain but that is non-functional due to depending on libgcc</code>: $ ldd ~/.rustup/toolchains/stable-x86_64-unknown-linux-musl/bin/rustc /lib/ld-musl-x86_64.so.1 (0x7f3903800000) librustc_driver-d2bfe141fc706ea1.so => /home/wmoore/.rustup/toolchains/stable-x86_64-unknown-linux-musl/bin/../lib/librustc_driver-d2bfe141fc706ea1.so (0x7f38f9200000) libstd-fe6ad1580bc261a5.so => /home/wmoore/.rustup/toolchains/stable-x86_64-unknown-linux-musl/bin/../lib/libstd-fe6ad1580bc261a5.so (0x7f38f8e00000) libc.so => /lib/ld-musl-x86_64.so.1 (0x7f3903800000) Error loading shared library libgcc_s.so.1: No such file or directory (needed by /home/wmoore/.rustup/toolchains/stable-x86_64-unknown-linux-musl/bin/../lib/librustc_driver-d2bfe141fc706ea1.so) ⋮ </code></pre> That's not a huge issue as the latest stable Rust compiler is in the repos (although rustfmt</a> is notably absent</del> rustfmt was added</a> the day I wrote this post). Also since CLion</a> is running in a Flatpak sandbox it can't see the system Rust compiler anyway. The CLion sandbox is a glibc environment so installing rustup into it works fine. Other Issues</h2> It hasn't been 100% smooth sailing. Some other small issues and bugs I've ran into: My screen brightness resets to max brightness each time I reboot.</li> I noticed that the ImageMagick tools were broken and was able to submit a fix</a>.</li> There was a typo in one of the bluetoothd files</a> preventing the daemon from starting, which I fixed.</li> As I was writing this post I noticed that timezones were not being output in some invocations of date(1)</code></a>, which was fixed</a> 24 hours after reporting it.</li> </ul> Conclusion</h2> So far my experience has actually been better than I expected. Since I installed it I have not rebooted back into Arch. This isn't the first time I've run a desktop musl system</a> and I was prepared to encounter incompatible software more often than I did. Flatpak really helps fill the gaps there. As the alpha announcement suggested, I have run into the odd bug here and there but for the most part the system is remarkably polished and stable. I plan to keep using it as the primary OS on my laptop, including its Framework 13 AMD</a> replacement that should arrive Q4 2023. It is currently my aim to use Chimera on my desktop computer at some point in future too. That probably won't be until after the beta phase is reached though. Comments</h2> Lobsters</a></li> Hacker News</a></li> </ul>

Void Linux (musl) on the Huawei MateBook X Pro wes@wezm.net (Wesley Moore) — Sun, 06 Oct 2019 10:06:01 +1100 I recently returned from a 3-week trip to Broome to escape the awful Melbourne weather. The first week I worked remotely and the latter two were holiday. A week before leaving I acquired a new laptop: a Huawei MateBook X Pro (2018). In the days before heading off I worked to set up the new machine into a state that would allow me to perform all my work duties. I wanted to take the new laptop as it is considerably lighter and smaller than the XPS 15 it's replacing. To make things even more interesting instead of going for my tried and true Arch Linux setup I wanted to try out Void Linux. Specifically the musl libc variant. This post describes the trial by fire that the laptop and Void Linux received on this trip. </a> Huawei MateBook X Pro (2018) running Void Linux (musl)</h4> </figcaption> </figure> My XPS 15</a> is two years old now. I was using it for work until recently but replaced it with a Ryzen 9 small form factor desktop PC</a>. Given my laptop use was now more casual and for when travelling I wanted something smaller and lighter. I did a bit of research and found the Huawei MateBook X Pro, specifically the 2018 model. There is a 2019 model but it has not been released in Australia. Seeing as it was last years model I was able to get it on sale for AU$2219, which compares quite favourably to the AU$3144 I paid for the XPS 15. The MateBook X Pro has a unibody all aluminium construction, 3K 3000×2000 HiDPI touchscreen display, Intel Core i7-8550U CPU (4 core, 8 thread), 16Gb RAM, 512Gb NVMe SSD, NVIDIA GeForce MX150 graphics, 4 speaker Dolby Atmos audio, and weighs around 1.33 kg (compared to the 2.06 kg XPS 15). It has 2 USB-C ports, 1 supporting Thunderbolt 3, 1 USB-A port (Apple take note) and a headphone jack. The laptop was delivered a week before heading off on the trip and it presented an opportunity to try out a new Linux distribution. I installed Void Linux</a> (musl libc</a> version) instead of my usual Arch Linux</a>. musl appeals to me because I'm Australian and a sucker for an underdog</a></del> it has a clean code base, permissive licensing, and is not a GNU project. Hardware Impressions</h2> The laptop comes packaged very nicely and includes a USB-C charger with detachable cable, and USB-C dongle with: USB-C, VGA (😳), HDMI, and USB-A ports. Some quick impressions: Build quality is excellent. Approaching if not matching Apple fit and finish.</li> Definitely superior to the XPS.</li> </ul> </li> Display is excellent. 3:2 aspect ratio is nice for reading and coding.</li> Trackpad is large, precise, and has an adequate button. I'd rate it 8/10 where I'd give the MacBook one 10/10 and the XPS 7/10.</li> The keyboard is great. Better feel than my old 2013 MacBook and XPS keyboards.</li> It's firm and fairly quiet but with a good amount of travel still.</li> Nothing like the newer MacBook butterfly keyboards.</li> It copies the dumb Apple arrow key layout, which is a shame.</li> </ul> </li> Dongle included in box with a good port selection is a nice touch.</li> The charger and cables feel well-made.</li> When charging there's a tiny white led on the side of the laptop that blinks while charging and goes constant when charged.</li> Audio is noticeably better than the XPS 15. It is very clear and precise, especially in the treble range. Having top and bottom speakers is a good feature.</li> </ul> </a> My Broome office</h4> </figcaption> </figure> Battery life was excellent even when working on Rust code and repeatedly recompiling. I estimate about 5 or 6 hours of battery life doing this. My typical workflow was to work on battery all morning, charge over lunch and then work all afternoon on battery, which worked fine. Even working in the warm ambient temperatures of Broome (~30℃) with computationally expensive workloads the fan, whilst active, remained fairly subdued. For whatever reason the fan is much more active when booted into Windows. Performance wise the XPS is definitely faster, especially when compiling code with multiple cores. This is mostly due to the base clock speed being about 1Ghz lower in the MateBook. UserBenchmark comparison of the two CPUs</a>. Incidentally I also discovered that video playback in Firefox is not GPU accelerated on Linux</a>. This results in over 100% (more than 1 core) CPU utilisation when watching HD videos on YouTube. Watching the same video in VLC with GPU accelerated video playback uses only about 20% CPU and the laptop runs a lot cooler. Linux support is great. Hardware that worked out of box: Wi-Fi</li> Audio</li> Graphics (integrated)</li> Trackpad</li> Battery level</li> Touch screen</li> Volume controls</li> Keyboard backlight</li> Brightness/backlight controls</li> Web cam</li> </ul> As other reviews noted the angle of the web cam is not great. Hiding the camera in a keyboard button is nice for ensuring it can't surreptitiously be used though. After I bought the laptop it was reported that Huawei would start shipping some MateBook models with Linux</a> in China. It's no real surprise then that the hardware is very well supported. Life in the Void</h2> My Void Linux musl experience has so far been quite smooth but is not without its compromises. Installation was quite hands on like Arch but there is at least an installer to help you with some tasks. I was able to set up my usual Awesome</a> desktop environment easily. Binary packages were available for most of my usual software. The main thing I did not manage to get working was properly was gnome-keyring</code>. On my other systems this acts as ssh and GPG agent and is automatically unlocked when I log in so I don't need to enter ssh or GPG key passwords all the time. When setting the machine up for work I also run into a GCC 9 bug</a> that another Void using coworker had hit. The bug prevents the Mercury compiler</a> from being able to be built. My coworker was able to downgrade to an older gcc. I had no such package on hand I resorted to using Podman</a> to do builds in a container. This worked fine for the duration of my remote work. The primary place where using a musl based distro becomes apparent is with pre-compiled binaries, often linked against glibc. In my case these were all proprietary software: CLion</a></li> BeyondCompare</a></li> Netflix</li> NVIDIA drivers, Bumblebee</a>, NVIDIA OpenCL</li> </ul> For Netflix I was able to reboot into Windows at the end of the day. Instead of CLion I just went back to using Neovim. For BeyondCompare, there isn't a great replacement, which is why I paid for a licence in the first place. For the odd merge conflict I needed to deal with I used Meld</a>. The lack of NVIDIA drivers is not much of an issue, in fact I used bbswitch</code> on the XPS to disable the discrete graphics. However, I thought I might start processing some photos from the trip in darktable</a> and it benefits greatly from OpenCL. In the end I deferred doing the photos until I got home and could use my Arch desktop. Over the course of the three weeks I ran into a handful of packages missing from the Void repos that are available in the Arch repos: shotgun</a></li> viu</a></li> CopyQ</a></li> Universal Ctags</a></li> PureScript</a></li> watchexec</a></li> Crystal</a></li> </ul> Being Rust tools I was readily able to cargo install</code> shotgun</code>, viu</code>, and watchexec</code> myself. I created a package for PureScript</a>, and Crystal</a>. I did not tackle CopyQ or Universal ctags. Closing Thoughts</h3> I like XBPS and the void-packages</code>/xbps-src</code> repo. Feels much like the FreeBSD ports tree except with bash instead of make and a familiar git based workflow. Void splits packages into the main package and -devel</code> ones like Debian. Having spent more than 2 years with Arch and FreeBSD that don't do this I find it quite annoying. I know there are some minor space savings to be had but I prefer to have the complete upstream package installed, so I don't have to remember to go install the -devel</code> version as well. So far I've enjoyed my time with the MateBook and Void Linux and plan to keep using it as the primary OS on this laptop. I can also highly recommend the MateBook as beautiful, well-built, Linux hardware. Update 09 Jul 2024: I sold this laptop in 2023. It ran Void for a while but in the end I ran Arch on it most of the time. Comments</h2> Lobsters</a></li> Reddit</a></li> Hacker News</a></li> </ul> Announcing Desktop Institute wes@wezm.net (Wesley Moore) — Sun, 23 Jun 2019 15:42:07 +1000 Since publishing, A Tiling Desktop Environment</a>, I've continued to think about the topic, absorb the comments I received, try out some of the suggestions, and poke around the code bases of some existing window managers and Wayland compositors. This weekend I set up a new website to document the thinking and research I've been doing. It's called Desktop Institute, and has a fun domain: desktop.institute</a>. Check it out for a more info on what I have planned as well as a roadmap for future posts. </a> </figure> A Tiling Desktop Environment wes@wezm.net (Wesley Moore) — Sun, 02 Jun 2019 09:48:31 +1000 I've been thinking about graphical shells recently. One of the great things about open source desktops1</a> is there is a plethora of choice when it comes to graphical shells. However they seem to fall into two camps: Full featured desktop environments that stick to the conventional stacking window metaphor.</li> Narrowly featured window manager based environments that include tools like tiling window managers often optimised for efficient keyboard use.</li> </ol> I am currently using the second of these through the Awesome window manager</a>. I'm really enjoying the keyboard centric operation, and almost never needing to manually position newly spawned windows. Each workspace (desktop) gets its own layout2</a>, which describes how windows are laid out. For example, my most commonly used layout has one master window that takes up half the screen then additional windows are stacked on the right half. The split between the two halves of the screen is easily adjusted with Super</kbd>﹢h</kbd> and Super</kbd>﹢l</kbd>. Layouts can be changed on the fly with Super</kbd>﹢space</kbd> to suit your work. Another aspect I enjoy about Awesome is its snappiness. This is largely due to the lack of animation. Switching workspaces is instant, without any unnecessary flourishes. It seems that the animations used in many graphical shells these days tend to reduce the perceived performance of the system. Look how fast this iPhone is when animations are disabled</a>. The drawback to window manager based environments is that you give up the cohesive, full featured nature of a desktop environment. For example, these are features of GNOME that I had to research, install, and configure after moving to Awesome (items in italic are ones I haven't actually taken the time to implement yet): Compositor</li> Volume and brightness status and control</li> Network status and control</li> SSH agent, GPG agent, polkit agent</li> Screenshot tools</li> Media controls</li> Notifications</li> HiDPI support Cursor sizing</li> </ul> </li> Automounting of external drives</li> Automatic multi-monitor support Desktop gracefully adapting to monitors being added and removed</li> </ul> </li> Screen locking</li> Power management Battery status</li> Low power warnings</li> </ul> </li> Clipboard preservation I.e. clipboard source can exit and you can still paste</li> </ul> </li> Color management</li> </ul> Even with many of these implemented the components don't always work as nicely as in GNOME. For example, my XPS 15 has a built-in 4K display and I connect it to an external 4K display at work. When dunst</a> shows a notification on the built-in display the text is sized wrong, when it shows on the external display it is correct, even though the displays are identical resolution. On the flip side Awesome has these things in its favour: Lower resource usage (mostly RAM)</li> Alternate window management layouts: Stacking</li> Tiling</li> Floating</li> Maximised</li> Full screen</li> And more</li> </ul> </li> Keyboard oriented</li> Keyboard bindings completely customisable</li> Better use of screen space I have no title bars on windows</li> Top bar is very short and can be instantly toggled with Super</kbd>﹢b</kbd></li> </ul> </li> </ul> So all this makes me wonder, where is the middle ground? Where is the desktop environment for professionals? Pro Desktop</h2> Mac OS is a popular choice for developers in some circles and has the cohesive full-featured experience that I mentioned above. I conducted an informal survey on Twitter</a> to try to see what things Mac users are adding to the system to make it work better for them: Hey Mac power users! I'm doing some research: What tools do you install to make the UI/graphical shell work better for you? Things that come to mind are: Alfred</a>, Divvy</a>, Spectacle</a>, FastScripts</a>, LaunchBar</a>, chunkwm</a>, that kind of thing. </blockquote> The responses almost all included one or more of these elements: Window management (often via the keyboard)</li> Keyboard remapping</li> Automation</li> Application launching</li> System stats</li> </ul> Some open source desktops have all these features but the ones that have them all seem to lack the polish and consistency of Mac OS, GNOME, or KDE and require a large investment in researching, installing, and configuring each desired feature. The ones that have the polish and consistency lack the customisation and keyboard control. So where does that leave me? I want a desktop environment like GNOME but with more control over window management and more keyboard control. Update 7 Apr 2024: System76 is building a new desktop environment for Linux called COSMIC</a>. It aims to replace their current GNOME based desktop and I think it is exactly what I am looking for: a complete desktop environment with tiling and keyboard control built-in. Perhaps there is room for something that takes the place of gnome-shell</a> in the typical GNOME desktop but built for this use case. gnome-shell</code> is built on mutter</a> and there are other desktop shells built on this too such as gala</a>, and Budgie</a>, so perhaps it would be possible to use mutter as the base window manager and compositor and build upon it. I've been considering starting such a project but before diving in decided to write this post and do some more research to help clarify my thoughts. Something for me to ponder. 🤔 Comments</h2> Lobsters</a></li> Reddit</a></li> Hacker News</a></li> </ul> Why don't you just…</h2> Inevitably some folks will be thinking, "why don't you just…". Below are a few of these that I've thought of already. I may add more as time goes on. Use KDE</h3> One possible option is using KDE</a> with an alternate window manager</a>. Although this does prevent you from using Wayland. I am fan of Wayland but not yet a user. I believe it is the future of the graphics stack on open source desktops and I think its architecture makes sense give the way computers are used today. My problem with KDE is the aesthetic. KDE and Qt really don't seem to align with me. That's not to say they're bad or even ugly, it's just not to my liking. I suppose as an ex-Mac user I feel more at home with GNOME/GTK. On the other hand it seems like someone familiar with Windows would feel more at home with KDE/Qt. Things like menus attached to windows, icons on buttons, icons on menu items, Application launcher menu ("Start" button), bottom task bar, and apply buttons in configuration dialogs all feel very foreign to my Mac using past. Sure some of these may be configurable but I'm not sure I'd ever feel at home. KDE neon: Icons on buttons, Apply button for configuration, task bar, Start-esque menu.</h4> </figcaption> </figure> KDE neon: Icons in menus.</h4> </figcaption> </figure> For comparison here is GNOME showing the the same things. I prefer that it is less busy and to be honest more like Mac OS in some ways. GNOME: No icons in menus, no task bar.</h4> </figcaption> </figure> GNOME: No Apply button in settings.</h4> </figcaption> </figure> Use Xfce</h3> It is possible to use an alternate window manager with Xfce</a>. However, while Xfce has made recent progress on HiDPI support it's still a mishmash of blurry icons, and tiny controls in places. Xubuntu 19.10 with 2x scaling: Blurry icons, tiny controls.</h4> </figcaption> </figure> Use the gTile GNOME extension</h3> gTile</a> is more of a manual window resizer. It allows you to position windows on a grid but it doesn't appear to have anything approaching Awesome's layouts. Stick with Awesome</h3> It's true that Awesome is working for me but it does feel a bit like I'm back in the dark ages needing to find and configure things that I've previously taken for granted. It is nice to build your own environment like this but the little imperfections like the dunst notifications mentioned above, or handling of external displays have me wanting more. ^1I'm referring to these as open source desktops and not Linux desktops since they work on other systems too, like BSDs</a>, and OpenIndiana</a>. </div> ^2My first Awesome</a> includes a litte information in the layouts. </div> Two Years on Linux wes@wezm.net (Wesley Moore) — Sun, 21 Apr 2019 08:00:00 +1000 This is the sixth post in my series on finding an alternative to Mac OS X</a>. The previous post in the series</a> recapped my first year away from Mac OS and my move to FreeBSD on my desktop computer. The search for the ideal desktop continues and my preferences evolve as I gain more experience. In this post I summarise where I'm at two years after switching away from Mac OS. This includes leaving FreeBSD on the desktop and switching from GNOME to Awesome. I'll cover the motivation, benefits, and drawbacks to giving up a complete desktop environment for a, "build your own", desktop. Embracing Awesome</h2> If I were to identify a general trend in my time away from Mac OS it would be one of gradual migration. Initially I was looking to replicate my Mac OS experience. I landed on elementary OS</a> as it shared many of the same values of Mac OS. Over time, I moved to vanilla GNOME and gradually dropped some of the tools I initially felt were essential, like Albert</a>, and Enpass</a>. Instead, I opted for built in functionality or command line tools. These gateway tools allowed me remain not too far outside my computing comfort zone. As time goes on though, I'm adopting more platform native options, like using the built in GNOME search instead of having a dedicated app for that like Albert. GNOME</a> was working pretty well for me and even got updated from 3.18 to 3.28 on FreeBSD (although it's remained there and the current version is now 3.32). Despite this, high resource usage, some conversations, blog posts and shift in workflow led me to reevaluate tiling window managers. I was using the terminal more than ever before. I've been comfortable in the terminal for a long time but I realised that I was using the tiling features of Tilix</a> and Neovim</a> a lot. I was also using the tiling feature of GNOME to show two apps side-by-side. 😢 Assuming this is https://t.co/DvCKWlHc2L</a> Is there a way to manually trigger/cause GC in gnome-shell (aside from Alt-F2 > restart)? pic.twitter.com/xUA0fubcp0</a>— Wesley Moore (@wezm) November 24, 2018</a></blockquote>

Comments</h2>

Lobsters</a></li>
Hacker News</a></li> </ul>

`Comments</h2>Lobsters</a></li> Reddit</a></li> Hacker News</a></li> </ul>`

Why don't you just…</h2>
Inevitably some folks will be thinking, "why don't you just…". Below are a few of these that I've thought of already. I may add more as time goes on.</p>

GNOME: No Apply button in settings.</h4> </figcaption> </figure> </p>

Xubuntu 19.10 with 2x scaling: Blurry icons, tiny controls.</h4> </figcaption> </figure>

Use the gTile GNOME extension</h3>
gTile</a> is more of a manual window resizer. It allows you to position windows on a grid but it doesn't appear to have anything approaching Awesome's layouts.</p>

Bit Cannon wesonlinux

A Month on Chimera Linux

Chimera Linux on HP Aero 13 laptop</h4> </figcaption> </figure>
Note 07 Jul 2024:</strong> Keep in mind that this was written in July 2023 and the distro has continued to improve. So the following does accurately represent the current state of things.</p>

Void Linux (musl) on the Huawei MateBook X Pro

Announcing Desktop Institute

A Tiling Desktop Environment

Two Years on Linux

Bit Cannon wesonlinux

A Month on Chimera Linux

Chimera Linux on HP Aero 13 laptop</h4> </figcaption> </figure> Note 07 Jul 2024:</strong> Keep in mind that this was written in July 2023 and the distro has continued to improve. So the following does accurately represent the current state of things.</p>

What Works</h3> HiDPI (I run the display @2x)</li> Wi-Fi</li> Audio</li> Bluetooth headphones</li> Web cam</li> Brightness and volume controls on keyboard</li>

What Doesn't Work</h3> Fingerprint scanner — doesn't work in Arch either.</li> </ul>

What's Missing</h3> Some things that I tried to install but hit roadblocks. Not necessarily insurmountable ones, just ones I haven't taken the time to tackle yet.</p>

Other Issues</h2> It hasn't been 100% smooth sailing. Some other small issues and bugs I've ran into:</p> My screen brightness resets to max brightness each time I reboot.</li>

Void Linux (musl) on the Huawei MateBook X Pro

Announcing Desktop Institute

A Tiling Desktop Environment

Why don't you just…</h2> Inevitably some folks will be thinking, "why don't you just…". Below are a few of these that I've thought of already. I may add more as time goes on.</p>

KDE neon: Icons on buttons, Apply button for configuration, task bar, Start-esque menu.</h4> </figcaption> </figure>

KDE neon: Icons in menus.</h4> </figcaption> </figure> </p> For comparison here is GNOME showing the the same things. I prefer that it is less busy and to be honest more like Mac OS in some ways.</p>

GNOME: No Apply button in settings.</h4> </figcaption> </figure> </p>

Xubuntu 19.10 with 2x scaling: Blurry icons, tiny controls.</h4> </figcaption> </figure>

Two Years on Linux

Chimera Linux on HP Aero 13 laptop</h4> </figcaption> </figure>
Note 07 Jul 2024:</strong> Keep in mind that this was written in July 2023 and the distro has continued to improve. So the following does accurately represent the current state of things.</p>

Why don't you just…</h2>
Inevitably some folks will be thinking, "why don't you just…". Below are a few of these that I've thought of already. I may add more as time goes on.</p>