Using an SD card (or micro SD in an adapter) connected to a USB reader might meet your needs. You can then use the SD write protect switch.

I thing I learned only recently is that the write protect switch on the SD card is not an electrical switch connected to anything in the SD card itself: it just hits a lever in the SD socket that opens a contact closure and it's up to the system (hardware and software both) to bother to look at it. So on many systems the write protect switch doesn't even work.

>But it leads to ridiculous whoppers like this, and ends up in practice excusing what amounts to the most corrupt regime in this country in over a century, if not ever.

Amen. Preach it, brother!

>No, this is just bad, on its own, absent any discussion about what someone else did. There was no equivalent pardon of a perpetrator of an impactful crime in a previous administration I can think of. I'm genuinely curious what you think you're citing?

I don't know what the poster was referring to, but I AM mad at Biden for pardoning his family. It's a molehill of an issue compared to the current administration though.

I would be very mad at Biden pardoning his family if the next president was going to be Bush. With all of Trump's calls for retribution, and actions in that direction since the election, it is hard to blame Biden for trying to shield his son from unjust exercises of the law, while Trump was publicly touting him as one of his biggest enemies.

I was less mad that Biden pardoned his family, when Trump did it first for Kushner in Dec. 2020. The precedent was already there.

You called an "interrupt," which was basically a system call. That changed a bunch of timing registers within the video hardware. For a long time you basically could only do 40, 80 columns of text and 25, 43, or 50 lines. With some trickery you could get the video hardware to output 90 columns and with even more trickery you could get 60 rows.

If you made a custom font you could also have more diversity in the number of rows too but this was rarely done.

Eventually different text modes became available with higher resolution video cards and monitors. 132 columns of text were common but there were others.

For panels in northern climates, if the tilt is fixed or just seasonally adjusted (i.e., not tracking the sun), we often will bias towards a bit more vertical tilt than mathematically optimal to encourage snow shedding.

>The point is that they are prioritizing this over new features.

Good! Shoring up infrastructure vs. delivering the latest hotness is something that is rarely prioritized. I'll take boring and reliable every day of the week.

Fair point, but I believe they are just migrating for the sake of pleasing their MS overlords.

Does anyone know what infra they are running on now? AWS?

> There doesn't really seem to be anything interesting about this.

Agreed. Seriously, am I missing something or are the compact chargers from various other companies at least as compelling as this? I've got a nice one from Lenovo with high output and a smaller form factor than this. (Several other manufacturers have a similar size and output so nothing special about Lenovo here). The Apple one, while maybe smaller then their usual, is still bigger and appears to be short and "fat" which can limit where you can plug it sometimes.

Or is just another "but this time it is from Apple" kind of thing. (All the vapor chamber talk from a few days ago had me scratching my head too.)

It’s slightly interesting in a “look how much stuff they crammed in there” way, but that would be true of a lot of other tiny chargers too.

Having read the article, I’m a little surprised this hit the front page. It’s well done as a tear down. But that’s all it is.

I'm the one who submitted this link. (I have zero affiliation with the authors). What you say is fair enough, but I thought the article an interesting data point nonetheless. In particular, I found it interesting how a vulnerability: 1) with a tiny window during which it was published, 2) of very high potential severity, and 3) with SO MUCH publicity surrounding it could still be lingering where you might accidentally grab it. The threat isn't giant here, but I saw it as just today's reminder to keep shields up.

It'd be some fluke of an accident. You'd need to be targeting not only debian:testing/unstable, but specifically debian:testing-20240311. And then - making sure not to apt upgrade at any point so you don't accidentally get any updates from the last 18 months - you'd need to also install openssh-server to avail of the backdoor, plus a service manager because running sshd in the foreground killswitches said backdoor. And then don't forget to expose the ssh port otherwise our effort is wasted.

The most realistic way to hit this would be to have built an image 18 months ago, on top of :testing or :unstable, and then not update or rebuild it at any time in those 18 months - in which case removing anything from the repo wouldn't help you. Or be purposely trying to recreate an affected environment for testing/research, in which case it's on you.

You're not wrong that we should keep our shields up - but "update sometime in the last 18 months" perhaps isn't such a revelation.

One thing does come to mind though - I do wonder if there's a way to strongarm apt's dependencies mechanism into having openssh-server conflict with affected libxz versions, so that if you did apt update && apt install openssh-server in an affected image, it'd bring a fixed libxz along for the ride. (and the images don't carry apt manifests, so apt update is required and you would have today's package list.) You could still pin an affected version, so there'd still be enough rope to allow you to recreate a research environment.

It sounds like you are adding things with care and thought, but is there a reason the user might care that the link is to an external site?

Because the trust associated with my site and domain doesn't necessarily extend to another. The user should know that they are navigating away from the trust I have earned with them.

In what ways is it better? Security margin or something? I thought Speck has held up pretty well to cryptanalysis (unlike you I'm not in the security field so maybe I'm wrong).

I quite liked the remarkable simplicity of Speck. Performance was better than Ascon in my limited testing. It seems like it should be smaller on-die or in bytes of code, and with possibly lower power consumption. And round key generation was possible to compute on-the-fly (reusing the round code!) for truly tiny processors.

>Even the tiniest MCU can typically perform more than one cryptographic operation per second. If your MCU has any cycles to spare at all it usually has enough cycles for cryptography.

>1 operation per second would refer to cryptographic signatures. If you are doing Chacha, the speeds are more like 1 mbps. AES is probably closer to 400 kbps.

It sounds to me like you, sir or madame, have not worked with truly tiny MCUs. :-)

But yes, there are inexpensive MCUs where you can do quite a bit of crypto in software at decent speeds.