edelbitter

Whose agent is it, once multiple participants talk to it?

Worse: I am writing angry and not particularly respectful comments about things that mostly happened/did not happen before I was born and very obviously those things should not be judged by what I would consider an ideal outcome by the standards of today, at least not before sending in a few patches to help with that. Sorry.

Your work, specifically your attention to the reusability/portability of GNU tests intensifying at the same time the uutils project started to close in on the remaining unusable (for that purpose) tests, is very much appreciated and has helped me well beyond its original scope.

On a more positive note, the thing that causes me some temporary pain might still be awesome for the long-term success of GNU/Linux (or whatever we shall call it now, still looking for an updated pasta[1] recipe). As much as it was a little too early a little too move fast break stuff, I applaud Ubuntu for demanding the drop-in-replacement to be possible.

To get where they are now, uutils needed to do the thing nobody bothered to do for 30 years: proper cli unit tests, the kind with which you can compare busybox/toybox/GNU/uutils/Darwin without depending on implementation details [2]. This will net more future good than current harm. Even if the tools cannot be changed to have fewer nonsensical edge cases for compatibility reasons, at least now I can ask $currentLLM to write me a better manpage, one that includes the gotchas [3] and factual errors that the 1996 (partly updated in 2004) version still fails. And improve shellcheck so even those among future generations that still need the shell as we know it today are not bitten by its warts as much.

[1]: https://safereddit.com/r/copypasta/comments/av4rl9/what_your... [2]: https://github.com/uutils/coreutils-tracking [3]: https://www.pixelbeat.org/docs/coreutils-gotchas.html

People switching or upgrading from soon-EoL versions beware: Ubuntu now defaults to uutils, which are reimplementations of GNU utils that deliberately do attempt to not read the original source (to be legally cleared to not comply with its copyleft expectations). The "correct" behavior is not always evident from POSIX, so uutils is by design an imperfect imitation with a long way to go for bug-by-bug compatibility.

While most data loss severity bugs reported in the 25.10 round of testing [1] have been resolved, the sheer volume of unexpected breakage suggests that there are more to be discovered. Most impacted are unit tests and shell scripts that expect some utility to return syscall errors in stderr and propagate it to a non-zero exit code, where on Ubuntu 26.04 they might silently swallow (apparent, partial or complete) failure to execute the requested action.

(Also, uutils binaries are ridiculously large, but this is not such big deal: Ubuntu has for many years already built rather large initramfs and has yet to make progress in automatically detecting which firmware blobs cannot possibly be needed on a given system. I did run into an "undersized" partition layout because of Rust duplication.. but only on systems upgraded from ancient times before this was the norm.)

[1]: https://github.com/uutils/coreutils/issues?q=is%3Aissue+%28l...

> I suspect it's just bad design.

I don't have good suggestions on what would improve the design while staying with the general approach, but I imagine reporting a "likely not significant" could have at least be improved to a "proven to be not significant" null result by adding the "obvious" control group. Just check how "unlikely" mentions of common memes and catchphrases compare to those brands. Are there non-brand mentions that are distributed similar to the brand mentions, showcasing that these numbers really do not mean much either way?

Not quite following why "limited liability" should necessarily reduce to "zero liability"

> they mitigate the largest DDoSes in the world

> DDoS-for-hire cost only a few dollars per minute

I imagine those two are closely related. If not for Cloudflare and similar offers, we would spend more effort & resources on non-symptomatic treatment of internet-scale bad actors and its enablers (lately, more under-maintained "smart" devices than dumb modems, I hear). Every unresolved-for-years botnet is excellent advertising for CF, and they are not even paying for it. (We are all paying for it, dearly.)

> We have seen certificate authorities caught between timely revocation and keeping subscribers’ sites online because too many subscribers could not replace their certificates quickly enough. When certificates need to be retired [..] we can [..] spread replacements across the available time, and track replacement issuance.

That sounds awfully sympathetic to the "only revoke if/when convenient" bullshit Telekom Security et al pulled off. I was hoping for something closer to:

We have seen certificate authorities extend promises to their customers that they knew to be fundamentally incompatible with their committed obligations to the CA/B & the wider internet. We intend to do better than that. We will not hide behind claiming it was inconvenient to fulfill our duties that come with operating a public CA. Our customers will be prepared for whatever revocation that we might be required to execute.

Another one that to me is equally impressive: instant glues

https://en.wikipedia.org/wiki/Cyanoacrylate

The first thorough research went into them when looking for new clear plastics, and this route of making them was ruled out because it would rather stick to everything than ease the production of objects with nice optical properties. The story goes, it was so annoying to work with that it was initially shelved, and only years after being considered again and ruled out again for a different project, the utility of its reliable and fast bonding was fully appreciated.

I wonder if you could prompt inject each camera to trigger on observing the other camera trigger, bouncing back and forth forever..

