On Wikipedia: German chapter is the second largest (>100 FTEs) and collects donations directly, funding root org from them and keeping significant part for its own operations. It’s not exactly an American monopoly.
You probably mean Schwarz Gruppe, the owner of Lidl, and their subsidiary StackIT. Yes, they are growing. Schwarz is also building 11B€ AI data center in Lubbenau, so I fully agree with you. We will be fine without American digital services.
The is article is about a solution in search of a problem, a classic premature optimization issue. UUIDv4 is perfectly fine for many use cases, including small databases. Performance argument must be considered when there’s a problem with performance on the horizon. Other considerations may be and very often superior to that.
It's not really feasible to rekey your UUIDv4 keyed database to int64s after the fact, imo. Sure your new tables could be integer-keyed, but the bulk of your storage will be UUID (and UUIDv4, if that's what you started with) for a very long time
I think you're right that it won't matter for most companies. But having been at a company with persistent DB performance issues with UUIDv4 keys as a contributing factor, it sucks.
If you have too many UUIDs, throw more DBs at the problem. Hopefully you haven't tied yourself to any architectural decisions that would limit you to only using a single database.
I don’t get it. Client generates UUID for prompt, PUTs the prompt with this UUID on server. Server caches the generated output for reasonable time, so that subsequent PUTs get 200 instead of 201. Transport protocol failures then do not matter. If response isn’t 4x, just retry.
Yep, came here expecting to read an interesting take on why SSE sucks or a better alternative, but this just reads like "skill issue." A term I very much dislike but seems appropriate here.
Significant part of relatively new technology stacks and tech slang is “skill issue”. A lot of problems were already solved or at least analyzed 40-20 years ago and hardly need to be re-invented, maybe just modernized.
The way the current architecture works—as far as I know—is your assumed "server caches the generated output" step doesn't exist. What you get in your output is streamed directly from the LLM to your client. Which is, in theory, the most efficient way to do it.
That's why LLM outputs that get cut off mid-stream require the end user click the "retry" button and not the, "re-send me that last output" button (which doesn't exist).
I would imagine that a simpler approach would be to simply make the last prompt idempotent... Which would require caching on their servers; something that supposedly isn't happening right now. That way, if the user re-sends the last prompt the server just responds with the same exact output it just generated. Except LLMs often make mistakes and hallucinate things... So re-sending the last prompt and hoping for a better output isn't an uncommon thing.
Soooo... Back to my suggested workaround in my other comment: Pub/sub over WebSockets :D
The user's last prompt can be sent with an idempotency key that changes each time the user initiates a new request. If that's the same, use the cache. If it's new, hit the LLM again.
The only reason LLM server responds with partial results instead of waiting and returning all at once is UX. It’s just too slow. But the problem of slow bulk responses isn’t unique for LLM and can be solved within HTTP 1.1 well enough. Doesn’t have to be the same server, can be a caching proxy in front of it. Any privacy concerns can be addressed by giving the user opportunity to tell server to cache/not to cache (can be as easy as submitting with PUT vs POST requests)
It's likely better to just store them in the database, it could be hours or days later that I want to look at the session again. If you're going to want a database for conversation anyway, then it doesn't make sense to cache and query individual messages
yup, the ADK framework I use handles all that bookkeeping for me, has a few options built in, and pretty easy to add new implementations. I'm extending it to attach filesys+exe changes during a session, persisted as container layers via Dagger
We need Framework-style company making local/owner-first everything, including fridges and washing machines today. There’s no guarantee that your next coffee machine or teapot won’t come with AI talking to you.
> a) normalising people uploading identification documents and hence lead to people becoming victims of scams
The reasonable approach to solve this problem is verification protocol that mandates integration with the apps chosen by users. You have your wallet with digital ID and you use only it on any website, sharing the bare minimum of details. No uploads of anything anywhere. Independent wallet providers ensure privacy and prevent state overreach.
> (b) a small fraction of kids branching off into fringe networks that are off the radar and will take them to very dark places very quickly.
Unfortunately dark places existed in mainstream social media too. It’s something that should receive sufficient attention from law enforcement, nothing has changed here.
> sharing the bare minimum of details
The reasonable approach, yes, but the approach most in the interest of the governments and corporate players driving these laws...?
I think people are overindexing on how much of this is "get more data on users".
I don't get why people believe there's a conspiracy here. There's perhaps a large tent, but "social media bad" is not a controversial opinion! "The gov't should do something about it" is more controversial, though I think the controversiality is less heavy in spaces with parents, teachers, places where people have to deal with kids.
Not that this is how things should be determined, but... I think reading this as a "get more data and track people" play feels like giving everyone involved too much credit. It really just feels like what it says on the tin here.
I don’t think it’s generally a good idea to store important domain information in synthetic keys. UUIDs should always be treated as opaque keys, but they may have structure that will help them fulfilling their primary function. Timestamp in UUID v7 may be close to moment of record creation, but it shouldn’t be the contract in your system that it is the creation timestamp.
Google Sheets can do a lot, especially if you have automation tool like Zapier. Excel is no longer a moat or the moat. Powerpoint… jain. It’s cool, but Miro and Figma eat that cake nowadays.
With its integrations and Turing completeness, unlike word processing or presentation- if it requires excel you just need to use excel. Even Mac Excel won’t work.
The truth is, only a fraction of your users needs MS products so much that they will die on this hill. Legal, accounting, maybe procurement. That’s it. For everyone else Google Docs are actually better.
It is perfectly possible to run a company with at least 1k employees on non-MS stack, throwing a bone of Office apps to (small) legal and accounting teams, so that they approve the budget. I did that before.
reply