Hacker News: mort96

New comment by mort96 in "Shipping JPEG XL in Chrome"

mort96 — Wed, 07 Oct 2026 18:54:51 +0000

However many decades you wait, libpng is not gonna add support for WebP

New comment by mort96 in "Shipping JPEG XL in Chrome"

mort96 — Wed, 07 Oct 2026 18:54:13 +0000

You don't need to bloat any menu. There's already a "Save image as..." context menu option which opens a save dialog. This dialog could have a way to select format.

I just tried it out now, using Waterfox on macOS 27. The save image dialog literally already has a Format dropdown. But I'm guessing it's just a weird part of some native dialog, it lets me select between "WebP Image" and "All Files". This kind of design could've been used to allow the user to save it as a different format than what it was served as.

New comment by mort96 in "Incident with Git Operations, Pull Requests and Actions – Resolved"

mort96 — Wed, 07 Oct 2026 16:29:05 +0000

I have to second this, GitLab CI is pretty good. I'll never be on board with infrastructure people's obsession with putting code in yaml but outside of that, the model makes much more sense to me.

A GitLab runner is a machine/VM which can get notified of a GitLab CI job, then run the job's container image (downloading it from GitLab's container registry if necessary), then run the code in the yaml file. You get to control your build environment.

It's so weird that GitHub Actions's model is "have one absolutely gigantic container image which contains everything any build could ever need, and if something's missing, the documented answer is to apt install it every run".

New comment by mort96 in "Incident with Git Operations, Pull Requests and Actions – Resolved"

mort96 — Wed, 07 Oct 2026 16:25:14 +0000

What... what parts of GitHub would you consider "critical parts of the service" if not git operations, pull requests and CI?

New comment by mort96 in "Shipping JPEG XL in Chrome"

mort96 — Wed, 07 Oct 2026 15:51:46 +0000

Really? The lossless comparisons I've seen has JXL winning over AVIF, do you have a link to the comparisons you've seen where AVIF wins in lossless?

New comment by mort96 in "Shipping JPEG XL in Chrome"

mort96 — Wed, 07 Oct 2026 15:46:11 +0000

Better and similar size:

    $ du -h $(which pv)
    116K     /usr/bin/pv

pv has a progress bar and nicer syntax. Next time you need to write an image, try:

    sudo pv -Yo /dev/blah /path/to/your/image.img

The -Y makes it sync after each write so that the progress bar represents actual progress instead of just how fast you can copy to kernel write buffers.

My life improved measurably after I contributed that '-o' flag to pv and it then made its way into all my systems through regular OS updates :)

New comment by mort96 in "Shipping JPEG XL in Chrome"

mort96 — Wed, 07 Oct 2026 15:42:31 +0000

Some people get mad at this reason for hating WebP, but it's so true. The main way in which most people's lives are affected by WebP is that images they download from the web no longer work.

New comment by mort96 in "Shipping JPEG XL in Chrome"

mort96 — Wed, 07 Oct 2026 15:41:31 +0000

And that was a pretty bad solution. Nobody wants to see "this web page doesn't display correctly because you're missing the bla bla plug-in".

New comment by mort96 in "Shipping JPEG XL in Chrome"

mort96 — Wed, 07 Oct 2026 15:35:49 +0000

Here's a benchmark over time of jxl-rs (Rust) vs libjxl (C++) across both memory usage and performance: https://jxl-rs-perf.lucaversari.it/. I'm inclined to trust that it's a decent benchmark since it's from Luca Versari, a key person in the original JPEG XL standardization effort and development of libjxl, and is now the main developer of jxl-rs.

Seems to be between a little and a lot faster in almost all of the tests.

New comment by mort96 in "A sustainable web career, for when all this blows over"

mort96 — Tue, 06 Oct 2026 21:18:39 +0000

"Everyone globally decide to stop improving and instead compete on costs" would be an example of the kind of change I'm talking about. I don't know if that will happen but it seems somewhat plausible.

It also seems plausible that it will take many years until hardware price/performance reaches a point where companies can provide models people deem acceptable at unsubsidized prices people deem acceptable. I don't know.

New comment by mort96 in "A sustainable web career, for when all this blows over"

mort96 — Tue, 06 Oct 2026 21:04:51 +0000

