RussianCow

On macOS, Option+Shift+- and Option+- insert an em dash (—) and en dash (–), respectively. On Linux, you can hit the Compose Key and type --- (three hyphens) to get an em dash, or --. (hyphen hyphen period) for an en dash. Windows has some dumb incantation that you'll never remember.

In my experience, Composer is billed like the rest of the models, but Auto mode is billed separately. I recently hit the limit on my plan and was being billed for on demand usage, but using Auto kept it within the "included" allowance (i.e. "free").

I'm not sure how much free usage they give you with Auto mode.

I'm not positive I could draw a technically correct bike with pen and paper (without a reference), let alone with SVG!

I highly doubt it. Most people are in rooms with bad acoustics to begin with.

This is also true of heating and cooling, and I've never understood why we (in the US) build relatively dense housing communities but don't implement things like this. Having a separate air conditioner for each home, especially in a condominium/townhouse complex, has never made sense to me as it's so inefficient compared to central heating/cooling.

Not everyone lives in an area where they can afford not to have one, especially with climates changing and temperatures hitting higher/lower extremes.

Maybe your exercise can be to direct your thoughts elsewhere. Start with 5 minutes instead of 30 and actively try to think about something else when your thoughts become too negative. I can't guarantee it will help you but it's a sort of meditation that's worked for me when I felt like my brain wouldn't turn off.

You say awesome, I say layers upon layers of opaque incantations I have to remember. Thank god for LLMs.

This was happening well before LLMs, though. If anything, I have hope that LLMs might break some people out of their echo chambers if they ask things like "do vaccines cause autism?"

The problem is human, not technical. Companies and managers need to start caring about the details instead of crossing items off a list. Until we see that culture shift in the industry, which might never happen, AI isn't going to help—if anything, it'll make the problem worse as devs rush to deliver on arbitrary deadlines.

I think the point is that other languages make guarantees that ensure you don't have to do any runtime checking. In TypeScript, it's far too easy (and sometimes inevitable) to override the type checker, so some poor function further down into the codebase might get a string when it expects an object, even though there are no type errors.

This. I use Linux as my primary OS (with KDE) and my main complaint, by far, is the email/calendar situation. Mail.app simultaneously just works and gets out of my way, and I haven't seen a Linux email client come close to replicating that.

Every few years I convince myself I'll create a better email client for Linux, and I always start the project enthusiastically and stop soon after, when I get just far enough to be reminded of how complicated email is. Maybe someday I'll take a sabatical and actually do it...

But way more difficult and with a much higher attack surface area.

And also, it's not necessarily apples to apples. It would be nice to be able to drop a compiled WASM module into your codebase and use it from just about any language on the backend. You could reuse a lot of code that way across different services without the overhead of spinning up yet another container. And you could potentially even run untrusted code in a sandboxed way.

Moreover, it's trivial to run several LLMs side-by-side for a while and measure the success of each, then migrate to the one that performs the best. And you can even migrate in-progress chats since all the context is passed on each call anyway.

The US average hasn't been that low in a few years; according to [0] it's 17.47¢/kWh, and significantly higher in some parts of the country (40+ in Hawaii). And the US has low energy costs relative to most of the rest of the world, so a 3-5x multiplier over that for other countries isn't unreasonable. Plus, energy prices are currently rising and will likely continue to do so over the next few years.

$50/month for 100W continuous usage isn't totally mad, and that could climb even higher over the rest of the decade.

The browser removes the friction of needing to install specialized software locally, which is HUGE when you want people to actually use your software. Figma would have been dead in the water if it wasn't stupidly simple to share a design via a URL to anyone with a computer and an internet connection.

The same logic you used for runtimes also applies to libraries. Vulnerabilities are found in popular JS libraries all the time. The surface area is, of course, smaller than that of a runtime like Node.js, but there is still lots of potential for security issues with out-of-date libraries.

There really is no good solution other than to reduce the surface area for vulnerabilities by reducing the total amount of code you depend on (including third-party code). In practice, this means using as few dependencies as possible. If you only use one or two functions from lodash or some other helper library, you're probably better off writing or pulling in those functions directly instead.

