I am kinda giving them shit for when someone pointed out that they’re essentially storing PII completely unsecured and their response was “you should use app isolation anyway”. That is not a good security model.

Jumping Cubes is the kind of game that works really well on a PC and has super simple rules but is absolute hell in real life.

That game on the Risk board was fun, though. IIRC North America in particular tended to have those terrible chain reactions that just kept going and going.

Of course LISP machines didn’t crash the hardware market and make up 50 % of the entire economy. Other than that it’s, as Shirley Bassey put it, all just a little bit of history repeating.

The logic behind it is that a smartphone-bound passkey represents two factors of authentication: what you have (the phone) and who you are (the fingerprint used to unlock the phone’s passkey store).

Anything on a PC is easily copied and can only ever be safely assumed to represent one factor: what you know (the password to unlock your password manager). Thus the benefit of getting a two-factor authentication in one convenient step falls away.

Of course it’s still super annoying, especially if you don’t really trust your smartphone OS vendor and use a portable password manager already.

I also often see implementations where there’s a first step where you have to select how to log in. It’s an extra click but very clear (and usually one of the options is some form of SSO where that one click fully logs you in if you already have a session open).

My company uses Entra ID (or whatever they’ve renamed it to this week) and it’s a pretty common sight in our login flow. I think our SharePoint instance does it so it should be something MS does.

Of course it all depends on w how the company configures it.

Passkeys are supposed to be bound to one device and protected by that device’s OS’s secure enclave. If you have a second device you’re supposed to create a second passkey.

That’s why many sites will flat out refuse to let you create a passkey with a desktop browser since a PC-stored passkey doesn’t fit the security model.

It’s not like you can’t add a “Log in with your company’s SSO” button to the form. That works just fine and at least Microsoft does something like that.

Processor architectures maybe. They put Rust into Debian and it’s so bad that now e.g. amd64 is ruined forever for any OS and won’t see any new processors in the future. We’ll have to move to a different architecture. I didn’t watch the video since I treasure my brain cells too much but that’s what I choose to read into it.

(A more reasonable reading is that Debian now ships a kernel that includes Rust code and coincidentally has also dropped builds for several obscure architectures but I do not feel obliged to assume reason with a title and thumbnail like that.)

Pushing to prod without review and breaking the running application is a resume-generating event in many companies. In many others it’s not even possible because of programmatically enforced policies.

If your company’s response is not to prevent or dissuade it but to have other people work overtime to fix the mess then that’s a major management fail.

Try to educate your boss about best practices. This incident should give your arguments some more weight.

Deployment to prod should not be something a developer can do by themselves; a proper CI/CD system can be configured so that prod can only be deployed to by people with an appropriate role (product owners or lead devs if your company doesn’t have POs).

If you don’t have such a system, make it an explicit policy: Only Steve the lead dev (or someone specifically appointed by him while he’s absent) can push to prod; if anyone else does it they get invited to an uncomfortable meeting with Steve. If they do it again the meeting will be with HR.

But seriously, you should lobby for a proper CI/CD system (if none is present) and for the system to be configured so that a) you can’t merge to the main branch without a code review and b) deploying to prod only works from main and with explicit approval by a PO/lead dev. That should stop most of the shenanigans.

It definitely depends on the use case. I could accept this being abstracted out to facilitate mocking, for instance (although I’d recommend mocking at a higher level). But in general this wouldn’t pass review with me unless I get a good explanation for why it’s necessary.

Then they could add their own function in later stages. YAGNI exists for a reason.

Agreed. Oddly enough, my Meshtastic contacts are much farther away than my farthest MeshCore contacts but MeshCore seems to be much livelier.

It’s about PMMA sheeting (aka plexiglass), right?

Best I can do is mandatory Lumen and Nanite. You can get almost-stable 60 fps on a 5090 with DLSS Performance and 3x frame gen, which should be optimized enough for anyone.

My game will sell for 80 bucks, 150 if you want the edition with all the preorder-exclusive content.

There is an installable btrfs driver for Windows. No idea how trustworthy it is, though.

And yeah, accessing Steam games on an NTFS partition from Linux is a recipe for permission issues. Just don’t.

Except if they then have to run it on their machine and the setup instructions start with setting up a venv. I find that a lot of Python software in the ML realm makes no effort to isolate the end user from the complexities of the platform. At best you get a setup script that may or may not create a working venv without manual intervention, usually the latter. It might be more of a Torch issue than a Python one but it still means spending a lot of time messing with the Python environment to get things running.

This may color my perception but the parts of the Python ecosystem I get exposed to as an end user these days feel very hacky. (Not all of it is, though; I remember from my Gentoo days that Portage was rock solid.)

There still plenty of “this version of pytorch doesn’t run reliably with Python 3.12, please use 3.10”, though. It’s not all sunshine and roses.

See, I don’t have to worry about such details. I work in corporate software dev, which means that everything is an MSSQL database where most of the tables contain only an ID of a table-specific format and a JSON blob. Why use an ORM when you can badly reimplement NoSQL in a relational database instead?

If Microsoft had added an Android app runtime (even if it were slow), they would’ve had a much better argument for buying Windows phones. As it was, their sales pitch was “buy a phone with this new OS that doesn’t run any of your apps, from the guys who made WinCE” (Windows Phone) and “buy a phone with this new OS that looks exactly like the last OS but won’t run apps from that one or Android” (Windows 10 Phone).

By the time Win10P dropped, nobody expected Microsoft to actually commit to it (so the enthusiast crowd stayed away) and its app ecosystem was literally a decade behind the competition (so casual users wouldn’t touch it). And then Microsoft didn’t see sales and promptly canceled the whole thing.