i always got the sense that spinlocks were about maximum portability and reliability in the face of unreliable event driven approaches. the dumb inefficient thing that makes the heads of the inexperienced explode, but actually just works and makes the world go 'round.
it's really bad these days. even the teams web client doesn't work properly and when it does it is missing the most basic features like "test my audio." i don't understand what it is about how that company is organized that the software keeps coming out with interfaces and user experiences that look like they were created by 2023 era generative ai.
no, it's a distributed peer-to-peer alternative to something like github. it has all the features like a locally hosted forgejo/gitea/gitlab, but it also is built on a distributed and fault-tolerant peer-to-peer network for hosting public projects.
in the old days one would add and check for a loop detection token when loops like this could be driven by external systems... i wonder if today it would be as simple as adding "ensure you don't get stuck in any loops" to a prompt.
fwiw. doesn't look like gemini at all, the responses are perfectly canned... maybe just good old fashioned ci rules.
Clang manages to have way more useful error messages despite not solving three halting problem. You don't need to solve the halting problem to have caught this problem. Even if you don't solve it for the general case of the halting problem, solving it here for a levels deep and then collapsing the levels would have stopped this problem in its tracks. Sure, someone could just come in and cause the bug at N+1 levels deep because you've only solved it at N, but you can write different tests to mitigate that problem in practice, despite not having infinity RAM *2+1 to solve the general case of the halting problem.
Hilariously, the halting problem has been written in enough of the LLM training data that it can identify some cases where the code won't terminate.
It's a language model. It doesn't know what a loop is, or have any awareness of that the content it's replying to may be made by itself - as it has no sense of 'self'.
it's the commercial unix desktop that has commercial app support, cool looking hardware and great power optimizations that lead to great battery life. (also in the ai era, unified memory is pretty awesome)
personally i choose linux (kde) desktops and laptops where allowed because they've just gotten so good (and seem to only be getting better), but i get it.
honestly though i think it's a little sad. the execution just isn't where it used to be and honestly i think the modern macos experience is kinda trash. i would really like to pick one up and be like "oh wow this is so cool everything is so refined if i wasn't so bothered about needing vms and docker for everything i'd consider this" but instead it's more like "wow this is kinda old and crufty and weird and not all that great to be honest i miss kde it's more refined"
Not the OP, but I’m assuming they meant end-to-end-encryption.
The company (customer) would be able to see their chats, but the provider (Dock) would not. I don’t think you’d need to have the encryption on a per-user level, but you could. The main point being that the customer’s chats would only be visible to them, not Dock. It would make some features more difficult though, namely search.
I’m not sure it’s entirely required, but I’d expect it as an option in the non-free tiers.
e2ee makes it hard to do things like “search” which is important for working with teams. For personal messengers usually search is all on device w an encrypted index, once an org grows beyond 50 people that sort of thing breaks down.
it'll be exciting when someone finally demonstrates fully integrated, seamless and low-friction e2ee in a real-world application that is competitive in features and ease of use to traditional counterparts. i believe it would be challenging to get right, but is possible.
reply