pulsartwin

Thank you for the amazing work! Do you have any publications or articles describing your findings and the process you developed for mapping the scientific data into perceptually meaningful colour images?

Rendering our observatory's images in true HDR is something I've been wanting to implement for some time (especially as HDR support on the web continues to improve), as there is so much more in the data than we typically get to see.

Sure, edited.

Maybe, or maybe not. But it will certainly kill the community they've built up, and squander a huge amount of goodwill. Why would anybody who's interested in supporting or using an independent browser (read: techies) choose one that nobody can contribute to? Not to mention how the sponsors might feel about this.

This seems quite misguided and is sad to see. They have every right to do this, but I was looking forward to continuing testing Ladybird as it improves and contributing in the future. I hope servo stays open to contributions, as it seems like it's all we have left.

Looking forward to the blog post. Do you plan to run both the Zig and Rust binaries side-by-side across a wide range of real applications (potentially shadowing in production) to weed out bugs?

At the very least, it's interesting to be a bystander observering as efforts like this progress. The first thing it makes me wonder is how comprehensive/high quality the test suite is to begin with. Not to cast aspersions, but even at 100% on all platforms I wonder how confident the Bun team would be in migrating.

> I imagine this behavior came from ClearType having been a special case, and therefore non-native widget toolkits getting explicitly programmed to render with it on Windows, forgetting that the user should be able to turn it off!!

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.

Hate seems a bit strong for an increase in perceived horizontal resolution on low DPI displays, but to each their own. That said, I'm not sure what you mean by it being impossible to turn off. On Windows you can just disable ClearType per monitor, and on Linux it's configurable either through your DE, fontconfig, or sometimes at the application level.

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

Yep, and if you're interested, Rubin doesn't send alerts directly to individuals. The alert stream alone (without full images) is enormous. There are a set of alert brokers who ingest, index, and add metadata before making the streams available in a consumable manner. You can find all the alert brokers here: https://rubinobservatory.org/for-scientists/data-products/al....

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!

That's not great, although at least a splash screen is purely cosmetic. More disappointing is that, even in 2026, the move to Wayland still comes with issues like this:

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

I'm glad there's finally some progress in that direction. If they actually implement subpixel RGB anti-aliasing, it would definitely be worth considering as an alternative. It's been surprising to see so many people praise Zed when its text rendering (of all things) has been in such a state for so long.

There is certainly a lot to be said for first-mover advantage, but TradeMe specifically (while still popular) is currently fighting a losing battle. Between rising listing fees, selling fees as a percentage of the product's value, and the influx of drop-shippers that flood categories with "local" products, its days are likely numbered. Personally, while 10 years ago everyone I knew was using it, I no longer know anybody that goes to TradeMe to sell everyday items. I'm not a fan of FB, but the fact that it's monetarily free to use makes all the difference for the average user.

If you don't think what Hellwig did obstructed the project, then I guess we fundamentally disagree. Again, the R4L folks could work around this by getting the code pulled in by Linus, but that doesn't stop the fact that a senior maintainer has made it explicit that they will do everything in their power to stop this.

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.

sabotage /ˈsabətɑː(d)ʒ/ verb

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

There are multiple comments that meet the exact definition of sabotage. If this:

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

I don't entirely disagree with some of your points, however, they are not what the recent discussion has been about. Plainly, a maintainer has unilaterally rejected the addition of rust code to assist with DMA and requested that code be duplicated in every driver (which also ignores the fact that the patch never added rust code to kernel/dma to begin with). It strikes many as strange that the experimental addition of rust-based drivers (greenlit by Linus orignally) has come to a head in this way:

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

This is a remarkably disappointing end to Hellwig's original NACK, yet entirely expected based on the recent treatment of R4L devs.

This is a great visualization. I wonder what techniques were used to create it as neither this article nor the original source seem to highlight them.

Looks like it was due to unsafe processing of custom emoji: https://github.com/LemmyNet/lemmy-ui/pull/1897