pdpi

Can we please stop with the "AI = Slop" rhetoric? I'm fairly bearish about AI, and even I'm getting annoyed by it.

"Slop" just means something is low-quality and of poor craftsmanship, irrespective of who or what made it. If it's slop, you don't need to look for tells, you can just tell it's slop. Sure, AI is prone to specific types of mistakes, and humans are prone to other types of mistakes, and you can often tell whether a specific poorly-crafted UI is man-made or machine-made, but bad is bad is bad.

> The board members weren't "his bosses", he's "the boss" and the board serves as his pleasure

Both are true. The board as a whole is his boss in his role as CEO. He is the board's boss in his role as majority shareholder. That makes the situation a little less clear.

The thing that is patentable isn't "a vibration". It's the exact, specific means through which you produce that vibration.

We've gone from completely dumb eccentric rotating mass vibration to trackpads that you'd swear are actually physically clicking, or the Ice Cubes demo in in Nintendo's 1-2-Switch[0], both of which use linear resonant actuators. Those actuators are themselves a complex enough piece of technology to warrant a patent, and the techniques to simulate the feel or real physical objects using those actuators are pretty damn non-trivial as well.

As a general rule, I find that the patent system is problematic but, within the scope of the system as it exists today, these are perfectly reasonable things to patent.

[0]: https://www.youtube.com/watch?v=HtlqvVfk1-Q

Perhaps the most straightforward difference is right in the name — a single-board computer is a whole board. A microcontroller refers to just the IC itself. The thing that's on the article's picture is a dev board for an MCU, not the MCU alone. That's just the chip at the top with the Espressif branding.

Now, if you want to argue that the difference between a dev board and an SBC is kind of vague, I agree on that front. I'd argue that the distinction is mostly the vendor's intent. E.g. if I sell the ICs in bulk and _also_ sell a board with that IC, it's probably a dev board. If I source the ICs from somebody else, only sell the assembled boards, and ship a general-purpose OS with it, it's probably an SBC. With sufficiently powerful hardware (like this thing seems to be), you could use a dev board as an SBC, and that is basically what this article is all about.

The plugin system itself was probably already in the making, and they just chose to implement this tiny feature as a plugin to try it out.

As for the only difference being the file name, that's an untested assumption. Up until now, Claude hadn't supported AGENTS.md, and it's a simple application of Hyrum's Law that somebody, somewhere, was taking advantage of that to give one set of instructions to Claude, and a different set of instructions to some other provider. The correct behaviour in the presence of both files is not obvious, either.

Having a kill switch for the change is a perfectly reasonable safety measure in case something goes horribly wrong.

Clearly, nobody at Apple is thinking globally about this stuff.

If you have kids, "Screen Time" is a reasonable enough name for the place where parental controls live.

If you work under the assumption that AI features are OK in general, but potentially problematic around kids in particular, parental controls are a reasonable enough place to put these AI controls.

If you're not a parent, and have broader concerns about AI, you'd never even think of looking for these options where they are.

But Return and Enter are still functionally different keys on macOS. Return inserts a new line, Enter (and cmd-Return) submits forms (which works for Reddit comments, but not here for some reason).

There's a qualitative difference between "they're doing a different thing" and "they're doing the same thing, tuned differently". GP is saying that this is a case of "they just tuned it differently".

This distinction doesn't change what the performance numbers look like today, but it does inform what changes would be necessary for those numbers to look different tomorrow. E.g. Apple Silicon isn't fundamentally orders of magnitude more efficient than x86, they just used smaller features. Newer Intel and AMD chips made on equivalent processes _also_ get similar efficiency gains.

Don't know whether this is a common outcome, but I tried the "remove the walls" example, and the result was... scary. It completely changed the game so that movement is now diagonal, and made the arbitrary decision that up/down move you on the positive diagonal, and left/right move you on the negative diagonal.

The problem, of course, is that having only the one single "you can't win" law is severely underspecified, but the solution was too clever by half, and highlights the problem with this approach — every program will be under-specified, because, at some point, writing the laws becomes a bigger problem than writing the code itself.

This becomes a real issue because the combination of underspecified but rigid laws pushes the aI towards this sort of "creative" solution that matches the letter but not spirit of the law. In this case, the issue was obvious, but I seriously worry about what sort of shenanigans will occur in less obvious cases.

> Valve’s DRM is just about the least invasive and easiest to crack DRM systems on the market.

In fact, their own documentation spells this out specifically[0]:

> The Steam DRM wrapper by itself is not an anti-piracy solution. The Steam DRM wrapper protects against extremely casual piracy (i.e. copying all game files to another computer) and has some obfuscation, but it is easily removed by a motivated attacker.

0: https://partner.steamgames.com/doc/features/drm

