Comments URL: https://news.ycombinator.com/item?id=46905555

Points: 532

# Comments: 333

Postgres has some really great features from a developer point of view, but my impression is that it is much tougher from an operations perspective. Not that other databases don't have ops requirements, but mysql doesn't seem to suffer from a lot of the tricky issues, corner cases and footguns that postgres has (eg. Issues mentioned in a sibling thread around necessary maintenance having no suitable window to run at any point in the day). Again I note this is about ops, not development. Mysql has well known dev footguns. Personally I find Dev footguns easier to countenance because they likely present less business risk than operational ones. I would like to know if I am mistaken in this impression.

Whether or not this is an endorsement of OOP or a criticism is open to interpretation.

> Your program must be really small and scoped for this to make sense.

to me suggests that it's not really global state if your program has to stay small and scoped. In a sense, your program has just become the context boundary for the state, instead of a function, or class, or database.

I realise that this line of argument effectively leads to the idea that no state is global, but perhaps that gives us a better way to understand the claim that 'global variables can work', which they undoubtedly can. It's fine for a program (or a thread, as in the original article) to be the context which bounds a variable's scope.

For me what really distinguished the more obvious human art is that it had a story. It was saying something more than the image itself. This is why Meeting at Krizky stands out as obviously human, and so is The Wounding of Christ whereas muscular man is not.

As with other commenters, I'm surprised the author liked the big gate so much. To me it was one of the easier AI pieces just by virtue of it's composition. It's a big gate. With no clear reason for being there, there are no characters that the gate means something to. It's just a big gate. Obvious slop. Paris scene on the other hand, did convince me. It does a pretty good job of capturing a mood, it sort of feels a bit Lowry but more french impressionist.

I think this has similar parallels to good character writing. A few words of dialogue of action can reveal complex inner beliefs and goals. The absence of those can feel hollow. It's why "have the lambs stopped screaming?" is more compelling than "somehow, palpatine returned".

To some extent, we already have had this competition between human made high art and human made generic slop for hundreds of years. The slop has always been more popular to the chagrin of those that consider high art to be superior. I don't blame anyone for consuming slop. I do. It's fun.

This is a bit of a ramble but I honestly appreciate that this survey genuinely adds another perspective to the question of what art is. Sorry if that sounds extremely pretentious. But then again, I like slop.

Edit: although yes I do agree that the 'value' part is tricky. If internet spam can generate more 'value' for some people than doing science, then when intelligence is cheap we are in for a rough time.

Examples of this would be Lens, Postman and now Insomnia. This sort of behaviour is why I use k9s and Bruno instead.

I suspect that the fundamental problem with visual languages is that you have to reify _something_ as the objects/symbols of the language. The most widely used text languages tend to be multi-paradigm languages which have significant flexibility in developing and integrating new abstractions over the lifetime of projects and library ecosystems.

It's not clear to me how this can be overcome in visual languages without losing the advantages, and instead ending up with a text language that is just more spread out.

Then, whenever the API includes an id in a response, it adds the appropriate prefix. When receiving an id in a request, validate that the prefix is correct and then strip the prefix.

That gets you all the advantages of prefixed IDs but still keep all 128bits (or however many bits, you don't have to stick to UUIDs) for the actual id.

Or, to put it another way, there's no need to store the prefix in the column because it will be identical for all rows.

EDIT: this is not to knock your work - quite the opposite. If you do have a use case where you need rows in the same table to have a dynamic prefix, or the client takes the IDs and needs to put them in their own database, then your solution has a lot of advantages. I think what I'm getting at is that if you're using prefixes then it's a worthwhile discussion to be had about where you apply the prefix.

https://github.com/karpathy/llm.c/discussions/677

You could take the final checkpoint from that page and run it for some additional steps and see if it improves? You could always publish the final checkpoint and training curves - someone might find it useful.

If search providers could at least match Google quality 'by default' that might help break the stranglehold wherein people like the GP are at the mercy of the whims of a single org

So, Google becomes two orgs: Google indexing and Google search. Google indexing must offer its services to all search providers equally without preference to Google search. Now we can have competition in results ranking and monetisation, while 'google indexing' must compete on providing the most valuable signals for separating out spam.

It doesn't solve the problem directly (as others have noted, inbound links are no longer as strong a signal as they used to be) but maybe it gives us the building blocks to do so.

Perhaps also competition in the indexing space would mean that one seo strategy no longer works, disincentivising 'seo' over what we actually want, which is quality content.

Also replication can be good for other operational reasons, such as zero downtime major version upgrades. Again depends on the business need/expectations.

If there was an option to cap billing, or at least some legally binding limit on liability, then I can countenance using netlify.

Until then, it's just not feasible nor worth the risk.

It is beyond ridiculous that serverless providers don't offer a way to cap spending. The idea that it might cause your site to go offline is a complete non-argument. That what I _want_ to happen. I want to be able to say sure, I'm happy to sustain 10x traffic for a few hours, and maybe 3x sustained over days, but after that take it offline. I don't want infinitely scaling infra precisely because of the infinitely scaling costs.

In this case, it's for the harmless charm of an imagined past, but the same forces are at play in some more dangerous forms of social conservatism.

The article you linked specifically states that this was previously thought to be true, but is not.

It does however point out that per-capita ocean plastic polluters are not evenly geographically distributed.