> Doesn't this require the environment to be owned by root? Doesn't it make more sense to leave things that are in /opt as root-owned anyway? (Or at least, change them back after running the installation as an unprivileged user.)

No, it doesn't require that, it just means your user-owned binary will be exec'd by root. But if you want the root -> user owned indirection, you can set `Exec=/etc/X11/xinit/Xsession`, which will exec your ~/.xsession as your user, and then you can keep a local install.

> Will any random greeter program just naturally pick up the contents of /usr/share/xsessions, then?

Ones that support x11 do, yes.

> So does it just ignore all your other dotfiles? Can I safely just try this out regardless of my usual WM/DE choices?

We try to read XDG_* things where relevant, e.g. themes and icons. But generally yes, once you point your xsession at qtile, we only use our config file.

Hi Mike. So far so good for me.

> It looks like you were able to figure things out through some combination of /proc poking, code inspection, and LKML querying. Out of curiosity, would it be feasible for you to have tried enabling some of the kernel hacking options such as WQ_WATCHDOG or DETECT_HUNG_TASK? Do you think that would have sped up your investigation?

We do have these both enabled, and have alerts to log them in the fleet. I have found it very useful for saying "there's a bug", but not generally applicable in debugging it. However, we wouldn't catch these things without user reports if we didn't have those tools.

Something that might (?) be useful is something like lockdep when there's hung tasks. It wouldn't have helped in this case, since it was a bug in signals wakeup, but I e.g. in the xfs case I cited at the bottom maybe it would.

Oh, I see, you're suggesting exactly,

> (Another maybe-interesting thing would be to just delete that check.)

I agree.

I would argue they're all invalid if PF_EXITING is present. Maybe I should send a patch to WARN() and see how much I get yelled at.

> Shouldn't it wake up, even if in its in PF_EXITING, that would trigger as reassessment of the condition, and then the `__fatal_signal_pending` check would make it return -ERESTARTSYS.

No, because the signal doesn't get delivered by complete_signal(). wants_signal() returns false if PF_EXITING is set. (Another maybe-interesting thing would be to just delete that check.) Or am I misunderstanding you?

> Shouldn't it be "ShdPnd"

derp, fixed, thanks.

The crux of it is that once you've called exit_signals() from do_exit(), signals will not get delivered. So if you subsequently use the kernel's completions or other wait code, you will not get the signal from zap_pid_ns_processes(), so you don't know to wake up and exit.

There's a test case here if people want to play around: https://github.com/tych0/kernel-utils/tree/master/fuse2

[1]: https://github.com/linuxkit/linuxkit/blob/master/ADOPTERS.md

Maybe the guy is a bad dude, I don't have a horse in that race. But lots of trading strategies that have worked in the past are well known.

Yes, and if you contribute from an e-mail address that Greg K-H's scripts don't understand, you get an e-mail from him asking you to disclose your employer if you're willing.

Some companies mandate you contribute from your corporate address, and it is impossible to contribute from some corporate e-mail accounts, since they don't allow SMTP access for use with git send-email. For example, my understanding is that this is the reason for the linux.ibm.com subdomain, though someone at IBM can probably elaborate.

LWN's numbers are probably pretty close to accurate, as I think most people disclose. I haven't read TFA, but I guess Oracle is counting only commits to kernel/+fs/+net/ or something like that.

I guess landlock can't help you here since it is still mostly about filesystem access right now, but maybe someday? It looks like "minimal network access control" is on the long term roadmap: https://landlock.io/

https://youtu.be/r_8om4dsEmw

RIP Dan Spira, one of the faster guys in Denver at the time of his death: https://www.bicyclecolorado.org/join-us/donate/remembering-d...

Thanks to Bicycle Colorado's advocacy, perhaps I won't have drivers intentionally trying to side swipe me next time I ride through stop signs in a safe (and legal!) manner.

I don't know, I just hit breakage the other day. I have /usr/bin before /usr in my path (which is the default on Ubuntu at least); I have muscle memory to use dpkg -S `which $foo` to figure out which package a binary is, but that doesn't work if dpkg thinks the binary is in /bin (e.g. ping), since it'll ask dpkg who installed /usr/bin/ping, which is nobody.

It is small fiddly things like this all over people's packaging and personal scripts that break.

In larger programs, you're forking because you need to diverge the work that's going to be done and probably where it's going to be done (maybe you want to create a new pid ns, you need a separate mm because you're going to allocate a bunch, whatever). Maybe the argument is that programs should never do this? I don't buy that. Then there's a lot of string-slinging through exec().