Bill Gates is a monopoly capitalist with zero scruples. He screwed over so many people, vacuumed up so much wealth from all other sectors of the world economy. He has zero qualms about doing this either: There’s video of his depositions in the anti-trust case against Microsoft, and the whole fucking time he just argues semantics in response to the questions, and when pressed after five minutes of defining every fucking word in a sentence, almost always claims he doesn’t know or recall. Obviously a guy that thinks being as dishonest as it is possible to get away with is perfectly good business. And he does that despite whatever the outcome of the case, he’d be richer than billions of humans collectively. What pathology is this?

There’s so much more shit, like the incessant lobbying for medical patents worldwide, or how, according to Melinda, Gates loved hanging out with Epstein.

Now, why would anyone want to have their picture taken with that guy? Torvalds is such an unprincipled lib.

Edit: Listened to some of the deposition in the background. Here Gates is being extremely annoying for example: The interviewer reads back an email from Gates saying something like “browser share is a very, very important goal for this company”, and then asks what other companies he’s comparing browser share with. Gates goes several minutes arguing he’s not talking about any other companies, since literally there are no other companies mentioned in that very sentence, obviously pretending like he doesn’t understand the question. If you listen to all the shit before, they have to go over whether “browser share” means “market share” (Gates says no), whether “very, very important” and “important” have different meanings (Gates says not necessarily, could be hyperbole), and that sort of stuff for minutes on end. Like seriously listen to this, I cannot even describe how stupid it is.

Yeah that stuff I myself got rid of back in the Gnome 1 days when you could still customize all that. I appreciate that the Gnome devs came to the same conclusions as me.

• Desktop icons are usually hidden behind windows. It makes more sense to put launch icons in front of everything else, like Gnome does when you hit the Win/Super key.
• Minimize is unnecessary when you have workspaces and efficient window switching methods. Same for the task bar.
• A long time ago, when I was young, I played around with themes and shit, when that was still supported. There were always problems. Theming any complex set of applications yourself is basically impossible without causing issues, and themes made by others also exhibited this problem. You need a concerted long-term effort, plus buy-in from basically all app development teams, to make a comprehensive theme. Note how Microsoft/Apple don’t want to support theming either.
• Systray was always some excuse for apps to just keep running in the background while not taking up taskbar space. Steam can go fuck itself, just please exit when I ask you to, and don’t treat the close button as “minimize”. If I wanted Steam running in the background I would just put it on another workspace.

I have this working on Debian like how you have it set up, everything on an encrypted lvm volume, except for boot and efi. Just one disk though. When waking up, it asks for the password like it does during normal bootup. It then restores RAM from the encrypted swap after you type the password. I think it worked out of the box, but it has been a while, so not 100% sure if I had to enable this somehow. Anyway this looks good to me.

If you manually run systemctl hibernate, does that work? Assuming this also does not work, you need to look at the logs during the failed hibernate attempt. Probably something like sudo journalctl -f and/or sudo dmesg -wH (for kernel logs). Open this up in two terminals, run systemctl hibernate and observe any errors or warnings.

It’s possible this is a hardware/driver issue, i.e. a driver prevents hibernation or fails at it. You may be able to figure out which driver/device is responsible by looking at the logs.

Interesting, thanks.

The tokens can be worth different amounts. There can be 1 ¢ tokens, 10 ¢ tokens, 1 € euro tokens, 10 € tokens, whatever. Your wallet app will, when withdrawing, generate various tokens worth different amounts.

Using those tokens will be somewhat like paying in cash at a store that does not return any change. You gotta pay the exact amount. In order to facilitate that, you’d withdraw tokens worth only small amounts. There wouldn’t be like be any 50 € tokens in practice. If you wanted to withdraw 50 €, you’d get 1000 1 ¢ tokens, 100 10 ¢ tokens, and the rest 1 € tokens or something like that, to make sure you always have the exact amount ready to pay for anything.

