MereInterest

> How?! After a process calls setsid(2), it becomes a leader of a new process group so it stops receiving signals from its former process group!

By limiting its usage to the period between fork and exec, so that the process calling setsid knows that the parent process is propagating signals to it.

So, my phrasing was inaccurate to the point of being entirely incorrect. I should have said that any process that calls `setsid` is responsible for ensuring that signals are being propagated. (And saved! Definitely didn't make a mistake on the internet and then play it like I was right all along.)

Clearly, the solution is to extend the `kill` syscall to accept the PID as a Gaussian integer, with both real and imaginary components. That way, we can preserve the current behavior of `kill(+123, sig)` and `kill(-123, sig)` as sending a signal to a single process or to a process group, respectively, and will then allow `kill(+123*i, sig)` as sending a signal to all processes that are either within a process group have a direct or indirect parent within that process group. I don't know what we'd use the negative imaginary numbers for, but I'm sure we could think of something.

If not for the uncatchable SIGKILL/SIGSTOP, I'd say that any process that calls `setsid` is responsible for ensuring signal propagation across the pgid. But since those are uncatchable, I tend to shrug and figure that I'll avoid setsid wherever possible.

There was a proposal at one point that would have had `unshare(NEW_CGROUP)` place the process into a child cgroup, rather than merely changing the name of the current cgroup. This would have meant that cgroups could actually be used for nested process management. Unfortunately, there's no guarantee that a process can ever make nested cgroups it wouldn't be sound for all supported resource constraints, so that proposal never went in. But that would have been nice to actually have nestable job management.

The only issue I’ve run into with Podman is that, like docker, I can’t have the container’s process be part of my shell’s foreground process group. For docker the daemon (either rootful or rootless) makes that inevitable, but podman has better rootless support, so I’d been hoping.

Unfortunately, there’s an unconditional setsid during podman’s container setup, which as far as I could tell exists so that the container can be detachable.

(This was all so that I could have the same job management with Ctrl-Z, SIGSTOP, SIGTSTP, fg, and bg, regardless of whether the process I’m running starts up a container. The only way I’ve found to have that is by handling chroot/unshare myself.)

It's an awful problem, and a pretty big gotcha for the ecosystem. For example, I worked on a tool that used `tool_name/random.py` for analysis of RNG usage. However, any command run within that directory would shadow the builtin `import random`. As a result, I couldn't run the `black` formatter from within that directory, because it would accidentally import the local `random.py`.

The solution is to update the python flags to include `-I`, so that python will run in an isolated mode.

<rant>

This is relates to my frustration with how PEP-668 was implemented. Python has long had a problem with accidental overwriting of system libraries. If you `sudo python -mpip install foo`, then that can interact very poorly with your distro's `sudo apt-get install python-foo`, since pip would add/remove files that were expected to be managed solely through `apt-get`.

But in adding a warning to prevent this, they also applied the same warning to `~/.local/pythonX.Y/site-packages`, which is where traditionally a user would install additional packages with `python -mpip --local foo`. The argument is that since this is part of the import path of `/usr/bin/python`, it belongs to the system's python installation, so installation to the user's site-packages should also be blocked. This is a sleight of hand that changes the goal of PEP-668 from "avoid conflicts in file ownership" to "ensure an isolated python environment for system tools".

If I were to accept their argument that /usr/bin/python's imports should only be affected by distro-managed installations, then I should also be prevented from making any `*.py` files anywhere. After all, if those were in the working directory, they would be imported. This is clearly ridiculous, and so I don't buy the argument that breaking user-level site-packages is justified in order to have an isolated system-level python.

The correct solution would be for distro-managed programs to use `#!/usr/bin/python -I` as their shebang instead of `#!/usr/bin/python`, so they would actually get an isolated environment. Instead, PEP-668 needlessly broke user-level site-packages, and didn't even solve the problem that it set out to do.

</rant>

My guess is that is because a TUI can’t give focus to the existing instance. When a GUI application realizes that an instance is already running, it can ask the windowing manager to unhide and focus the running instance.

For a TUI to do the same, it wouldn’t just need to find and focus the window, but would need to trace it through the myriad ways that a TUI can be displayed. I may run a TUI inside a docker container, as part of a tmux session, over ssh. If a TUI somehow managed to focus the existing instance through those layers of wrapping, I would be very surprised, disgusted, and impressed.

So I think it’s that the end goal of “redirect user to existing instance” is infeasible, so nobody bothers to enforce a single instance, since the rest of the steps aren’t possible.

And even worse when the full-disk encryption requires you to unlock the computer after every reboot. It's just enough that the entire installation needs to be attended, and prevents you from doing anything else in the meantime.

Meanwhile, on Linux, my emacs session has a longer uptime than Windows.

> I thought the unsafety couldn't "spread" like that in Rust.

The goal of a library is to provide the encapsulation such that the unsafety doesn't spread.

If undefined behavior occurs, the fault lies with whoever wrote `unsafe { ... }` in the body of a function. If I write "unsafe" in order to call an unsafe library function, and I don't meet the library function's pre-requisites, then it's my fault. If the library internally writes "unsafe" in order while providing a safe wrapper, and I never actually wrote `unsafe { ... }`. If neither I nor the library wrote `unsafe { ... }`, then it is the fault of the compiler.

Using "in safe Rust" means that `unsafe` doesn't occur either in the user code nor in the library. In this context, since we've heard how many uses of `unsafe { ... }` exist in the Bun rewrite, I'd read "in safe Rust" to mean "without calling any functions marked as unsafe".

> I think one of Markdown‘s biggest sins is how it handles line breaks. Single line breaks being discarded in the output guarantees that your nicely formatted text will look worse when rendered.

My experience has been the complete opposite. Markdown parsers that don’t discard single linebreaks (e.g. GitHub-flavored markdown) turn my nicely formatted text into a ragged mess of partially-filled lines. Or for narrow display widths, an alternating series of long and short lines.

Markdown parsers that correctly discard single linebreaks make sure that the source text (reflowed to fit a max number of characters per line) and the rendered text (reflowed to fit the display width per line) both look reasonable.

I run into this issue when building against different environments, each with a

1. A library depends on a system package. To test against the different versions of the system package, the library is compiled within a container.

2. To minimize the incremental rebuild time, the `build` directory is mounted into the build container. Even when using a different version of the system package, this allows re-use of system-independent portions of the build.

3. When switching to a build container with a different version of the system package, the mtime of the system package is that of its compilation, not that of the build container's initialization. Therefore, the library is erroneously considered up-to-date.

Because the mtime is the only field checked to see if the library is up to date, I need to choose between having larger disk footprint (separate `build` directory for each build container), slower builds (touch the system package on entering the container, forcing a rebuild), or less safe incremental builds (shared `build` directory, manually touch files when necessary).

I looked into it at one point, as I was disgusted by the unskippable advertisements when paying for an ad-free tier on one of the myriad streaming platforms. Apparently, they distinguish between "advertisements" for a product or service and "promotions" for themselves. I get why that would be a reasonable internal distinction, as the former would require sign-off from the business paying for the advertisement, while the latter would only need internal approval, but it's a pointless distinction after that.

I particularly love how they will periodically choose to only use the selected Bluetooth device for audio output, and will instead switch back to the builtin microphone. The builtin microphone may be in my pocket or across the room, and so the only indication I get is when the person on the other end of the line says that I’ve dropped off.

Nothing changes in the UI to indicate this, nor could I find any setting to change this. Sometimes swapping the audio away from the headset and back to it helps, but it it at best a temporary fix.