To be fair, postgres still suffers from a poor choice of MVCC implementation (copy on write rather than an undo log). This one small choice has a huge number of negative knock on effects once your load becomes non-trivial
I'm also curious about this, especially if anyone has operated postgres at any kind of scale. At low scale, all databases are fine (assuming you understand what the particular database you're using does and doesn't guarantee).
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.
I'd say that the 'poor man's closures' aspect of OOP - that is, being able to package some context along with behaviour is the most useful part for day to day code. Only occasionally is inheritance of anything other than an interface valuable.
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.
Indeed, we also have technology that can read the written language. Seems like that would be the way to go, and you get to keep backwards compatibility with eyeballs
I appreciate this survey for how thought-provoking it is. Ironically, I'd say that the survey is itself art. And not a piece of art that AI in it's current state could ever pull off. Maybe that's when the AI art turing test will truly be passed, when AI is capable of curating such a survey.
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.
To be fair, newer research is demonstrating that smaller more power efficient models with the same performance are possible, so the hope is that these giant LLMs are just a stepping stone to a less energy hungry place. In contrast, proof of work fundamentally needs more energy then bigger the network gets. It's no guarantee but we can at least see some hope that as energy impact drops and increasing value is found that 'AI' will cross the threshold of being worth the energy.
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.
This is sort of the role that L3 cache plays already. Your proposal would be effectively an upgradable L4 cache. No idea if the economics on that are worth it vs bigger DRAM so you have less pressure on the nvme disk.
I'd say there is a fourth category too - things that would be perfectly fine as a simple, local program purchased once that grow over-complicated cloud features to justify a subscription model.
Examples of this would be Lens, Postman and now Insomnia. This sort of behaviour is why I use k9s and Bruno instead.
Having spent an unhealthy amount of time thinking about this, I think it's even worse than an abstraction _level_.
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.
My understanding of these prefixed IDs is that translation happens at the API boundary - what you store in the database is the unprefixed ULID/UUID in an efficient binary column.
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.
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.
The hope though is that by splitting indexing that puts search providers on an equal footing in terms of results quality (at least initially). Advertisers go to Google because users go to Google. But users go to Google because despite recent quality regressions, Google still gives consistently better results.
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
Honestly I think Google needs to be broken up. It's not a novel idea but the more I think about it the more I like it.
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.
Replication can be for HA, not just for scale. All depends on your business requirements.
Also replication can be good for other operational reasons, such as zero downtime major version upgrades. Again depends on the business need/expectations.
Same, as it stands you the user are legally liable for the full bill unless netlify graciously forgive it.
Even in op's case, they didn't (still charging 5k!).
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.
I'm also interested to know this. I have a couple of static sites running on the free tier for friends/family and now I'm planning on moving them all to a VPS as soon as I can.
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.
The worst thing that I've found with teams is the latency in a video call is _just slightly_ too high (and noticeably higher than Google meet and zoom). I find this latency to be absolutely critical in keeping the flow of conversation and preventing people from accidentally talking over each other. After seeing a forced switch to teams when the whole company was WFH, it was extremely obvious the detrimental impact it had on every meeting. It's the most basic technical aspect of the product, it doesn't matter how great the rest is if you don't nail it. That's why I hate teams.