I looked at this a looong time ago, but the basic idea is that the tokens (equivalent to cash coins/banknotes) are generated on the end user’s device, through some public-key cryptographic back-and-forth protocol. The issuer (bank/central bank/payment provider) does not see these tokens (they’re only on the end users device), but can verify that they’re legit (i.e. issued by them) somehow.

You can take one of these tokens to them, and deposit it in an account. They won’t know who it’s from but they know it was legitimately issued by them. Depositing a token is also supposed to be the only way of figuring out if it is a legit token, the bank will not tell you if a token is legit unless you deposit it.

When someone pays with these tokens in a shop, the shop will want to immediately (during checkout) deposit them, to make sure they’re legit, and also to make sure the token hasn’t been double spent. A shop that doesn’t do that makes itself vulnerable to fraud. This means shops will have a hard time hiding their revenue (to dodge taxes) compared to cash.

If someone you trust gives you a token (birthday money from your grandma, say), you don’t have to immediately deposit said token, since presumably you trust your grandma to not give you fake or double-spent tokens. Since you trust you grandma, there is no need to deposit the token and involve the bank, and that transfer would be untraceable (it’s literally just copying a number from her phone to yours).

The idea is that shop owners would have a hard time dodging taxes without opening themselves up to fraudsters using fake tokens, while the customer cannot be identified. You’d also be able to exchange tokens with family and friends in a way that isn’t traceable, as long as you trust them to not screw you over.

Ok so it’s not the uinput permissions.

When you use lightdm, do you use it to log into a Gnome wayland session, same as with GDM? Or is there any other difference between using GDM and LightDM? What exactly is/isn’t working, and how can you tell it is related to the XTEST extension?

Also I can use the PS5 controller as a mouse just fine.

Ok, this could maybe be the kernel driver creating a “real” touchpad device. Steam is able to create fake/virtual mouse and keyboard devices, I suspect that’s what steam uses XTEST and/or uinput for. So even though your PS5 touchpad works, that does not invalidate my theory that steam wants XTEST for mouse/keyboard input fakery, because that’s what exactly what XTEST is for.

So technically, Steam wouldn’t require XTEST for controller input, it would require XTEST to map controller inputs to fake mouse or keyboard inputs. I don’t know what exactly steam does if XTEST isn’t present, like what exactly doesn’t work?

And XTEST is an X11 protocol extension, it probably doesn’t work properly under Wayland anyway.

The null here is concerning to me.

Dunno, ‘(null)’ might just refer to the default connection (or server or screen or whatever X11 object this refers to), so not sure if this something to be concerned about. I presume X11 clients in general do work? Like xterm or xeyes work, right?

I am having the same bug as in here :/

The fact that you cannot log in may seem/look like that exact issue you linked to, but that’s from 2019 and may have a different cause. In general, GDM will start some executable, (i.e. gnome-session or something like that, or at least it used to be gnome-session, haven’t used gnome in a while) which if it exits/crashes this will kick you back to GDM. It could crash for many reasons.

You should check the logs for sure for both issues. X11 session logs (relating to Gnome X11 not starting), should be in ~/.xsession-errors (or ~/.xsession-errors.old for the previous session, I think). There may be a /var/log/Xorg.0.log for xorg, which I guess could also be the thing crashing (maybe). There may be other things logged with journald that could be relevant. journalctl --user should show all the logs for the user session. Logs from Gnome, since it runs as your user, would presumably show up there. My guess is all the relevant logs for a Gnome wayland session would also be there, as well as (hopefully) Xwayland errors/warnings, since Xwayland is actually the thing that would report it doesn’t support XTEST.

Note that journalctl likes to show the oldest logs first, so look at the timestamps. You can press G to scroll to the end. There are various ways to filter messages, look at journalctl --help. You might want to use --grep to look for anything related to XTEST or xwayland.

Lightdm and GDM are systemd units (systemctl list-units), the logs would show with something like sudo journalctl -u lightdm.

Interesting. I will say I suspect still this is to make the controller act as a mouse or keyboard somehow, which steam can do.

