I feel uneasy about this after the xz story.

Great, the UX feature I probably hate the most in Jira, now on Github.

This was exactly my thought. It breaks every bit of intuition I have using a browser, and makes pages run even slower.

Every bit of intuition you have using a browser, really? You click a link, the current page changes, you click back, it goes away. You cmd/ctrl click it opens in a new window, you right click and select "open in new tab/window" and it opens in a new tab / window.

Now, when you click a link in GitHub, the current page doesnt change. I want to look at the linked issue on its own page. That doesn’t occur anymore.

The page i wanted to go to pops up in a small overlay on the right hand side. The body text and content that I wanted to view is in a new, weird location, with the old page still behind it in the normal spot. It’s very unintuitive.

Thankfully either the behavior has reverted or I’m no longer in the A/B test. I can’t get the popup to happen anymore for me. (edit, nvm, behavior varies depending on repo or something? it acts completely differently on different pages, sometimes links are normal and sometimes they open in a popup. extremely annoying)

Also it breaks copying links. If I want to link to an issue I copy the URL. But now there's two different issues open at the same time, which one am I linking to? Original? Popup? Both?

Right, not saying it's not annoying, but "every intuition about using a browser" is a bit over the top. A link can open a dialog, has been happening for decades.

And GitLab, too!

Recently I tried out Brompton Bike Hire in London for a week. Can recommend the bike, and the price is reasonable. The bikes are hired from automatic storage lockers, which makes sense as a concept. The app is atrocious though, and I had a lot of trouble returning the bike at the end of the week.

Did you pin the package's priority or just apt removed it?

I've not used Linux on the desktop for some years⁰ but as I move back this sort of thing is why I'm not considering Ubuntu². If I want to dig into settings like that to keep my preferences I might as well stick with Windows.

Yes, the control to be able to tweak the system to my liking is one of the attractions or Linux, but not when I have to in order to avoid behaviours that I don't want being reasserted.

[not that I expect nor particularly want Ubuntu to change, I just accept that I'm not part of its target audience and I'll be better served elsewhere - choice is a great thing!]

----

[0] heading back there now as Windows11 is not happening on my home machines¹, I feel that I shouldn't have let Windows10 happen, looking back.

[1] aside from the laptop that came with it that I'll keep there for Office and DayJob compatibility for a while.

[2] Currently running Debian³ on the other laptop, main desktop will likely go that way if it isn't decommissioned completely, and I use a dock with the laptops instead.

[3] As that is what I use server-side more often than not.

It can't be. It's the same confusion as "email address normalization" being wrong (for example when gmail ignores dots when mapping an address to an inbox).

It matters where the normalization happens, and server-side behavior is out-of-scope of these identifier RFCs.

I don't think it's incorrect for distinct paths to point to the same resource.

Of course you shouldn't assume that in a client. If you are implementing against an API don't deviate regarding // and trailing / from the API documentation.

Wait until you try http:/example.com and http://////example.com in your browser.

Your first example is a valid uri but not a valid http url, because it's missing a host part. Your second example is not a valid uri, as the spec requires that [scheme]:// is followed by a host indicator.

Neither has much to do with / normalization, which applies to the path part of a valid uri.

I believe host can be empty.

      host        = IP-literal / IPv4address / reg-name
      reg-name    = *( unreserved / pct-encoded / sub-delims )

https://www.rfc-editor.org/rfc/rfc3986#section-3.2.2

Of course, most software freely ignores RFCs when the end result "seems better".

Yes, the uri spec must allow the host part to be empty. That's easily shown by remembering that file:/// URIs are commonly preceded by three slashes, so the spec must allow for that. Not sure where the brain was going with that.

Still, it's not a valid http url. I looked up the current rfc for completeness sake: https://www.rfc-editor.org/rfc/rfc9110#section-4.2.1

> A sender MUST NOT generate an "http" URI with an empty host identifier. A recipient that processes such a URI reference MUST reject it as invalid.

And it really is an empty host component, as RFC3986 section 3.2 specifically says:

> The authority component is preceded by a double slash ("//") and is terminated by the next slash ("/"), question mark ("?"), or number sign ("#") character, or by the end of the URI.

So yes, collapsing all those ////// into two really is illegal according to the spec -- but then again, the specs are mostly about network communication, so machine-to-machine. I consider a browser's url bar parsing to be more in the UX domain than in the technical domain.

In both cases I get https://example.com/ in FF.

> The XOR trick is only cool in its undefined-behavior form:

> a^=b^=a^=b;

I believe this is defined in C++ since C++17, but still undefined in C.

What about email?

I am surprised I don't hear about vim/neovim/vscode plugin supply chaim attacks. Feels like a similarly lucrative target to language package managers.