React was actually pretty simple in the early days. It's gotten significantly more complex because of hooks, suspense, SSR, and other features they've introduced more recently. But I would still take modern React over AngularJS 1 and I think it's far more explicit.

This. React was incredibly innovative at a time where the alternatives were some combination of:

* Two-way data binding spaghetti

* Boilerplate-heavy reactivity

* Opaque, framework-specific magic

* Manual state updates/transitions

React didn't win "by default" (whatever that means), it won because it was better than most of the other options at the time.

I agree that, on purely technical grounds, it isn't as strong of a framework as other competitors anymore, but React is and has always been Good Enough™ for most companies, to the point that it's not worth reaching for anything else most of the time. And I say this as someone who doesn't like most things about modern React.

This has happened to me more times than I can count, and it's extremely frustrating because it teaches people the wrong lesson. The worst part is they often get defensive when you refuse to cooperate, which just makes the whole thing unnecessarily more stressful.

Ironically, I used JetBrains products for years before switching to VS Code because the latter felt so much faster. So it definitely depends on what you're used to.

Zed feels significantly faster than VS Code, but it also doesn't feel as polished and "complete" as an IDE, so I'm going to stick to VS Code for now for the same reason I stuck to JetBrains IDEs for so long.

> but honestly I don’t see why providers don’t compete at all here

Because the types of customers that make them the most money don't care about any of this stuff. They'll happily pay whatever AWS (or other cloud provider) charges them, either because "scale" or because the decision makers don't realize there are better options for them. (And depending on the use case, sometimes there aren't.)

> Not to mention you'll have to be in the business of defining, updating and managing the schema, ensuring that upgrades to the db don't break the application servers, etc, etc.

I have to do this already with practically all software I write, so the comexity is already baked in. Sure, if you don't already have a database or cache, maybe a proxy is simpler, but otherwise it's just extra infrastructure you need to manage.

> The proxy server is the right design decision if you are truly trying to build something production worthy and you want it to scale.

I've been doing stuff like the above (not for LLMs but similar use cases) for years "at scale" without issues. But in any case, you need to store state the moment you scale beyond a single proxy server anyway. Plus, most products never achieve a scale where this discussion matters.

You can do all of that without a proxy. Just store the current state in your database or a Redis instance.

It's simpler than that. People often don't know what they want until they're actually presented with the buying decision. Economists call this stated vs revealed preferences and it's a well documented and understood phenomena.

Isn't Fastmail basically the only one? What other well known provider supports JMAP?

> blaming the services for putting that term in the contract and obligating you to do it.

I think you're vastly overestimating customers' willingness to listen and care about whose fault it is. In practice, if Netflix (or whatever other app) suddenly stopped working on Android phones, people using Android would complain about their phones being broken whilst their iPhone-using friends continue to use the app just fine.

The media companies know that they will win that game of chicken every time. It would take a concerted effort across tech companies to really take them down, and nobody is interested in waging that war because the cost of simply implementing DRM is too low for it to be worth the struggle and the risk.

> I've noticed a notable performance penalty (around 10%, even higher on GPU heavy games) when running games with Proton, which is mainly why I haven't dropped Windows yet.

I don't mean to dismiss your comment at all, but I'm surprised that such a low overhead would be the primary reason holding you back from switching. The difference between, say, 100 FPS and 91 FPS seems so negligible in my mind that it would be pretty near the bottom on the list of reasons not to switch to Linux.

> This is how we should view optional services that require us to give our PII data in exchange for hours of attention-grabbing content.

This is a nice fantasy, but realistically it means you shouldn't use probably 90% of services out there, which isn't reasonable for most people. Plus, there are plenty of companies with treasure troves full of data on you that have equally questionable data security/privacy practices that you've never even directly interacted with.

We need regulation. There is no other alternative. And we need to stop blaming victims of data breaches for companies not putting basic security measures in place. I don't think it's unreasonable to expect every company you interact with to securely store your sensitive data. If a place was physically making people ill like in your thought experiment, they wouldn't be around for very long; I think we should demand the same for our data.

> Blindly trusting these models without any verification will put innocent people in prison.

I don't think anybody is suggesting this. But if the models can gleam information/insights that humans can't, that's still valuable, even if it's wrong some percentage of the time.