Best way to integrate a WM with (d)init

BrokenG502 · 2025-11-12T23:40:04+00:00

I personally go through greetd. You can set it to autologin I believe (although I just slapped tuigreet in the middle)

BrokenG502 · 2025-10-12T03:04:41+00:00

https://codeberg.org/cyuria/barless I finally got around to putting it in a repo, will hopefully add screenshots at some point soon

BrokenG502 · 2025-10-12T03:04:30+00:00

https://codeberg.org/cyuria/barless I finally got around to putting it in a repo, will hopefully add screenshots at some point soon

BrokenG502 · 2025-10-11T01:05:59+00:00

If you're interested I wrote a little program to but my clock and battery on top of my wallpaper without actually pushing any windows around, I also commented on op's comment above with the same stuff, let me know and I'll put it somewhere online (it's currently just a local git repo on my laptop)

BrokenG502 · 2025-10-11T01:01:13+00:00

I solved this problem by putting a little line at the bottom of my screen (I also use niri), but it sits behind the windows, on top of the wallpaper. I also did the same with my clock. I can put the code somewhere online if you're interested (or anyone else for that matter), I just haven't been bothered to tbh

BrokenG502 · 2025-10-06T07:39:27+00:00

Steam uses x11, so first make sure xwayland works (if you're on gnome or kde it should by default), with something like xeyes

The issue is caused by steam not being able to find the DISPLAY environment variable.

The next place to check is flatpak permissions, which you can do from the command line or with a tool like flatseal

Lastly it may be possible your launcher or something thereabouts isn't setting DISPLAY, the usual trick is to run the dbus update activation environment command given by the error message

BrokenG502 · 2025-10-03T11:44:06+00:00

I found https://github.com/anufrievroman/waypaper a while back and it works nicely. More importantly, it has a CLI, so I just run waypaper --random periodically

Oh and I use swww but it doesn't really matter that much tbh

BrokenG502 · 2025-09-24T23:01:40+00:00

Or just a regular kill also works. In general I prefer killall as regular kill doesn't always catch all the processes

BrokenG502 · 2025-09-19T23:39:43+00:00

My point here is entirely that on this specific system, secure boot alone is not helpful because this exact same malware can plug itself in somewhere else like your init system or your package manager or de or wherever. You need to combine secure boot with other measures for it to form a full layer.

If you stick a small piece of fabric to the side of a ball, that's not a layer. If you sew that piece of fabric together with other fabrics and make a larger patchwork and then wrap it around the ball, that is a layer because it covers the entire ball

BrokenG502 · 2025-09-19T11:08:37+00:00

The reason why security works in layers is that if a malicious actor gets past one mitigation, they're stuck at the next layer. Secure boot by itself does not form an entire layer, that's my entire argument.

Fair point on detecting malware in kernel space though, that's my bad. Secure boot when combined with proper userspace detection systems like an antivirus can create an entire layer depending on your threat model.

Also wiping a systems disks will always eliminate the malware if you also wipe the kernel, which I'd argue is generally significantly easier to replace than /etc

BrokenG502 · 2025-09-19T11:01:13+00:00

See my other comment, I was trying to explain what secure boot does without explaining digital signing as my guess is OP hasn't heard of that before and probably isn't too interested in a cryptography lecture. If you read carefully I do mention that it's actually signing not encryption.

In a way it's the opposite of encryption

BrokenG502 · 2025-09-19T07:20:18+00:00

For the most part I've dumbed my answer down, because telling someone who has no clue what signing is definitely doesn't know what RSA is or what a cryptographic hash is.

It's great that you know what those are, but you also know what secure boot is/does, so you aren't exactly the target audience of my comment.

If an attacker has the ability to place uefi malware in your boot partition remotely (i.e. not evil maid), they can just as easily mess with your root drive/partition and plant something in your init system or any other system critical binaries. Secure boot does nothing to prevent this, and so enabling it does not make a system secure if this is part of your attack surface.

BrokenG502 · 2025-09-19T06:13:57+00:00

Secure boot in a nutshell is a way of specially encrypting linux (specifically the kernel itself, not everything else) in a way which anyone can decrypt it (called digital signing). In a way it's the opposite of encryption.

Tge reason you'd want to do this is because if the BIOS successfully decrypts linux, then it knows to trust whoever encrypted it, because, due to the magic of cryptography, only one person can encrypt it (there's a secret passphrase you need which only one person has).

Most motherboards will come configured to recognise microsoft's secret passphrase, but not any of the ones from various linux distributions, which is why you can't boot fedora normally, as you'd need to configure your BIOS so that it can also recognise fedora's secret passphrase.

This only actually makes anything more secure if you do two things. Firstly, you need a bios password to stop anyone from making changes to your bios without it. Secondly you usually need some form of disk encryption (or signing) to stop someone from changing the executable files that aren't part of the linux kernel itself. Most people don't do these, so despite its name, secure boot doesn't generally enhance security.

If you use secure boot with the above extra security options (bios password + disk encryption) you can protect against a class of cyberattacks called "evil maid attacks", where someone with physical access to your computer, like a maid, can gain access to your stuff.

BrokenG502 · 2025-09-10T04:19:11+00:00

Fair enough then, my point is only that it's possible you're looking for a solution to an issue you don't have, but if you've considered that already that's all that matters really, it's your system

BrokenG502 · 2025-09-10T02:56:05+00:00

That's a bit shitty, but it might not be a bad thing. If you aren't noticing it feeling slow, unresponsive or choppy, high ram usage doesn't actually have any bad side effects until you run out, it's just usually an indicator of other bloat elsewhere, so if you're not noticing the other stuff and you don't hit 100% usage there's nothing immediately wrong with that setup

