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.
The problem with feature tests is that you then rely on the test code being correct. A typo in the feature test can erroneously be interpreted as lack of that feature.
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.
> 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".
The trick is that you make it something that humans want to do. Using [0] as an example, the interactive elements move, with context-dependent environment interactions.
At least cargo places everything in a .cargo directory, so it doesn’t display by default. Go will instead write to $HOME/go, without even the decency to use a hidden directory, unless you first define the GOPATH environment variable.
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.
> 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.
> Emacs is not primarily a TUI program (although it does have a TUI with the -nw). The TUI version of emacs lacks visual customizability and introduces unnecessary overhead (terminal!). Use the GUI.
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.
> Making these extra stops causes the bus to 'miss' the light cycle at almost every stop.
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.
> Oh man. The infinite loops of impossible verification by large companies that should know better are massive pain peeve of mine.
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.
> There are always weird systems with old drivers (looking at Ubuntu 22 LTS)
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.
Google will lock you out of an account even if you remember your password. This happened to me, when Google decided to use the recovery email address for 2FA, locking me out of my primary account. And the exact same change was made to my recovery account, at the same time. As for the recovery email of my recovery emails address, it was with a company that hadn't existed for over a decade, and no longer existed.
I'll admit that I've done that type of bugfix in the past. Though, usually it's because the bug is caused by an underlying design flaw, and the 10-line fix would have only papered over a single instance of the bug, and wouldn't actually solve the underlying cause.
Last time I needed to install Windows 11, avoiding making a Microsoft account required (1) opening a command line to run `oobe/bypassnro`, and (2) skipping past the wifi config screen. While these are quick steps, neither of those are at all "easy", since they require a user to first know that it is an option in the first place.
And newer builds of Windows 11 are removing these methods, to force use of a Microsoft account. [0]
In Rust, this can almost be expressed as `arg: &'static str` to accept a reference to a string whose lifetime never ends. I say “almost” because this allows both string literals and references to static (but dynamically generated) string.
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.
There’s a difference between the owner having telemetry on their own car, and the manufacturer having telemetry on the cars they’ve sold. One is taking care of your assets, and the other is spying on customers.
> Why are you assuming that a human would be more efficient and better for the environment than an electrically powered robot?
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.
Meanwhile, on Linux, my emacs session has a longer uptime than Windows.