Thank you for giving us a great example of how to appropriately use AI: turning a long comment with no line breaks into a blog post summarizing the comment.
Now I just need to pass your comment into ChatGPT to get a short summary.
Edit: I asked for a one-sentence summary of it and this is what I got:
The comment expresses deep frustration with modern technology, society, government, and politics, calling for radical change and greater individual skepticism.
But how can we then ensure that I am not adding/processing products which are already in the "final" table, when I have no knowledge about ALL the products which are in this final table?
Without knowledge about your schema, I don't know enough to answer this. However, the database doesn't need to scan all rows in a table to check if a value exists if you can build an index on the relevant columns. If your products have some unique ID (or tuple of columns), then you can usually build an index on those values, which means the DB builds what is basically a lookup table for those indexed columns.
Without going into too much detail, you can think of an index as a way for a DB to make a "contains" (or "retrieve") operation drop from O(n) (check all rows) to some much faster speed like O(log n) for example. The tradeoff is that you need more space for the index now.
This comes with an added benefit that uniqueness constraints can be easily enforced on indexed columns if needed. And yes, your PK is indexed by default.
Read more about index in Postgres's docs. It actually has pretty readable documentation from my experience. Or read a book on indexes, or a video, etc. The concept is universal.
May you elaborate what you mean with read replicas? Storage in memory?
This highly depends on your needs. I'll link PG's docs on replication though.
If you're migrating right now, I wouldn't think about this too much. Replicas basically are duplicates of your database hosted on different servers (ideally in different warehouses, or even different regions if possible). Replicas work together to stay in sync, but depending on the kind of replica and the kind of query, any replica may be able to handle an incoming query (rather than a single central database).
If all you need are backups though, then replicas could be overkill. Either way, you definitely don't want prod data all stored in a single machine, usually. I would talk to your management about backup requirements and potentially availability/uptime requirements.
Well our options would have been prostate cancer or dementia, and prostate cancer is somehow still a better choice.
Imagine the latency on a data center in space. Uplink/downlink every time your server gets an inferencing request? Lol.
I could see it being fine for longer running asynchronous requests, but that would be if the cost/benefit made any sense at all, and if the servers had any resources worth talking about.
I have a server at home built from old parts and some refurbished drives with nearly as much storage as the currently launched satellites. 2800 satellites like this would come out to around 230 of my servers, or ~7PB.
A single 2U server with 12 drives, each with 24TB storage, can hold 288TB. It would take ~24 of those to get to 7PB, which is a lot of servers, but not so many that someone with quite a lot of savings couldn't afford it.
Also, the servers on the ground can be cooled by, idk, air if needed. Or water. Or I guess liquid nitrogen if you want. Point is there's an atmosphere for the heat to dissipate to, unlike space.
Pronouns are pointers. "Let us (let's) move it over there." Both "us" and "it" indirectly refer to something else by a new name. Like pointers, the pointees are defined by some context external to that sentence/statement (usually earlier sentences/statements or some other actions). The meaning of "us" and "it" can change as well in different contexts, and as such, those words are not bound to one value (and "rebinding" those words by changing contexts does not change the values they were previously bound to).
This seems like the same problem that lifetimes solve in Rust - tracking when values are no longer used and thus fall "out of scope". Automated tooling should really be doing lifetime analysis of these values, and that seems to me like it would fall well out of scope of what GenAI can be trusted to do.
If this is such a huge problem, are you able to create finalizers that close the resources instead, or better abstractions for managing the LTs of these resources? I don't write Java anymore, but this seems like a problem better solved by other tools.
On one hand, this feels very "thoughtcrime"-y. On the other, certain people should probably just not have a platform to spew their nonsense on. I'm curious to see how this plays out.
Nobody tell him about the Inflation Reduction Act.
Tokio's broadcast module is a mpmc messaging queue.
The terms "mpsc" and "mpmc" refer to how the channels can be used. Breaking down the letters, there are two sides to a channel:
p is producer, or transmitter/sender. This side sends datac is consumer, or receiver/reader. This side receives data.Data only flows one way through a channel. Each side may have a restriction on how many members can be on that side:
s is single, so this side cannot be cloned. You only have one object that can interact with this side (so only one sender or only one receiver)m is multiple, so this side can be cloned. Any number of objects can exist that interact with this side (so a bunch of simultaneous senders or receivers)A mpsc channel can only have one consumer, so only one thread can receive messages at a time, and it can only receive those messages once.
A mpmc channel can have many consumers, so multiple threads can receive messages at once, and a thread can receive a message multiple times (through multiple receivers).
Both can have multiple simultaneous producers.
This has been true for a very long time. There are entire generations that want to look in real life how face filters on Instagram and Snapchat made them and others look on social media.
This is just another step in that direction, and it's depressing how bad it is already.