"That front page" isn't the front page, it's the release notes for version 7.0.0.

The actual front page has "The Package Manager for Everywhere" as its subtitle (and that exact description as part of its <title>), and that is basically all you need to know. It's a staple for Unix-y power users on macOS (but supports Linux too, including WSL), and version 1.0 will be ten years old next week. You're not very far off from complaining that Postgres release notes don't explain that Postgres is a database.

But then why bother with having a display at all?

I was actually thinking the exact opposite.

The big “tail” on the original gives you something to build an enclosure around, and the ports are all on the face opposite the display. That shape makes it easy to 3d print a mount for a 10” rack.

This one has stuff on four out of six surfaces (display, button, card slot, ports), and the two free surfaces are at a right angle to each other instead of being on opposite sides, so this gives you little to no leeway for mounting semi-permanently without some adhesive.

> Also I don't think AMD and Intel is capable "to step in" to replace them.

It's kind of weird. nVidia kind of has the PC market cornered, but AMD has had the last couple of generations of Xbox and Playstation. Also, they power the Steam Deck/Machine, and Valve has been contributing a lot of AMD graphics features into the Linux drivers. There is a world where AMD (and maybe even Linux on AMD specifically) becomes the de facto standard for gaming.

Eh, seems perfectly believable to me, I've seen exactly that dynamic in several engineering orgs — the top-down comms is "more metrics, more alerts, more everything", while the bottom-up comms is "current alerts are low-quality, rank and file has alert fatigue".

Mini-B cables can be somewhat hard to find.

There's two ways to approach this — build tooling for existing Rust developers to get them to adopt the Microsoft stack, or build tooling for existing Microsoft stack developers to get them to adopt Rust.

I'd argue that the former is less important than the latter, and my understanding is that Visual Studio is still the IDE for Windows-centric development, so for those MS-first developers, Rust missing from VS means Rust is poorly supported, end of story.

Great game, too, with some truly surprising features (like Verilog export)

That's a needlessly snide take.

Any device inside my network that talks to the outside world is a potential vulnerability. TV manufacturers aren't exactly known for their stellar development practices, and dodgy apps on TVs are being used as VPN exit points for cybercrime or scraping. Then there's the part where smart TVs are adding ads to their home screens and other random places.

I want my monitors and TVs to be completely dumb. Just a display, the necessary circuitry to plug the display into a bunch of input ports, maybe the necessary circuitry to function as a KVM switch, and nothing else.

This is one case where Rust benefited from C++’s experience — move by default with opt-in clone/copy is IMO the better setup.

You can see that there is demand for a product (and, therefore, make that product), while misestimating the scale for that demand. It's what leads to failed products (when you overestimate the demand), and Apple has had a few of those. Why is it so weird that they would also underestimate the demand for other products?

I'm not saying the scrutiny on US models is unwarranted. I'm saying that open-weight models are the perfect trojan horse, so giving those models a pass on that same level of scrutiny (irrespective of provenance) is just begging to be pwned.

Giving open weight models more leeway “feels” right, but it’s a massive self-pwn based on the mother of all back doors.

It’s a little bit like saying “sysadmins need work visas and vetting, but this guy works for free, so just give him root and don’t think too hard about it”.

Seems to be anti-pattern #4: If you build it, they will come. His description matches yours almost word for word.

> The founders automatically assumed that if they had the vision and one customer wanted it, many others would

https://www.itamarnovick.com/startup-anti-pattern-4-if-you-b...

> This feels like the explanation for the Wii U, despite Nintendo obviously not being a startup of any kind.

This is a particularly interesting example, because they followed up with the Switch, which is, in some ways, the diametric opposite of the Wii U. Arguably, what happened was that they had the right idea that the hybrid TV/handheld format was the right blue ocean play, but the Wii U failed by being TV first and handheld second, instead of handheld first and TV second. You could probably build a whole business strategy course on just this discussion.

Yeah, I could've been clearer.

VGA displays are something of a dying breed, and HDMI is the single likeliest interface you might find on a random newish display, so there is a market for absolute cheapest, most basic HDMI output device you can make. If you're going to build that interface, 1080p is the resolution you need to target. My point was simply that 16MB is just barely enough to build that interface, and barely enough is still enough.

16 * 1024 * 1024 / 1920 / 1080 = 8.0909, so you have enough VRAM for double-buffered 24-bit 1080p, with a bit to spare. For pure software rendering, that's good enough!

Does it help to point out that the water path looks suspiciously like the day/night line on a map?

Like this: https://svs.gsfc.nasa.gov/5477/

And the older Anscombe's Quartet: https://en.wikipedia.org/wiki/Anscombe%27s_quartet

I've been using ImHex[0] for this purpose, to pretty good effect.

[0]: https://github.com/werwolv/imhex