Ugh this sounds like when I worked at Oracle/OCI. Some environments required a VPN, some a jumpbox, and some required logging into a virtual desktop, and then logging into a jumpbox. Just thinking about it gives me PTSD

any sufficiently large organization that is around for a decade or two trends towards spaghetti-access

Yup, same boat here (mid-size company).

All the corporate stuff is behind Okta, so that easy enough.

But all the dev/test systems are a mix of SSO, individual logins, etc. At least they're all behind the same VPN (except when they aren't, but that's less common).

And of course, if you're a cloud engineer (vs "normal" software engineer), you also have to deal with AWS access, which is a whole different can of worms.

And yet, somehow AWS managed to get this right-ish. They evolved, learned by making mistakes, and created de-facto standards (like object storage protocol) on the way, while at the same time supporting decades-old services. And I'm sure they'll withstand the current AI craze.

AWS had the benefit of not trying to retrofit IaaS on top of a (already bad) PaaS.

Does Google have good SSO internally? Or Facebook?

(excluding things like administration of organization-wide infrastructure key material)

So the problem is the team size, not culture?

I used jemalloc recently for ComfyUI/Wan and it’s literally magic. I’m surprised it doesn’t come that way by default.

Allocators like that aren't the default for every process because they have higher startup costs. They are targeted to server workloads where startup cost doesn't matter, but it matters a lot if you're doing crud like starting millions of short-lived processes.

I don't think glibc malloc makes an optimal set of tradeoffs for any scenario.

This poster is an obvious LLM lol

Yep. em-dashes everywhere.

This sounds like some kind of learned risk aversion, like they don’t want to assume the responsibility of altering whats already there.

Yep the menu is handy for ssh tunneling. Maybe not a lot of people doing that these days though with stuff like dev tunnels and Tailscale.

I typically just create a "new" connection in a separate tab when I want to add tunneling.

I put new in quotes because I use another little-known feature, "ControlMaster". Multiplexes multiple connections into one, it makes making " new" sessions instant (can also be configured to persist a bit after disconnecting). Also useful for tab-completing remote paths. It does not prompt for authentication again, though. And it's a bit annoying when the connection hands (can be solved with ssh -o close, IIRC).

> I use another little-known feature, "ControlMaster". Multiplexes multiple connections into one, it makes making " new" sessions instant

Is this what secureCRT used as well? I remember this being all the rage back when I used windows, and it allowed this spawn new session by reusing the main one.

I'm using that as well but had issues with tunneling where it creates the tunnel in the background and terminates and so you might not know the random port it assigned or I couldn't figure out how to un-tunnel it and tunnel again to the same port. Just bypassed the control master then.

TIL; thanks, that's interesting (and somehow escaped my 20+ years of using ssh)! As usual the gold is in the comments :-)

I use it all the time with https://tuns.sh that let's you expose localhost to the public.

Tesla???

This is never happening, the Ultra needs a giant copper heatsink.

Ditch the Aluminium and go with a copper MacBook Pro. Or silver. If you get it with a terabyte of RAM, the silver shell will be a small part of the total costs.

Argentium 960 would most likely be the best alloy for the job, as it’s a good heat conductor and doesn’t tarnish like pure silver.

GeekBench being questionable aside, these results have me stoked to see what an M5 Ultra looks like performance-wise!

IDK if you're the author but yt-dlp can easily be installed with Homebrew. Manually downloading the interpreter etc is quite the rigmarole.

yes especially because homebrew will also setup deno for you, which is required for youtube itself.

And installing Homebrew also installs the developer tools, which would have take care of the Python problem.

They added iOS-esque stuff a long time ago in Lion/Mavericks like “App Nap” and “automatic termination” so it kinda has this, but it’s inconsistent.