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

[0] https://news.ycombinator.com/item?id=48254291

One step of the 2024 supply-chain attack on xz utils was to disable a security feature by introducing a feature test with an intentional typo. Even knowing that this commit[0] contains an intentional typo, I had to re-read the diff a few times to actually find it.

[0] https://git.tukaani.org/?p=xz.git;a=commitdiff;h=a100f9111c8...

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".

[0] https://www.cs.unm.edu/~dlchao/papers/p152-chao.pdf

And if you install more than one version of go, they get placed in $HOME/sdk [0]. Last I checked, this path is hard-coded with no override, despite this being a known issue for 8 years.

[0] https://github.com/golang/go/issues/26520

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.

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).

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.

Can you elaborate on this? I tend to use emacs exclusively in the terminal, since I'm often using them on remote workstations. For remote workstations, I can (a) open files using TRAMP, (b) open a remote GUI with X11 forwarding over SSH, or (c) open a remote TUI. TRAMP doesn't always play nicely with LSP servers, and remote TUIs are much, much more responsive than X11 forwarding.

Locally, the performance of emacs depends far more on the packages I load than on the GUI vs TUI, so I'm interested in hearing what overhead there would be.

This would be a much bigger change, but it's also possible for the lights to give priority to buses. When a bus approaches a light, that should trigger the lights to advance to the part of the cycle that gives the bus the green light. That way, you prioritize the 20 people in the bus rather than the 10 people each in their own car.

I got hit by this from google.

1. Gmail added requirement for 2FA on my primary email address. Since I had no phone number on file, it instead used my recovery email address. Thankfully, I still had the password for my recovery email address, and could continue to (2).

2. Gmail added requirement for 2FA on my recovery email address. Since I had no phone number on file, it instead used by recovery's recovery email address. Thankfully, I still had the password for my recovery's recovery email address, and could continue to (3).

3. SBC Communications no longer exists, as it merged with AT&T in 2005. Email addresses at `sbcglobal.net` were maintained up until around 2021-ish, when they started purging any mailboxes that had been idle for more than 12 months.

Fundamentally, this was google's fault for misusing a recovery email for 2FA. Unfortunately, the only way to fix it would be to contact AT&T, asking them to pretty please update the email settings for somebody who hadn't been a paying customer for two decades.

While I agree with your general point, RHEL stands out way, way more to me. Ubuntu 22.04 and RHEL 9 were both released in 2022. Where Ubuntu 22.04 has general support until mid-2027 and security support until mid-2032, RHEL 9 has "production" support through mid-2032 and extended support until mid-2034.

Wikipedia sources for ubuntu[0] and RHEL [1]:

[0] https://en.wikipedia.org/wiki/Ubuntu#Releases

[1] https://upload.wikimedia.org/wikipedia/en/timeline/fcppf7prx...

And newer builds of Windows 11 are removing these methods, to force use of a Microsoft account. [0]

[0] https://www.windowslatest.com/2025/10/07/microsoft-confirms-...

For Rust’s macros, a literal can be expressed as `$arg:lit`. This does allow other literals as well, such as int or float literals, but typically the generated code would only work for a string literal.

Because bicycles use 5x less energy per mile than electric scooters, which would be a reasonable analogue for slow electric delivery robots [0].

> It is very inefficient (approx 25%) to use food as an energy source,

By comparison, fossil fuel conversions are about 30-45%, depending on the energy source [1].

> and humans are always burning energy. They can't turn off at night or when they are idle. I think it is very likely that the robot would be better for the environment than the person.

That's a really, really weird baseline to use. Turning off a robot when not performing a task is standard procedure. Turning off a human when not performing a task is not standard procedure, and is frowned upon in polite society.

[0] https://www.statista.com/chart/28710/energy-efficiency-of-mo...

[1] https://www.eia.gov/electricity/annual/html/epa_08_01.html (Smaller numbers are better. To find efficiency, divide 3412 (1 kilowatt*hour in Btu) by the value in the column [2].)

[2] https://www.eia.gov/tools/faqs/faq.php?id=107&t=3