Return to Level1Techs.com

Let's try Artix/s6/dwm

Ok, so I recently decided that, after nearly 3 years, I wanted to move my desktop linux machine from Solus to something more customizable with a more mainstream packaging system. Solus was a great choice for my first linux desktop, but budgie was getting buggy for me, and I increasingly wanted tiling. Plus I really hate typing eopkg.

My first choice was KDE Neon. My justification was:

  1. mainstream distro/packaging (Ubuntu/apt)
  2. kde is highly customizable
  3. tiling with krohnkite
  4. distro is maintained by the DE, so DE should be the solid and is more up to date than kubuntu

Long story short, KDE was breaking horribly after serious customization. Issues are difficult to troubleshoot. Lots of moving pieces, and difficult to decipher logs. Most recommendations online boiled down to, “take a snapshot before any configuring so that you can revert when everything inevitably breaks”. Anyway, kwin and the compositor were crashing multiple times a day, usually when the system was idle. I restarted my config from scratch multiple times. This was not going to work for me. The only thing that drew me to kde in the first place was that I could customize it. Many many hours wasted.

So I ragequit KDE Neon… and Ubuntu, although the latter is probably collateral damage.

Turned off by the whole experience, I gave into @SgtAwesomesauce’s initial advice to try arch, however, after refreshing myself on Luke Smith videos (the natural thing to do when considering arch), I have decided to step even further outside of my comfort zone and try Artix with s6, which is a fork of arch without systemd. Additionally I will try dwm. Depending on how I feel about dwm, I may use Awesome instead. I guess it will come down to whether I like configuring in C or Lua. I do have some very distant C experience. Never typed a single character of Lua.

Anyway, the first thing I am going to do is merge a lot of discussion about this that happened elsewhere, so consider the immediately following posts to be the long version of what I’ve described here. After that I will just post my progress and notes on the process. Whether or not I will ultimately use any of this is not certain, but I think the time spent working through it will be a more valuable learning experience than re-doing KDE gui config over and over.

1 Like

@SgtAwesomesauce you pitched me on Manjaro (right?), do you use KDE as your daily driver? I am having so many issues with it… it is utterly unusable. It seems like it’s fine for a few hours or a day and then I log in and everything is completely fucked. I cannot use this thing.

Do you think Manjaro would be dramatically more stable? I figured, Neon is a distro made by the DE, so it must be the best experience, but my experience in Neon has felt like a pre-alpha. It’s fucking terrible. I can’t believe how bad it is.

No. I don’t use KDE anymore, found it too unstable. (and I like bash scripting normal distro features too much)

I’m using i3 or sway, depending on the machine.

I think that debian based distros have major problems with desktop uptime. One of the reasons I nuked my Ubuntu Desktop.

I’m having zero stability issues with Manjaro or Arch that don’t come down to thunderbolt limitations in the kernel right now. On the laptop that I don’t use thunderbolt on, I’ve got a 28 day uptime.

It’s honestly more of a showcase of what “proper KDE” should look like, and I don’t think it’s designed to actually be installed.


1 Like

BTW, my latest bash monstrosity:

#!/bin/bash
# Script to automatically adjust wanted display configuration based on presence of Thunderbolt dock and lid state


THUNDERBOLT_DEVICE="0043a888-4074-1300-ffff-ffffffffffff"
NO_DOCK="~/.screenlayout/int.sh"
DOCK_LID_OPEN="~/.screenlayout/dock-38-int.sh"
DOCK_LID_CLOSED="~/.screenlayout/dock-38.sh"


function configure_workspaces {
    i3-msg [workspace="1"] "move workspace to output DP1-2"
    i3-msg [workspace="2"] "move workspace to output DP1-2"
    i3-msg [workspace="3"] "move workspace to output DP1-2"
    i3-msg [workspace="4"] "move workspace to output DP1-2"
    i3-msg [workspace="5"] "move workspace to output DP1-2"
    i3-msg [workspace="6"] "move workspace to output DP1-2"
    i3-msg [workspace="7"] "move workspace to output DP1-2"
    i3-msg [workspace="8"] "move workspace to output eDP1"
    i3-msg [workspace="9"] "move workspace to output eDP1"
    i3-msg [workspace="10"] "move workspace to output eDP1"

}