>rich, cool, nice people

I know its a bit of glass half full vs glass half empty, but I suspect those are not quite the right words. Does any of the countries recently doubling down on populist policies about immigration really care about the upper end of whatever the euphemism/approximation metric of the day is? Whether the metric is about money, social behavior, maintaining trust & continuity, or even just purely practical matters of compatibility in non-negotiable beliefs & customs.. none of the policies really seem to be aimed at drawing a line between the top 10% and the top 30%. I think its always more about keeping the bottom X% out.

Automatic call screening is available in just a select few jurisdictions where that would be legal. In the remaining supported countries, one would explicitly opt in or disable the feature altogether as they please. Last month some rapist mentality dev decided that I am no longer worthy of having that toggle in the settings because my consent does not matter. So now the toggle is hidden, the feature is on. (I can briefly regain control by resetting the phone app to factory defaults, but it keeps coming back.. until Google fixes their happy little mistake).

The OS is the distilled wisdom of other experts. Wisdom that neither I, nor the current generation of next-word-guessers, could possibly keep pace with; no matter how many reddit bots the frontier lab operates in its attempt to extract complex concepts into simpler vectors. It will be the collection of things that are so unbelievably expensive to reinvent and re-learn for each machine and user, that they are not subject to to the market forces that come with making the slop cheaper. Any well-maintained OS will maintain that role. And be ever more important in the future, as apps diverge into even lower quality and even less shared benefit from improving them (for the other approx. 2 users).

Google is currently carrying out a "call screening" experiment on Pixel phone "owners" (mentioned, but cannot be disabled in the app settings). OP is specifically mentioning iphone, though.

Huh? Knowing that the ceiling of diminishing returns is that high should make us even more optimistic about low-effort progress in the right direction. The 80/20 of weightlifting starts with no longer shifting your spine in a funny way for every slight inconvenience. That is a small distance from the feeble median status quo, and still very far away from jacked. To achieve meaningful reduction in injury risk and some forms of chronic pain, we do not need to focus as much on people going from already generally fit towards trying things that are naturally extremely difficult for them (or for their postmenopausal hormonal state). There is more net benefit per exertion at the very beginning of a resistance training voyage. Which could very well never reach the intensity of enjoying a proper "no please, no stairs!" moment that indicates maximum strength improvement per unit of time, and still have been best-in-class per unit of currency spent on nudging people into it.

There is an even stronger version of your argument, one that works without shifting to the same old "you don't need the expensive stuff, just get your life together" advice that already has kind of a bad rep for not fixing depression. You can accept that you cannot inject much more of necessary discipline and motivation into people after they leave school.. and still argue against many types of surgery in mostly the same way: by strictly comparing them to other costly endeavors that could bring about those probably-helpful life changes. Many more people could work towards that "real solution" by benefiting from some other spending.. which merely happens to be cheaper than surgery, while still not being entirely up to them.

Example: My town installed an outdoor "grown-up playground" in the nearby park. Probably cost a little over two complicated surgeries. Already saved 10 people from neglecting upper body workout. Just 10 people having a really low-barrier-of-entry gym available to them whenever walking their dog. I suspect its already been cost-effective. Plus, it is reusable and low-maintenance. Try to beat that in the operating room!

Careful, there is two different things going on here:

a) whether you use the maybe-entropy provided by the CPU (and/or the bootloader)

b) whether you credit that maybe-entropy towards your tracking of whether the pool should be considered sufficiently seeded

random.trust_cpu/random.trust_bootloader configures b).

nordrand has been removed from the kernel as it had become overloaded by meaning both a) and b)

Under most circumstances, a) is harmless. You mostly want that off when the CPU exhibits some performance hiccups when asked.

Under some circumstances, b) is outright dangerous. Some applications can work without seeded pool at some slightly reduced performance, but could be made to fail miserably if they had been made to believe that the pool was seeded yet it was not. This happens with hash tables when you skip some of the accounting because it seems no longer relevant. It really would not be relevant, once even a determined attacker should be unable to reliably trigger the worst-case-performance.

- Find some new way for Cloudflare to acquire paying customers. If their business did not depend on the status quo, they would be exceptionally well positioned to roll out the technical & organizational frameworks that that make massive botnets a thing of the past.

Not while the new dukes of the internet wielding massive armies of hijacked smart TVs have a better time browsing the web than I have; as a mere peasant with just a few IP addresses. There would be no reason to sign up and pay up for bulk access, unless open access is shut down.

Speculation, no insider info: Its one more thing that needs to be sent out to all their proxies, and could be a reason for meaningfully different metrics whenever the (non-time-critical) regular updates fail. The more configuration/state each proxy receives and processes, the more difficult it will be to determine what is wrong when one exhibits abnormal behavior. At least one of the serious outages was even directly attributed to having accidentally exceeded some hard limit (very hard actually, a rust panic) in how much data could be distributed through one particular such channel, see https://blog.cloudflare.com/18-november-2025-outage/

