ipsi

> Ouch! Much of this verbiage was dictated by me personally; I just have a fairly distinct register some might consider inscrutable.

I do notice that the more Claude-generated stuff I read, the more it creeps into my daily usage, and I suspect I don't read nearly as much of it as an Anthropic Employee would, so I could believe that. Though "much of" isn't the same as "written with zero AI generation/rephrasing/etc."

Anyway, that aside, something I would like to see is an example of something that's possible with this system that isn't, or isn't easily, possible with existing Claude hooks. Right now it reads like "Here's a cool thing! Here's how it works! And here's this other similar system we have! Here's how that works!" But there's no summary of the differences, why I'd use this over regular hooks, and so on. Or at least not that I saw on quick skim, and I'd be looking for that to be mentioned as early as possible, so I know if the rest is worth reading.

The future for whom? The general public? Not a chance, no way, not unless it's able to run on a phone (anywhere from 20-40% of internet users, world-wide, are phone-only).

For companies? I think that's a lot more plausible, as that's mostly just a question of money - is it cheaper to run and administrate our own models, or outsource that?

For technically inclined users? I think that's unlikely unless they're able to operate on relatively cheap hardware while still being just as good as the hosted models. And by that I don't mean "a mac studio," that's far more money than I think is reasonable. A single RTX 5080, maybe, once memory prices start to drop.

If you go far enough back in time (this dates back to at least 2011), it's arguing against things like:

For port binding, for example, it used to be that you'd deploy your app to the web application container, rather than bundling them together. e.g., deploying your WAR file to Tomcat, rather than building a self-executing JAR which included Tomcat. The wording is a bit odd, but I think they were trying to make the point very generic, and not specifically about the Enterprise Java world.

For the backing resources, it's a combination of point 3, config often living inside the codebase, applications just shelling out to /usr/sbin/sendmail or what have you, and applications living on the same host as the DB, such that bringing up a new application necessarily required bringing up a new DB as well. Which also made it hard it to scale horizontally.

The whole "12 Factor" thing was partly because Heroku had specific solutions for all of these, so going down this road made it much easier to then sell Heroku, and partly because they really were frustrating. I'd say that the port binding one is more targeted at, say, WebSphere, and all that came along with it, such as sharing a single heap across multiple apps, needing to talk to the WebSphere admins to change configuration, needing to use a "lite" version of WebSphere to test locally, if that was even possible, and so on.

They sound super-obvious these days, but at the time, for a lot of us, they were really nice to see.

Overwatch has similar issues - common advice for playing Competitive is to just completely disable text chat and voice chat. Yeah, you'll miss genuine, helpful suggestions, but they're a tiny, tiny minority of messages at the lower ranks. Not that it necessarily improves a lot at the higher ranks, as I understand it, but is less awful.

I don't play a lot of competitive Overwatch, but it's definitely a much nicer experience with chat turned off, even if I'm not the one being flamed, even if we lose because people are typing instead of shooting.

The biggest issue is, of course, (4) - how do you plan on enforcing that for sites that don't run out of your country of residence? Implicitly restrict access to only those sites in said country?

Even then - I have a reasonably nice Brother Printer/Scanner/etc device, and I could never get AirPrint to reliably work until I switched over to using Ethernet instead of Wi-Fi. Something to do with it going to sleep and not broadcasting the necessary mDNS stuff, IIRC. I couldn't find any combination of settings in the printer to make it happy, and since it's now right next to a switch, it's not really worth the effort of digging any further.

The Java one can actually be quite helpful, for a couple of reasons:

1. It tells you which variable is null. While I think modern Java will include that detail in the exception, that's fairly new. So if you had `a.foo(b.getBar(), c.getBaz())`, was a, b, or c null? Who knows!

2. Putting it in the constructor meant you'd get a stack trace telling you where the null value came from, while waiting until it was used made it a lot harder to track down the source.

Not applicable to all situations, but it could be genuinely helpful, and has been to me.

When spoken? Almost certainly. But I think they mostly write in Hochdeutsch, especially in formal contexts, at least that I've seen (private chats/etc are a totally different matter), so I don't foresee any major issues there.

They really are very, very different. Knowledge of one helps with the other, but it's far more than just "a couple of weeks to adjust to the accent", for example.

EDIT: It's worth noting that this is mostly a spoken thing, AIUI - most formal/semi-formal writing would be in Hochdetusch rather than a local dialect.

That matches my experience, in an admittedly slightly older car. Note that you'll rarely be charging over 80% because it's just too slow, and going under 5-10% is a bit too stressful, so practical range is probably 70-75% of maximum on longer trips. Less if it's winter and/or the AC is running.

If I could rely on every Rasthof having multiple functional EV chargers, I think range anxiety would be far, far less of an issue for me, but as of now it's something that I do think about for longer trips, and do have to plan for.

SourceForge, probably.

Yes, for one of two reasons, I'd say:

* In the big cities, increased rents will almost immediately eat up the extra income from the UBI, and there won't be any meaningful change in the status quo for anyone who rents — which I imagine includes the majority of the people who do the important but undesirable jobs.

* Anywhere that the people doing these jobs either can afford houses (smaller American towns, e.g.), or where there's enough rental supply that rent won't immediately go up by the same amount as the UBI, will have to start paying people more to do these jobs. As far as I understand it, jobs like trash collection are already relatively well-paid given the training and qualifications required, so they might not even have to pay that much more.