function check_ws {


    LID_STATE=$(cat /proc/acpi/button/lid/LID0/state | cut -d' ' -f7)
    THUNDERBOLT_CONNECTED_UUIDS=$(boltctl | grep -B3 status:\ .\*authorized | awk ' { if ($2 == "uuid:") { print $3; exit } } ')
    echo $THUNDERBOLT_CONNECTED_UUIDS

    if [[ $THUNDERBOLT_DEVICE == $THUNDERBOLT_CONNECTED_UUIDS ]] ; then
        if [[ $LID_STATE == "closed" ]] ; then
            echo "lid closed, TB connected."
            exec $DOCK_LID_CLOSED
            echo $DOCK_LID_CLOSED > ~/.screenlayout/.chosen
        else
            echo "lid opened, TB connected."
            exec $DOCK_LID_OPEN
            echo $DOCK_LID_OPEN > ~/.screenlayout/.chosen
            configure_workspaces
        fi
    else
        echo "TB disconnected"
        exec $NO_DOCK
        echo $NO_DOCK > ~/.screenlayout/.chosen
    fi
}

check_ws

nitrogen --restore
echo cmd:restart > /tmp/polybar_mqueue.$(pgrep polybar)

I’ve got a udev rule designed to watch PCI events and run this script on a timer latch. (if the script has been called in the last 10 seconds, ignore)

3 Likes

Got it. I am considering this because most of my work can happen in a tiling wm (gimp, etc have terrible issues with these though). Are you running these on top of KDE or something else. As they are only WM, there must be a DE underneath no?

No DE underneath. Just xorg for i3, wayland for sway.

With i3, you can set windows to “float” This will eliminate the issues inherent with Gimp.

1 Like

And that’s in Manjaro? or just arch?

I’m mostly using just arch, but Manjaro is arch with an install wizard and a slightly slower TTL on package updates.

One of my 3 laptops has Manjaro on it, for cross-testing purposes.

Oh, and manjaro has a few custom things, but I don’t really use them. Kernel version management is a bit better, etc…

1 Like

What would you recommend for ease of use. I am knowledgeable but want to set something up once and never think about it again. And I want the desktop uptime to only be determined by the need to restart for new kernels.

Check out Manjaro i3.

It’s got really sane OOTB configuration, but I dislike the color scheme (can be changed, but it’s work)

If you don’t like urxvt, you’ll want to switch to something like st. no, I’m serious, use st, it’s great. I’ll give you my build if you don’t want to mess with patching source code.

Additionally, they use the default i3bar, which I find to be ugly, so something like polybar goes a long way to making it have the comfy feel like a “full fat” desktop does, but with a tiling wm.

So Manjaro is a fun one. I’ve found it optimal to pacman -Syu at least once a week, but you can absolutely hold off for a couple weeks. New kernels come out usually 2-12 days after a patch release comes out from Linus. I don’t think Manjaro has live patching, so if you’re concerned about uptime, that’s a downside, but I think live patching is basically only available through subscription stuff. (inb4 dynamic tells me oracle provides it free now)

So, what it comes down to is this: You can absolutely custom tailor your system to your needs. You can absolutely have great uptime on an arch-based distro. You can absolutely have a very stable environment. You can absolutely have whatever you want on arch.

You just need to put in the work to do it yourself.

Want to close a window with super+alt+F7? Sure thing. bindsym away!

Want to rebind your brightness control? Sure thing.

Want Firefox to always open on workspace 3? Done.

Want to save and restore a layout so you don’t have to super+v, super+h, super+w, etc… for 30 seconds? Sure thing, that’s doable.

Basically, Arch/Manjaro gives you a solid base to build the environment you want.


Let me fix up my dotfiles repo and I’ll give you a link so you can explore the configs.

2 Likes

