Their reasoning for not having 2 keyholder is that 2 people are more likley to colude to change the results (in this case announce false results) than 3. Of course 3 people could still colude to do so, so it's a matter of reducing not eliminating the risk.
My understanding is that in 2 out of 3, the third can also decrypt/view the results, so (assuming number 3 doesn't lose their key) then 2 can't colude to cheat (unless they also colude to somehow "deprive" number 3 of their key (e.g. with a heavy wrench)). If number 3 does lose their key, then the risk of colusion is higher than "requires all 3", but conversly the risk of "accidental or deliberate failed election" is lower.
It's (always) about a balance of risks.
Parse_url isn't standards compliant, often fails with relative url's and most importantly only parses urls, not uris (with the exception of file://). I also find it's syntax clunkier than the new uri(), but that's just personal preference.
The pipe operator is indeed just syntactical sugar (and the article links to another article specifically about it which does cover the case of temporary variables), but with the coming partial function application feature it (in my opinion) will make easier to read/reason chains of code than temporary variables or nested function calls.
parse_url() also had no generate_url() counterpart - sure, it could (sometimes) split a URL into its components, but there was no safe way to modify those components and glue them back into a string. The new URI class solves that.
> The hallucination issue can be worked around by providing that demonstrates the agent's working (i.e. what tools they called with what parameters).
And this is (in my opinion) an intractable problem - You can get the AI to list the tools/parameters it used, but then you can't be sure that it hasn't just hallucinated parts of that list as well, unless you both understand that they were the right tools and right parameters to use, and run them yourself to verify the output. And at that point you might as well just have done it yourself in the first place.
I.e. if you can't trust the AI, you can't trust the AI to tell you why you should trust the AI.
It's intractable unless the problem space demands 100% correctness at all times.
When Im using observability apps I dont demand correctness, I'm very happy if the LLM came up with 3 hypotheses about what happened and I could discard 2 of them by reading its working.
They‘ve stated clearly that you pay the same. Its just calculating stuff differently that you can now remove a dedicated machine mid-month and get the remaining time‘s money back. Which wasnt the case until now.
They have been using this business model for years for their VPS products and Hetzner has slowly been moving to unify their products because it's such a disjointed mess right now.
Like, it's completely unreasonable to expect to pay more.
(Source : I work in vaccine research, including challenge studies, in the UK, but only in IT/Digital, I'm not clinical).
In the UK at least (and as I understand it in most countries that subscribe to the principles of the Declaration of Helsinki), all of our studies have to have insurance to cover such eventualities (which are exceedingly rare these days). In addition, we provide clinical contacts for the participants throughout the trial and follow-up, and ensure that participant NHS medical records (and central NHS databases such as for the COVID vaccines) are updated with the necessary details for any future related care.
Money/Payment is always a careful balance. You don't want people taking part in the trials purely for the money (i.e. doing something they wouldn't otherwise be comfortable doing), but you need to ensure they aren't disadvantaged by taking part in the trial.
Technically, that's not true either! That's the current format, previous formats (still legal and transferable/usable) have included XN, XNNXXX, XXXNX, and others!
There's definitely some ambiguity there, that's a good point.
I'd probably say that users_facts would be a to-many join table between users and facts, like if you had one row per fact and a multiple facts per user though that example doesn't really make sense here (could just have the FK exist in Fact and not need a join table). If UserFacts were stored in a table with multiple facts in one row about a single user, I would probably call that table user_facts.
Would probably also be fine with running across either in any codebase (or even singular table names, for that matter! as long as it's consistent :D )
Yes, but they're only allowed to use the data for the (legitimate) purpose it was retained. If you ask them not to retain/use it for marketing purposes, they can still retain it for statutory purposes but they can then only use it for that (not for sending you advertising emails etc.)
