Why would you need to dynamically change the temperature?

Because the things you have in the fridge change. The opening and closing of the doors change. The actual equipment changes. Store hours change. Holidays happen. Sports games happen. Weather happens.

To be honest, a grocery store is one of the most dynamic systems I can think of.

Edit: A bang-bang thermostat is not an appropriate solution for a grocery store.

That's called a thermostat and doesn't require remote control. The frozen food needs to be at the correct temperature all the time, regardless of external factors.

> Because the things you have in the fridge change.

Are the contents of the fridge also being adjusted via remote management tools?

On iOS devices you can import/export Passkeys between supporting password manager apps (including Apple Passwords).

In my experience, migrating between Apple Passwords and Bitwarden worked without issues, in both directions.

Wasn’t part of the point of the last article that some of the various methods we call “passkeys” aren’t portable?

Generally, if you want to restrict the user to use a particular authenticator, you need to own that authenticator. At that point you can have the attestation you are looking for. If you want Yubikey policy and behavior, you're gonna have to get your user a Yubikey.

The passkey provider vendors are motivated to serve their customer's needs (the end users, and secondarily enterprise deployments) over non-customer needs.

So Apple platform support (for example) will only send an attestation when one is configured via MDM. Your provisioned work device can indicate to work systems that it is in policy.

The compatibility-limiting risk, if it exists, is more likely from regulators putting their hands on the scale and pushing for security policies that would prevent synchronization and backup, and requiring attestations to make sure those policies are in effect.

Most "Passkey" branded approaches are portable. The "not portable" subset of Passkeys is primarily backwards compatibility with things like Yubikeys. That's also what attestation is mostly for, backwards compatibility with applications and Enterprises that still need "this is specifically the physical Yubikey I mailed this user" type keys, not as much Passkeys.

I'm not saying it's impossible, I'm saying there's a barrier that's useful to further vendor lock in. My mom is going to use Apple passwords on her iPhone. When she needs a new phone, the complexity of import/export and fear of losing access to her accounts is going to push her to buying another iPhone. It's just another avenue of lock in, like existing OS level password managers, just with an extra level of confusion for the end user.

My dad didn't like iCloud Passwords because he still uses a Windows laptop and only recently has the iCloud Passwords app been good or all that useful. We settled on 1Password a few years ago and having 1Password on his phone and setup as his default password app means that iOS uses it as the default Passkey app as well. "It just works."

The vendors could use it to enhance lock in, but for the most part the vendors all seem in agreement that the rising tide safety to float all boats of Passkeys is worth investing in making them friendly, especially to non-technical users, and to some extent try to avoid direct lock-in.

But can you use Apple Password app on an Android device?

Strava is an example of a website that's dog slow on Safari. Pages take 10+ seconds before they start rendering.

Interestingly gmail suddenly started loading dog slow in Safari for me. I'm on an older version of Safari so that could be a factor - so bizarre though. I wouldn't put it past them to be doing that deliberately.

Firefox on iOS doesn't support extensions at all.

You can use it without understanding, but this won't help you actually understand how it behaves.

I believe I can understand how a library behaves from the README and docs. I do this all the time. We all do.

You haven't run into cases where the documentation is missing or incomplete? You must be dealing with different libraries than I am.

Of course. And then we fix the problem. It's no different here. The point is that reading the code first is absolutely not a requirement when adopting a new library.

It is not. But there’s an element of trust being involved. Something like libflac or libcurl, I don’t read the code. I read the doc which does outline the behavior of each function and the conceptual model. If something break, it’s quite often my code. Why? because their code is battle tested. Which is quite different from AI generated code.

That's because it's new. libflac and libcurl didn't come out as battle tested code. That takes time and...battles. And what are those battles if not people seeing issues with what those libraries are doing and fixing the code? There absolutely no reason that AI written code can't or won't become battle tested.

> There absolutely no reason that AI written code can't or won't become battle tested.

I can think of 2:

1. Low trust: I'm not going to trust some rando's AI-generated code/PR when I can make my own AI generated code. Maintainer will (rightly) not trust my awesome AI-generated PR because I'm a rando to them.

2. Fragmentation, if a lot of people are doing (1), they wont contribute to the same upstream codebase like they would in the past, which means each codebase only runs through a small subset of potential environments.

The interplay between 1 & 2 will result in a lot of siloed code, with no accounting for taste (i.e. sensibilities developed by maintainers)

Low trust is not a reason that code can’t be battle tested. All non battle tested code starts as low trust by default. AI written or otherwise. I’m not even sure what you mean by fragmentation tbh. This feels like a very vague argument in general.

But you’re right that it’s the hill climb of human trust that AI is going through right now. Some of us are just farther along than others. Some of us refuse to consider trusting AI out of fear, and not rational evaluation of its capability.

The battle tested part is the reason I suspect my code rather than theirs first. The trust part is in their engineering process. New project from OpenBSD or Debian, I’m ready to try. Random guy on Github, bring out the 10 foot pole.

You can’t say a new project is battle tested. Those are mutually exclusive, regardless of who or what wrote the code.

Rob Pike seems to dislike syntax highlighting:

