really enjoyed reading this and learning about <ruby>.

i thought it was the symbol for gradient?

edit: ah, the name of the symbol for the gradient operator is nabla

I went to a similar museum in Japan, in Arima Onsen. It was a fun, hidden gem.

This is incorrect, I am currently using both nanoKVM USB and PCI models today

Website says 'preorder'. Is it available or not then? Preorder usually means it is not ready. Where did you buy it?

it looks like you can order the cube one on amazon right now.

Ah ok thanks I will check it out.

Completely agree- the coverage of MUNI + BART is actually pretty good (with some notable exceptions) and in my experience (ymmv obviously) less stressful than driving and seeking parking.

Agreed. My personal hot take is that powershell is a great way to deal with json.

they are likely referring to autonomous vehicles, not public transit

I can't say I know exactly what that journalist had in mind, but my understanding is that he was referring to the fact that younger generations (in the geopolitical west) aren't that interested in cars and both the market and legislation are responding to this shift.

Your reticence to accept the term gaslighting clearly indicates you've never had to interact with MSFT support.

On the contrary, I have spent thousands of hours interacting with MSFT support.

What I'm getting at with my post is the dev teams support has to talk to, which they just forward along their responses verbatim.

A lot of MSFT support does suck. There are also some really amazing engineers in the support org.

I did my time in support early in my career (not at MSFT), and so I understand well it's extremely hard to hire good support engineers, and even harder to keep them. The skills they learn on the job makes them attractive to other parts of the org, and they get poached.

There is also an industry-wide tendency for developers to treat support as a bunch of knuckle-dragging idiots, but at the same time they don't arm them with detailed information on how stuff works.

> What I'm getting at with my post is the dev teams support has to talk to, which they just forward along their responses verbatim.

But the "support" that the end user sees is that combination, not two different teams (even if they know it's two or more different teams). The point is that the end user reached out for help and was told their own experiences weren't true. The fact that Dave had Doug actually tell them that is irrelevant.

I guess I see your point.

If we're going to call it gaslighting, then gaslighting is typical dev team behavior, which of course flows back down to support. It's a problem with Microsoft just like it is a problem for any other company which makes software.

I've never seen the same behavior from any other software supplier.

Almost every software company out there will jump into their customers complaints, and try to fix the issue even when the root cause is not on their software.

I can't say I've seen it with every vendor. Or even internal dev team I've been an internal customer of - but I've seen it around a lot.

You might be lucky in that you've worked at companies where you are a big enough customer they bend over backwards for you. For example: If you work for Wal-Mart, you probably get this less often. They are usually the biggest fish in whatever pond they are swimming in.

> I have similar pain with {} and []

in grade school I believe we were told those were "braces" and "brackets" respectively

a more modern, zero-trust solution like mTLS authentication

That makes sense, mTLS is great. Some services like Google Cloud SQL are really good about support for it. https://cloud.google.com/sql/docs/mysql/configure-ssl-instan...

It's not quite a zero-trust solution though due to the CA chain of trust.

mTLS is security at a different layer though than IP source whitelisting. I'd say that a lot of companies we spoke to would want both as a defense-in-depth measure. Even with mTLS, network whitelisting is relevant. If your certificate were to be exposed for instance, an attacker would still need to be able to forge a source IP address to start a connection.

If mTLS is combined with outbound connections, then IP source whitelisting is irrelevant; the external network cannot connect to your resources.

This (and more) is exactly what we (I work on it) built with open source OpenZiti, a zero trust networking platform. Bonus points, it includes SDKs so you can embed ZTN into the serverless function, a colleague demonstrated it with a Python workload on AWS - https://blog.openziti.io/my-intern-assignment-call-a-dark-we....

I'd put it in the zero-trust category if the server (or owner of the server, etc) is the issuer of the client certificate and the client uses that certificate to authenticate itself, but I'll admit this is a pedantic point that adds nothing of substance. The idea being that you trust your issuance of the certificate and the various things that can be asserted based on how it was issued (stored in TPM, etc), rather than any parameter that could be controlled by the remote party.