I am so profoundly disappointed in KDE because I was able to configure something that I am really really happy with but ultimately cannot use, because the uptime is so ridiculously poor.

2 Likes

I suspect you might be frustrated, not with KDE, but with Neon.

2 Likes

Dotfiles:

lol nope

Feel free to dig through them, I’m tracking everything with yadm, which seems to be working just fine.


Note about my keymap modifications: If you’re not used to this, you will have a bad time.

What it does is make the repeat mode start much faster, and repeat at a faster rate. It also changes caps lock to super, and sets it so that tapping super is actually escape, but when held down as a combination (ex: Super+D for dmenu), it’s actually just super.

I also changed left control to be ~ because it helps my vim workflow.

lol nope

For screen layout selection, I have a script that pipes ls ~/.screenlayout into dmenu, so I can select multiple screen layout shell scripts that were generated with arandr. that’s super+F8. Super+Shift+F8 gives you something special. This is my prototype auto-detecting layout selector. I have 3 potential screen configurations; internal laptop, external 38in, or both. Depending on lid state and thunderbolt dock presence, I need to change em. (that’s the script I pasted above)

You can manually run it that way, but i’ve also got udev triggers for it. Just doesn’t always work 100%.

lol nope

2 Likes

You’re drunk, go home.

Tbh, I am so close to just running a full suckless stack on CentOS 8 Stream. The whole point is that you compile it from scratch so why not? And the way I was using Command Output panel widget is essentially how you’re supposed to use dmenu.

I would actually be surprised if KDE performed better in arch for me. The issues I have seen appear to be entirely within KDE and do not relate to larger system issues.

This is absolutely fine with me as long as it’s only once. If I have to relearn the wheel every time I have to update or troubleshoot this or that, then no.

That said, I might just go full Luke Smith and suckless everywhere!

If you’re using i3 on X11 with no DE, what are you using to login? Do you have a tutorial or something I can look at, because it was my understanding that you needed some sort of DE to scaffold for the WM.

Yeah, basically.

I’ve been using dmenu for a lot of cool stuff lately.

This is why you track your dotfiles with git. You can see your history, and you can build the environment you like/need.

And you can migrate bits and pieces to other machines with PRs. :stuck_out_tongue:

It’s important to know that a Desktop Environment and a Display Manager are two different things.

Desktop Environment is something like Gnome, KDE, XFCE…

Display Manager is GDM, SDDM, LightDM, etc…

Display Manager is what you log in with. You don’t need one for a minimal install, but you absolutely can have one. LightDM is always a good choice in that case…

tail -n5 .zprofile
[ ! -f ${XDG_CONFIG_HOME:-$HOME/.config}/shortcutrc ] && shortcuts > /dev/null 2>&1 &

[ "$(tty)" = "/dev/tty1" ] && ! ps -e | grep -qw Xorg && exec startx

You use the standard console login. ZSH is my shell, so .zprofile gets executed on login. This oneliner checks if I’m logging into TTY1 and if so, it starts x. and in ~/.xinitrc, you simply place exec i3 to get i3 up and running.

2 Likes

I managed to break Manjaro i3 install. It probably wasn’t anything huge, but I just couldn’t update the system. Just didn’t have the time or energy to start digging around so instead I installed Ubuntu back, and rolled with AwesomeWM, which is what I’m currently using.

But I did like Manjaro overall, I just wasn’t sure if rolling release is for me after all.

I might just go and try regular Arch next.

You will need a display manager, aka login manager. Something like LightDM, SDDM, etc.

1 Like

No you don’t. :troll:

.${SHELL:1:1}profile scripts are plenty.

2 Likes

So. This is how you learn. If you run into package conflicts on Arch like that, it’s 99.9% of the time a situation where there’s a PSA about manual intervention needed.

Pacman is a very simple package manager and so it doesn’t have the “migration” type features Apt or Yum have.

That’s why I’ve got Arch’s news/updates RSS feed in newsboat. If I run into a problem, the first thing I do is check there.

1 Like

Nerd

/s

Legit didn’t know you can do it that way too. Have to look into that.

post bookmarked

1 Like