> Syntax highlighting is juvenile. When I was a child, I was taught arithmetic using colored rods (http://en.wikipedia.org/wiki/Cuisenaire_rods). I grew up and today I use monochromatic numerals.

https://groups.google.com/g/golang-nuts/c/hJHCAaiL0so/m/kG3B...

He is definitely not alone in thinking this, for example (but for different reasons): https://www.linusakesson.net/programming/syntaxhighlighting/

Rob Pike doesn't disclose that he has color blindness when he says he doesn't see the value in syntax highlighting. Classy.

Wow, that second link does exactly what I do when I'm talking to people about skittle highlighting; demonstrating a skittle highlighted snippet of prose to show how absolutely harmful it is. I only started doing that maybe three years ago, so they've got me beat by 15 years or so! Glad I'm not alone on this crusade, at least. It is genuinely my belief that skittles have cost humankind millions of manhours of productivity, at minimum.

Not convinced at all by these reasons. Rob Pike has long stepped down from the Go team so it shouldn't matter? This is a website not a language change.

I like Linus's work, but that post smells of rotting strawmen. All the examples look manipulated into throwing the opposition under the bus.

> The cheating is out of control.

There are hardware cheats that are not detectable by KLAC, so it doesn't solve the problem, just improves the situation.

The only way to avoid cheaters is to play with people you trust.

The real problem is that servers are now entirely the domain of the companies running the anti-cheats. We used to run the servers for most of these and could ban cheaters. But the game companies demand we play the game their way, not our way. We've really lost something.

I agree, it's a curve. I don't think we'll ever completely eliminate cheating, but we can make it so difficult and expensive that most people don't do it. That's good enough for me.

Because people want to have fair fun competition? How is that hard to understand?

They abandoned (or at least postponed) the idea of charging for self-hosted runners usage.

Actions management plane is the most problematic part of the platform (in regards to scale), so they are basically losing money with self-hosted runners.

Scaling of VMs shouldn't be a problem, since that is practically stateless, whereas there are lots of operations performed for every job/workflow.

Are you implying that a 6 year old hardware is as good as a paperweight? Outside of the Apple fairyland this is just bonkers.

I'm not blaming the Homebrew project/developers here, but the fact that many people are okay with deprecating perfectly fine hardware.

No, he’s asking what you think a reasonable support timeline is. An open source project supporting hardware 6 years old is pretty awesome.

6 years is really not a long time at all. You can probably find heaps of open source software out there that compiles and runs perfectly on 20 year old PCs. It's not like the maintainer has to do much to retain support--they just have to not make the software dependent on new operating systems.

Bits don't rot.

Bits certainly don’t rot and you’re welcome to stay on the latest stable version that runs on your architecture.

And if you want new bits with the new features, those aren’t the same bits and that work isn’t free.

Exactly. That's all I'm asking for. If version X works on my system today and version Y needs an OS bump, well... that sucks and is avoidable, but whatever. I expect to be able to obtain and use version X tomorrow and into the future. That's it. I'm not asking to make version Y work for me, but it would be nice if they didn't add the OS dependency.

But increasingly, developers can't even manage to keep version X around and working, despite them having to simply not do anything to it to keep it from breaking.

How many of those 20 year old projects had to go through an architecture change that the manufacturer no longs supports? Come on man be reasonable.

Ask MacPorts, which goes all the way back to Leopard-era PowerPC!

Homebrew doesn't have to lift a finger to support Intel Macs. It already does! All they have to do is not kill support for them.

Hey, it's their software, they are all volunteers and can do whatever they want. I'm grateful for the short window of time in which I was able to use their software. I don't get to decide their support period, but I will still hopelessly complain about it. "Deliberately breaking compatibility with a computer because it is old" is my biggest axe to grind with the whole software industry, and I'll shake my fists at this cloud until I die.

How does MacPorts manage to do it?

Why don't you ask them?

I would not expect the software to continue to get updates, but I would expect the software to continue to work.

I'm salty today because I tried to run Fusion 360, and found that Autodesk just out of the blue decided that 1. My computer is too old to run the software (which ran just fine a few weeks ago on the same computer); 2. That I needed to update the software, and 3. The update will not run on my "old" computer. They took software that ran fine on my computer and deliberately pulled the rug out. Fuck Autodesk. I'm spending the entire afternoon exporting dozens of files I have on their cloud, one at a time, since they apparently can't even manage to keep an existing version of the software running.

NixOS is an open source project that runs great on my 2013 Dell laptop. I think the real point of distinction is that brew depends on Apple's OS and SDK, which somewhat ties their hands, while other OSs don't.

I managed to sell my battered old 32-bit Thinkpad on eBay last year. I couldn’t put Trixie on it, but Bookworm installed fine.

There's been a huge step up in basically everything going from intel to apple silicon. It's not a comparable hardware in any sense, and as such, it really does feel like it became a paperweight? I know I never wanted to see an intel macbook ever again the moment I tried M1. It's maybe hard to comprehend how different it is if you haven't used both. And at the same time I'm happy with my x86 desktop for 10+ years. Only thing that really improved in that span was storage.

So I wouldn't say this applies globally to apple users/products, but the post-intel era is a special case. If nothing else, they are helping the environment by not feeding that (literally) hot garbage with more electricity.

You're on macOS. you should know full well that they do not care about those values.

It links directly to captcha page.