One interesting thing is that it says in the bug report, that steam also requires uinput, which is used to create virtual input devices from userspace. And maybe (speculating) you need that for XTEST to work on wayland or something, or maybe steam can use uinput instead of XTEST if it’s not available.

Or maybe it’s security-related somehow (Regular programs being able to create virtual keyboards is kind of a security issue).

For me the output of getfacl /dev/uinput will list my username with read/write permissions. I have no idea what is responsible for giving me this permission but there it is.

Can you check with getfacl in both sessions?

I have never heard about this, can you link to your source for this? Also what’s the symptom here exactly?

AFAIK steam and games directly use the kernel devices for controller input, not any X11 extensions.

Edit: Wait!? Do you want to use the controller as keyboard + mouse? Inside of GDM? Because that might use XTEST after reading about it, since XTEST seems to be some kind of testing protocol that allows one to emulate a mouse.

Oh, you’re talking about Windows 10 specifically then? I took it you meant generally.

KDE has looked and mostly (yay workspaces!) worked like Windows since the first version. I remember I was there.

KDE was started in 1996 and the first release was in 1998. Windows 95 was released in (surprise!) 1995.

Yeah no problem. This is a bug inside swhkd.

My guess is, swhkd is setuid root so it can open /dev/input/event* files, which are the keyboard devices.

These days, sway (or any other wayland compositor) gets access to keyboard events by talking to logind (or elogind or seatd if you don’t have systemd). But logind, I think, will only allow one program (e.g. sway) access to keyboard events at a time, so as not to allow keyloggers to be implemented.

This is also why sway used to support running setuid root, because that way it can access the devices without logind.

I think what swhkd does is:

1. Gets started as root by the kernel because of setuid bit and root ownership of the binary.
2. Opens /dev/input/event* files to read keyboard events. This is presumably what it wants root for.
3. Waits for keyboard events by reading the open file descriptor(s). When it finds one of the configured shortcuts, it calls fork(2) (to duplicate itself) followed by setuid(2) (in the forked process) to drop privileges and run as a normal user, and then execve(2) to execute your command.

The problem is that it messes up somewhere and doesn’t set the correct group membership. It would probably need to call initgroups(3) to correct this, I think.

I will also say, because that page says this is perfectly safe, that maybe the author(s) don’t know what they’re talking about, because frankly the fact you were a member of the root group, even though your user isn’t supposed to be, is already concerning and a minor privilege escalation. Setuid root binaries were an endless source of privilege escalation vulnerabilities in the past.

But then again, a typical sudo-enabled setup is already like you’re an admin user, so you’re already pretty much f-ed if your user account gets compromised. So whatever I guess.

You may want to report this bug to them.

Yeah so this does not confirm my hunch, and I don’t think sway is changing your group membership. Version 1.9 does not allow sway to be installed setuid root, and it isn’t, as confirmed by the ls output.

So it must be something else. It could be anything between the login shell in the console and the shell started with the messed up groups. What’s weird is that in order to change group membership, you would need root permissions (technically you only need CAP_SETGID, but why would you have that?). I think there are really only two ways to do that: Run a binary that has the setuid bit (like e.g. sudo) or CAP_SETGID, or talk to some process (e.g. a daemon like systemd) that is already running as root, and ask it to do that for you.

I cannot imagine why anything between the login shell -> sway -> ??? -> zsh would be either setuid root, or have any reason or permission to change groups in any way. So that’s really weird and interesting.

How do you open the shell inside sway? Keyboard binding from sway config? Launcher? Which terminal? Do any of the involved programs have setuid root bit set (looks like rws instead of x in ls -l output)?

About zsh: I mean I guess in theory one could change groups in the zsh configuration if you had the permissions (which you shouldn’t have), but I cannot think of any reasonable explanation why anybody would want do that.

Can you provide output of which sway, sway --version, file $(which sway) and ls -l $(which sway)?

Also, can you run id, after logging in w/o gdm on the console, and then again after starting sway?

