...seems to me you should try to spend down those credits first, even if it's on something completely useless. Otherwise you're giving them free money (they never had to spend the compute).
Playing devil's advocate: if I did in fact grab one of my kitchen knives to defend myself against a violent intruder into my kitchen, I wouldn't expect to be banned from buying kitchen knives.
I'm not sure this is still a useful analogy, though...
And if you grabbed the knife and went on a violent spree, I'd absolutely expect the knife manufacturer to refuse to sell to you anymore.
The knife manufacturer isn't obligated to sell to you in either case, I'd expect them not to cut ties with you in the self defence scenario. But it is their choice.
1. Found out you used their knives to go murdering
2. Sells knives in a fashion where it's possible for them to prevent you from buying their knives (i.e. direct to consumer sales)
Would almost certainly not "be more than happy to continue to sell to you". Even if we ignore the fact that most people are simply against assisting in murders (which by itself is a sufficient justification in most companies), the bad PR (see the "found out" and "direct to consumer" part) would make you a hugely unprofitable customer.
Meh. Not sure why knife dealers would be assumed to be more moral than firearms dealers. See, e.g. Delana v. CED Sales (Missouri)
> the bad PR (see the "found out" and "direct to consumer" part) would make you a hugely unprofitable customer.
That... Doesn't happen.
Boycotts by people who weren't going to buy your product anyway are immaterial to business. The inevitable lawsuits are costly, but are generally thought of as good publicity, because they keep the business name in the news.
If I shoot someone, something that is explicitly warned against in firearm safety materials that come with every purchase of a new firearm, I am no longer allowed to purchase any more firearms.
The specific shape of a kitchen knife would make it a particularly poor fighting knife, and knives in general are bad for self defense, due to the potential for it to be turned against the user. So, there is a good argument that such a suggestion is really in the user's best interest rather than a cynical play for the manufacturer to limit liability.
Ummm, that change (if you mean being able to flip the pieces as if looking in a mirror) would fundamentally change the essence of the game. It would prevent players from developing the visual ability to mentally rotate and imagine the piece. I believe it would break the core dynamic and the spirit of the game, but I appreciate your feedback nonetheless.
> It would prevent players from developing the visual ability to mentally rotate and imagine the piece.
To me, this was the least fun part. Since there’s no penalty for entering squares incorrectly, I just tried the shape, and if it wasn’t accepted, I figured “oops, I must have flipped it.”
But I agree it would be a major change. If you ever share the source code, I would want to try doing this myself for my own use, to see what it feels like.
> I think the "somehow" is the extremely integrated app store. Previously, if there were any app stores, they didn't really matter. It didn't hurt you not to be in them because hardly any users were either. But today it's basically just a technicality to say that you don't have to be in the official app store, and not even theoretically/technically true in many cases.
I don't think this in itself is the cause. Basically every Linux distribution has an "official repository" which is really just an app store by another name, but the system is still open. Having an integrated distribution channel is really useful!
True. And of course there is no problem with other stores like fdroid.
But somehow google play is different, which is why I added the highly integrated part.
I think fdroid actually helps google play by going so far the other direction that it excludes most apps, so you cannot have fdroid as your only app store. (to be clear I highly approve of fdroids policy and would not change it)
But there are even other app stores that cover both bases, allowing all the non free apos from play store and yet not being google. But then the problem is trust. I trust the apps in say the ubuntu repos and in fdroid, but say Aurora store? ehh, maybe? I would normally not even slightly consider installing apks from a 3rd party like that, but I got an eink tablet that can't install google play, so was more or less forced to try it just on that device. But that's not my phone. I don't have or do anything important or sensitive on it.
So while I am still sure that Google is doing multiple things that keep play store practically unavoidable necessity, it's probably also a combination of other, kind of coincidental factors too like fdroids strict principles and no obvious basis to trust any other store. Maybe some of those other factors are not immutable.
Maybe it's just an impression thing or a failure of marketing and Aurora is exactly the answer and exactly as trustworthy as any official major linux distro repo, and I just don't have that impression for some reason.
Remember that the Play Store was the fourth iteration of an Android app store developed by Google, a global technology giant with vast resources. Earlier non-free, closed-source app stores helped pave the way for what eventually became the modern Play Store. Although you can always sideload an APK file, the foundation of the ecosystem was built on big spenders, whales and freemium games
The people who "accept ads as a part of life" are funding the content you read and watch. You are not in any way "a bad person", but you should be thankful that not everyone blocks ads.
Venture capital funds the content, on the hope that people watch ads in the future. Online ads now are a very different beast compared to what AdWords was from 2002-2007 - not dependent on full-spectrum surveillance through their own browser, their own mobile operating system, video streaming and cloud suite.
Google accumulated untold riches from those primitive ads yet they and Meta have tightened the screw a little bit more in each passing year.
Have always felt it's not really any different to allowing a website to run a JS crypto miner. It moves money (which is why it's done) but wastes resources (time/energy) so is on net a detriment to affordability.
I find it often helps me to see a feature before I evaluate if it was really a good idea in the first place. This is my failing--but one thing I like about Claude is that it's now possible to just try stuff and throw away whatever doesn't work out.
...uh, I think Claude Code is great, actually. A lot of that is indeed just the strength of the underlying model, but the local client is great too. Plan mode, checkpoints, subagents... I've been using Claude Code for a year now, and I feel like Anthropic has steadily been eliminating pain points.
I love Claude Code and use it all day, every day for work. I would self identify as an unofficial Claude Code evangelist amongst my coworkers and friends.
But Claude Code is buggy as hell. Flicker is still present. Plugin/skill configuration is an absolute shitshow. The docs are (very) outdated/incomplete. The docs are also poorly organized, embarrassingly so. I know Claude Code's feature set quite well, and I still have a hard time navigating their docs to find a particular thing sometimes. Did you know Claude Code supports "rules" (similar to the original Cursor Rules)? Find where they are documented, and tell me that's intuitive and discoverable. I'm sorry, but with an unlimited token (and I assume, by now, personnel) budget, there is no excuse for the literal inventors of Claude Code to have documentation this bad.
I seriously wish they would spend some more cycles on quality rather than continuing to push so many new features. I love new features, but when I can't even install a plugin properly (without manual file system manipulation) because the configuration system is so bugged, inscrutable, and incompletely documented, I think it's obvious that a rebalancing is needed. But then again, why bother if you're winning anyway?
Side note: comparing it to Gemini CLI is simply cruel. No one should ever have to use or think about Gemini CLI.
I've been using deletated Claude agents in vscode and it crashes so much it's insane... I switched to copilot Claude local agents and it works much better.
Idk about this whole vibe coding thing though... Well see what happens
The AI cannot drive meaning from the dog's input because there's no useful information encoded in there. It's effectively a random string (if there's less randomness, it's just because it's a dog's paw physically pressing on a keyboard).
All the relevant information was in the initial prompt and the scaffolding. The dog was not even /dev/random, it was simply a trigger to "give it another go".
The shapes of clouds and positions of stars are essentially random, and yet humans derive meaning from both. I agree you could have gotten the same results via /dev/random, or probably by increasing the temperature on the model, but I suspect doing one of those things is important.
The shapes of clouds and positions of stars aren't completely random; there is useful information in them, to varying degrees (e.g. some clouds do look like, say, a rabbit, enough that a majority of people will agree). The mechanism at play here with the LLM is completely different; the connection between two dog-inputs and the resulting game barely exists, if at all. Maybe the only signal is "some input was entered, therefore the user wants a game".
If you could have gotten the same result with any input, or with /dev/random, then effectively no useful information was encoded in the input. The initial prompt and the scaffolding do encode useful information, however, and are the ones doing the heavy lifting; the article admits as much.
> If you could have gotten the same result with any input, or with /dev/random, then effectively no useful information was encoded in the input.
It's not that the input contained useful information—obviously it does not—it's that it's causing the output to be more random, and thus more "creative".
Without the gibberish, "generate a random game" would likely repeatedly surface high-probability concepts—platformers, space shooters, tower defense—whatever sits near the top of the model's prior distribution for "game." The gibberish causes the model to land on concepts like "frog" that it would almost never reach otherwise.
For what it's worth, Apple's UEFI firmware is likely not compliant because they began using EFI before it was standardized. You can blame them for not updating it later, but I can understand why they didn't; it was working.
Look up "UEFI shell" for your vendor. Sometimes this is an unlisted F key, sometimes its as simple as selecting it as which OS you want to boot, sometimes it will happen automatically if no boot device is discovered, sometimes you must supply it as a bootx64.efi from the vendor (or from Tianocore).
Just because UEFI is a standard doesn't mean all the vendors don't smoke crack.
That's only a shell/repl, implementing a DSL for boot-related stuff. It isn't implemented in FORTH, it does not execute or understand FORTH, or use it for anything. It's not there.
It just occupies a similar role in a similar place, of what some FORTHs on some systems once did. Mainly OpenBoot on SUNs and some PPC Apples, while having nothing from their internals.
Having the ability to type some commands in your firmware/BIOS/UEFI, like it has been the case on Sparcs by SUN, PPC Macintosh by Apple, or the OLPC doesn't make it a FORTH.
reply