What is the difference between making sure an HTTPs endpoint does not leak and making sure an IMAPs endpoint does not leak? I do not see much of a fundamental difference.

Except, it makes the user experience worse: I can certainly make it infinitely more tedious to open the document exchange site of $superimportantcompany on superimportantcompany.co (or was it .com? or .co.uk? or important-company-le.ai?), and spread out "my" inbox across 30 different sites and spend additional time navigating their unique interfaces to not just read, but also add each document into the appropriate local archive. But what have I gained in making it more likely that each correspondence is kept confidential between the only parties that should read it? Nothing beyond what I started with. Could have stayed with email, no?

I can see the appeal of mitigating part of the usability problem by pivoting straight to bundling up all thematically related messages into centralized repositories to limit the number of pseudo-mailboxes one has to maintain simultaneously, as done in the recent "everything medical related" cases. But someone would grab a full copy in the inevitable compromise, and that is a risk that should rather stay scoped to smaller groups of senders and/or recipients. It seems like a bad tradeoff to force every blood test of everyone into the danger zone for that, given that one could have instead spent 3% of the budget on.. merely policing away the DNS warts in public authorities (or, in the medical example, insurance companies) while keeping data custody unchanged.

Public key encryption as in DANE already achieves what can be achieved given the constraints. I have seen some purpose-built apps that use email for auth and then establish a different channel to exchange the documents. But that just nets the security properties that you already had with email.. just with some added methods of sideloading trojans past those pesky email attachment scanners. Turns out, you cannot just sprinkle some "encryption of some sort" magic on top of an already encrypted channel (which was inadequate in auth, not in confidentiality) and get a meaningful improvement from that. Instead, it subtracts from the already way too limited budget that people trying to get actual work done can spend on establishing who they are talking to through distinct comms channels. Not sure what the purpose of those apps even is, other than generating some $$ for the provider (in the most egregious case, Cisco).

The uniformed woman with the pistol is whatever the stitching on the chest pocket say she is. Is that not true just the same even in places where other people may routinely open-carry?

That may not matter that much, as even if you run a relatively strict policy about where you send the reply, you can still easily get bitten by external mistakes there: Because of the huge number of individually administered departments that might each become authorized recipient of such data, a malicious party only needs to find one suitably dangling DNS delegation to score a "…@attacker-controlled-subdomain.legitimate.example" mailbox. The sender would not be able to prevent this.. unless its regulatory oversight body is very patient about repeatedly delaying legitimate requests for seemingly-minuscule formal defects. (Mentioning just for context. Probably not the mechanism at play here, Revolut would have tried to shift blame in the press release if it was.)

Is it uncommon/impossible to ask for the federally-brokered in-person procedure in the US?

(The way I know it: Local court or police officer shows up at our office later that day and hands over a printout matching the request that we had been unable to confirm, on request of federal authority, in turn on request of the authority demanding we hand over some customers data. Those two requests utilizing government agency-internal auth mechanisms we do not need to know or care about.)

.. 9 out of 10 unhappy customers are currently unable to cause any blame, because they cannot even reach customer service because they are getting the "bot" treatment.

If it does not happen quickly, then the result might end up similar to data privacy topics.

If you can afford to keep fines in litigation/appeals/formal-defect limbo for a sufficient number of years, you can grow out of even once-threatening fines and delay compliance until the law that you finally bow down to is so old that its signs of old age will in the meantime become popular arguments for undermining or retracting it.

I guess when discussing the reasons for the law failing to bring about the intended changes, we only need to agree on that the law did not intend to make this distinction (though it definitely could have made them, even before LLM this was a deliberate choice) - not whether doing so would have been advisable.

Sending money to the intermediary is still essentially free. The likely incorrect assumption here is rather: that it would do any good in this case. Because that only works when the intermediary has agreed to do anything other than facilitate wire transfers (with the beneficiary account number and cost schedule specified!). They would say so in the instructions (e.g. a note on how the SEPA reference field should be filled), if that were the case.

SCT is not contingent on EU or Euro participation - SEPA membership is distinct from those. That is how Iceland, Norway and Switzerland can reap the benefits (the latter not even EEA member, though effective treaties are now somewhat similar). As long as an US bank has a correspondent branch/account/partnership/whatever inside SEPA, they can make it almost free to receive money via SEPA, and then possibly still save on currency conversion and transaction cost as they clear in bulk across the pond.

RBOS is short for Royal Bank of Scotland. When accepting SEPA credit transfer (though they are not legally mandated to offer the instant execution variant), I don't think there is even a mechanism to sneak in extra fees, beyond what the sending institute already billed (typically: 0.00€).