I think it's sort of obvious that the limit to this general rule is when data dependencies between fors and ifs forbid you from pushing things further up/down.
14,989 karma · joined March 3, 2013
I understand why you'd want it, and that's why RFC10008 introduces QUERY as a GET-with-body alternative.
A bit tangential, but I really *really* appreciate them making this distinction, and wish more people did this. Way too many tools try to advertise themselves as all things for all people, catering to all use cases, and that helps nobody.
"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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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”.
> 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 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.
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.