I see, that is indeed frustrating.

> Once every Mac shipped with a Retina display, there was no need to retain that compromise, because you already get high resolution so you may as well get color accuracy too.

I believe that is Apple's position, and it may be valid for their own high-DPI displays. However, it overlooks the fact that most external monitors, especially typical office displays, are still far from retina pixel densities. Even on a relatively good 27" 4K panel, text on macOS looks noticably worse than on Windows or Linux. Then again, that's likely compounded by the lack of fractional scaling. Unless you're using a 5-6K external display, you aren't hitting 250+ PPI to get crisp text at all.

> I will note macOS still enables by default a feature called "stem darkening" (incorrectly called "font smoothing" in macOS Settings) that also looks fairly awful to my eye, and seems itself a legacy from the low-DPI days.

Yea, I've seen quite the range of stem darkening implementations. Skipping proper gamma-correct blending in many doesn't help.

The really annoying thing nowadays is renderers attempting to apply subpixel rendering to panels that aren't even RGB/BGR in the first place.

MacOS went the other direction and removed subpixel rendering entirely, which is partly why low DPI external displays tend to look worse there.

Each broker provides an interface with different strengths, and some are still scaling up as operations begin. And yes, most brokers support spatial queries (cone searches / RA-Dec filters), along with a host of other interesting parameters to filter by. You can check out the public Fink portal and API docs as an example (https://lsst.fink-portal.org, https://doc.lsst.fink-broker.org).

Rubin is still very early in survey operations, so only parts of the entire footprint have been observed so far. Depending on the region of interest, it may not have actually been observed yet (also, high quality difference image templates will take quite some time to build up). But it's very exciting to see how much data will be generated over the 10-year survey period, and once the observatory is running at full speed, the entire southern sky will be continuously re-imaged every three nights!

> Some popups, such as Search Everywhere and Recent Locations, may not be moved outside of the main frame.

and

> Some windows and dialogs, e.g. Project Structure and Alerts, may not be centered on the screen or keep their previous location. This is due to the window manager having total control over windows’ locations in Wayland, which it is not always possible to override on the application side.

Code that wasn't his to reject was NACKed, causing a large amount of uncertainty about how to proceed with drivers that use DMA, and around the R4L project in general. At the absolute least, this is plain intent to sabotage (but IMO it is clearly more than intent at this stage). The core of what you are saying is that this has/will have absolutely no impact on anything to do with future R4L progress. The explosion of discussions around this exact topic across various forums with abundant disagreement from maintainers and R4L folks running counter to that idea are irrelevant I guess.

I'm not even a "rust person" and nobody has said anything about "being on the right side of history" except you. If that's how you see this discussion then we're not going to get anywhere. I wish you well, and urge you to in future engage in good faith and consider that not everybody is some boogeyman "on the true path" evangelist.

1. deliberately destroy, damage, or *obstruct* (something), especially for political or military advantage.

2. to intentionally prevent the success of a plan or action.

Definitions from Oxford, Collins, and Cambridge all fit the bill. Even dictionary.com has "any undermining of a cause."

"You might not like my answer, but I will do everything I can do to stop this."

is not intent to sabotage (even if it might not be successful as Linus could pull in the patch anyway), then what possibly could be?

Pointing out the ridiculousness of comments like this and suggesting the R4L folks push forward while ignoring them doesn't scream toxicity. Refusing to compromise with the R4L devs and calling the additions a 'cancer' has expectedly caused a stir.

"The common ground is that I have absolutely no interest in helping to spread a multi-language code base. I absolutely support using Rust in new codebase, but I do not at all in Linux."