The fact that your group membership changes even when starting sway from a tty, as mentioned in some other comment, is super weird. I believe newer versions of sway should not mess with this.

AFAIK some versions ago, sway used to be (or at least could be) a setuid root binary (something something needed root privileges for some reason to do with h/w access), but no longer. Back then it looks like it did mess with group membership etc.

I have this hunch, that maybe your binary has the setgid bit set for some reason (due to, perhaps, an oversight made by the packager, because in the old package that was needed).

OK I’m convinced, that’s apparently how that works. I wonder why it’s designed that way.

Edit: OK, I looked at the docs, and they sure do make a broken symlink there. I still think it’s worth a try to create a non-broken link, maybe the docs are wrong. I would expect they would put a little note there, that yes, you really do want to create a broken symlink (if so, why not a regular file?), but then again its kernel docs and those aren’t the most friendly.

I also thought you were OP for some reason, sorry.

Edit2: If you look at the file listing later in the docs, you can see this:

./configs/c.1/ncm.usb0 -> ../../../../usb_gadget/g1/functions/ncm.usb0

Which does look like a real non-broken symlink, so I maintain the docs are wrong and you’re not supposed to make a broken symlink.

Original comment, silightly edited:

You misunderstand. I suspect OP cannot create the symlink, because it would be a broken symlink, not because the symlink is relative. Maybe you cannot create broken symlinks in the sysfs for some reason.

I was just trying to explain that a relative symlink is relative to the directory in which it resides. The target to the symlink should point to ../../functions/uvc.usb0 if you want it to point to something that exists. The ln command in OP’s listing would result in a broken symlink, since the specified path is not relative to the c.1 directory. It is relative to the working directory, but that’s wrong, that’s not what ln expects you to put there.

Maybe it needs to be a correct symlink, maybe that will solve the problem.

Do you mean you intend to create a broken symlink?

IDK how all that works but I will say that the result of this would (in a normal filesystem) create a link named configs/c.1/uvc.usb0 yes, but that link would point to functions/uvc.usb0 relative to its own dir. This doesn’t exist and your symlink would be broken, presumably the special file system there doesn’t like that.

Edit: Apparently that’s not the problem and you’re totally supposed to run an ln command that should logically result in a broken symlink, thanks to kernel driver sysfs abuse.

Yeah no problem. I’d like to point out that this puts a hole in your firewall. If you have something exposed via udp, and an attacker knows about your --sport rule or figures this out, they can connect to it just by setting their source port to 5353. You can check what’s listening on udp with ss -lun or sudo ss -lunp (for process info).

Also, I have looked up what @[email protected] said about dig not supporting mdns and I think they are correct. With mdns, because of the multicast nature, you can get replies from multiple computers, and that’s a pretty big difference to regular dns. How could it even reliably know it has gotten all the replies or if it should wait for more? It just sort of happens to work correctly if you get a single reply.

Also, and I also looked this up, mdns lookups will to go through avahi-daemon on regular glibc distros. The libnss-mdns plugin description for glibc says this:

nss-mdns tries to contact a running avahi-daemon for resolving host names and addresses and making use of its superior record cacheing. If Avahi is not available at lookup time, the lookups will fail.

As I said, I’m not sure about that.

Still, dig won’t be listening on port 5353 for the answer, it’ll open some random port, so the firewall rule for 5353 will not apply. And the conntrack rule, is my guess, also doesn’t apply, because what I think the conntrack module does is:

• Remembers about the outgoing connection (i.e. when dig sends its udp packet out): source port, destination IP and port
• Check incoming packets against this info, and lets them through if they appear to be an answer

Since the outgoing packet is going to multicast, and the incoming packet (I suspect) is coming from the IP of the machine that answers (a different IP therefore), conntrack wouldn’t be able to figure that out. The answer doesn’t match the outgoing packet that dig sends. Since this is just a hunch, I would try to confirm this by looking at the traffic in e.g. wireshark.