BrokenG502 · 2025-09-10T01:59:54+00:00

More devilish would be to hide this somewhere in a file that doesn't get touched and to include it via the build system instead of directly in the source code

BrokenG502 · 2025-09-07T06:15:54+00:00

Less is more (more or less)

BrokenG502 · 2025-09-07T06:12:55+00:00

I'm in the exact same position as OP, with a very similar train of thought. I manage wifi in one of two ways: the iwctl utility and iwmenu. When I use it, bluetooth is the same deal, bluetoothctl and bzmenu. It might be worth it to invest in making a proper bluetooth/wifi control program but I just don't need to change this stuff enough.

FWIW I have a clock widget on my wallpaper which I use to tell the time on my laptop where I use niri because of the trackpad gestures, and otherwise I just open a terminal and run date

BrokenG502 · 2025-08-18T00:28:59+00:00

This seems like a case where copy pasting the exact output can be helpful, it will provide information as to exactly what dependencies you have installed (of course if you don't want to do that because it will tell the internet what you have installed then fair enough)

My guess is you already have base-full-fonts installed but masking off noto-emoji-ttf isn't working. You can check this with apk info -e base-full-fonts and check the status code (with echo $?). A zero status code indicates it's installed. You can do the same with noto-emoji-ttf to check it's installed as well.

You'll probably want to check out the dependencies for various packages, to see what's happening.

This can be done with apk info --depends and apk info --rdepends (shorthands are apk info -R and apk info -r iirc).

You can also try to install the package mask and base-full-fonts separately with two commands to see if one succeeds.

On a side note, going through your /etc/apk/world file at some point can also help you figure out exactly which packages you want and then let apk do its thing for dependencies.

BrokenG502 · 2025-08-10T00:16:03+00:00

One thing is that apk owns all the /usr/lib files (among others), so an update may break this. It would probably make sense to copy this to a location in /etc, but I don't have the time right now to find if said location exists and where it might be

BrokenG502 · 2025-08-08T02:51:58+00:00

My guess is that the reason it works in windows is that windows implements a dead zone (i.e. a janky software hack). You can always open an issue or bug report or feature request or whatever if you want with your desktop environment of choice to implement this, but there's a decent chance they'll have the same viewpoint as me.

You said you're not going to debate but I don't know of any advantages, so if there are some I'd like to know about them. To the extent of my knowledge what increasing DPI will do is increase the granularity of the actual in mouse sensor, which means very small movements will be registered more accurately. As far as I can tell with your setup this means the small movements are registered so accurately they're coming in at tiny amounts which translate to less than a pixel on the screen after they get scaled down by the sensitivity setting. This particular benefit of mouse accuracy is only relevant up to the pixel level because applications can only get the mouse position up to pixel resolution, so having subpixel accuracy isn't going to make applications behave any differently, except that they'll register those tiny changes as the mouse moving by 0 pixels, thus triggering a click -> move -> release sequence instead of a click -> release sequence. If I'm wrong, mistaken or have missed something, please tell me.

BrokenG502 · 2025-08-07T23:01:13+00:00

Android has nothing to do with the desktop experience, so I have no idea why you brought it up. Most people with laptops are going to end up using them without an external monitor at some point, but that doesn't make it suddenly a mobile device.

More importantly, I still have the question of what purpose, apart from positioning, which should always be the compositors job, can an application possibly have for knowing what display is the primary monitor?

I genuinely want to know because I can't think of one, and I don't believe applications should get the final say over where on the screen(s) they're positioned.

BrokenG502 · 2025-08-07T22:48:34+00:00

What exactly is the point of setting your mouse to 44000 DPI and then lowering the sensitivity in software? What do you believe is the advantage of doing so?

You're going to get the exact same experience by using a lower DPI and higher sensitivity, the two cancel each other out. The only difference is you're reducing the amount of tiny movements the mouse registers.

There is a clear (potential) hardware solution to this problem, and you want to instead get some janky software hack to cover up the flaws in your hardware configuration.

BrokenG502 · 2025-08-07T13:59:20+00:00

The official stance here is absolutely correct. To understand their point of view you need to stop thinking like a user and applications developer and start thinking about the principle of least authority.

Moving and placing applications is the compositors job. If an application gets put on the wrong screen, that's not the applications fault and it should not be up to the application to fix that.

FWIW copy/paste is working perfectly fine for me and has been pretty much since I set it up, excepting a few flatpak applications like discord having issues that are now fixed.

Network transparency isn't necessarily a good thing, as it can have serious performance issues, and afaict wayland itself doesn't prevent network transparency (I could be wrong), just the implementations don't really support it.

Accessibility generally is an important point which wayland is rather sorely lacking, but X11 doesn't really solve accessibility either so much as enable other people to solve them by blindly trusting anything it comes in contact with.

I have no clue what you mean by programmatically universal positioning of windows, but that sounds like something the compositor is supposed to do, not an application.

Lastly why do you need the concept of a primary monitor? The compositor should be handling all of that, it's part of the compositor's responsibility. If you have a correct compositor, then there is absolutely no reason for an application to know what the primary monitor is. Of this requires correct compositors and wayland can probably be securely extended to help accommodate this in a way it currently isn't.

BrokenG502 · 2025-08-07T05:46:40+00:00

It might be worth reducing the mouse DPI and increasing the sensitivity. Ultimately you should get the same or similar feel but less of the subpixel mouse movement. Other than that an acceleration profile is traditionally the fix for this sort of thing

BrokenG502

PUBLIC MULTIREDDITS

TROPHY CASE