Well this "silver bullet" is paid for by VC money, for now. I don't know what happens after, but VCs aren't in the business of subsidising a service forever. We're in a very temporary point in the cycle and things will change, I just can't predict how.

New comment by mort96 in "JetBrains reported a net financial loss first time in its tracked history"

mort96 — Tue, 06 Oct 2026 13:49:29 +0000

I'm not a fan of VS Code myself, but everyone I know uses it (except for people I myself have influenced into using something else). It truly is a sort of default editor these days.

New comment by mort96 in "Mold Linker Version 3.0.0 Release – Rewritten in Rust"

mort96 — Mon, 05 Oct 2026 17:39:05 +0000

But we're just talking for bootstrapping Rust here.

New comment by mort96 in "Turn off Apple Intelligence on macOS 27 and get its disk space back"

mort96 — Mon, 05 Oct 2026 08:26:54 +0000

I imagine the calculation goes something like this:

* Benefit: Printers "Just Work", customers are pushed towards higher storage tiers where we have fantastically high margins

* Drawbacks: None

New comment by mort96 in "Turn off Apple Intelligence on macOS 27 and get its disk space back"

mort96 — Mon, 05 Oct 2026 08:21:41 +0000

You don't see why people would want to free up a bunch of disk space that's taken up by a feature they never use..? Are you sure? Have you seen Apple's storage upgrade pricing?

New comment by mort96 in "The Forgetful CPU (Linux on M4)"

mort96 — Sun, 04 Oct 2026 01:45:49 +0000

Documentation is not the same as a standard...

New comment by mort96 in "How to speed up the Rust compiler in September 2026"

mort96 — Fri, 02 Oct 2026 15:20:46 +0000

As they say, it's a damn TUI for a chat bot. 1.8 MLoC is like 50x what you'd expect from something like that. If you want to speed up compilation, reducing that absolutely insane bloat would be a good start

New comment by mort96 in "Git 3.0's upcoming SHA-256 default will be a costly mistake"

mort96 — Thu, 01 Oct 2026 23:37:58 +0000

We're discussing a hypothetical situation where SHA-1 gets even more broken. From my original comment in this thread (https://news.ycombinator.com/item?id=49924179#49925367):

> If I can forge commits with any SHA1 hash at will

We probably don't want to wait until there are practical pre-image attacks discovered to change away from SHA-1.

New comment by mort96 in "Git 3.0's upcoming SHA-256 default will be a costly mistake"

mort96 — Thu, 01 Oct 2026 21:55:16 +0000

For A), I don't understand what the point is? I never mentioned what Linus is confident about, I talked about what you can verify when you pull from my mirror. I could replace a commit from 2010 with a malicious one

For B), I would think this could work, but it's a completely different solution from what you proposed and what I responded to.

New comment by mort96 in "Git 3.0's upcoming SHA-256 default will be a costly mistake"

mort96 — Thu, 01 Oct 2026 20:04:59 +0000

The design of Git, as a Merkle tree, is meant to allow for use cases like this:

* I host a mirror of the Linux git repo.

* You download Linux from my mirror.

* You check out a commit, say fd179f8a05be3ccae366b9b96e176b51fbe54aab, which you know is a genuine commit through some out-of-band mechanism (mailing list, GitHub web interface, a line in a Nix file, whatever).

* You check whether the repository I gave you is legitimate or not by re-computing the hash of the commit which I claimed was fd179f8a05be3ccae366b9b96e176b51fbe54aab. If it comes out to be fd179f8a05be3ccae366b9b96e176b51fbe54aab, you know it's legitimate. If it doesn't, you know it's fake.

This is a completely normal use of Git. People download from mirrors all the time. People rely on commit hashes to identify a specific source tree. People trust that if whatever the mirror gave them hashes to the right value, it's genuine. That way, you don't have to trust the mirror.

If I can forge my own commits to have any hash I want, this whole model breaks down. I can replace some old commit in the repo with my own forged commit with the same hash, and when you download a copy of the Linux repo from my mirror, you'll receive a repo with malicious content, but it'll hash to the same fd179f8a05be3ccae366b9b96e176b51fbe54aab hash as a genuine repo would. This breaks the security model of Git.