edelbitter

> a particular vision of progress that is informed by history

I imagine there has, for a very long time, not been a need to specifically write down what that field-specific vision is and how exactly history teaches us that there really only is one scientific method. Some future LLM will surely be able to explain this in their place, so mathematicians can stick to their primary fields instead of having to become experts in teaching the theory of teaching.

Are they?

The problem to be solved was not to spew out maximum lines of text containing some greek letters per hour.

It was to write down iterative progress in conceptualizing, modelling and consistently explaining difficult questions - in a way that advances human understanding. If nobody bothers to read through 50 pages of gibberish that may or may not be containing some insight, then the total problem solving remains zero.

The old hardware approach is still king when it comes to effortlessly catching someone "optimizing" something in a way that will break again in just a few generations of whatever Intel is doing. Unfortunately 486 is now gone from linux upstream (better/worse: all TSC-less or CX8-less cpus are dropped).

3.9 tar is on SuSE 4.3 cdrom 3, see https://archive.org/download/suse-linux-4.3

Even when assuming that a decline in hanging out in person is a huge factor, it is particularly bad for the youngest. Because all the suburbia+birthrate trends get much worse at the point where the number of same-age peers within comfortable reach of available transportation drops from 1 to 0. The same basic principle was less awful for the earlier generation that more likely lived through a comparatively mild 3 to 2 drop, and remains less bad for those that grew up just in time to make up for the distance with reasonable affordable petrol.

The point about gambling is hard to argue against. Abolishing (or simply stopping enforcement of) various gambling bans around the world, especially those specifically scoped for the youth, is a fairly recent development. Upholding those bans took constant investment - the incentives to tear down the protections were always there.

I politely refused the data collection a couple times just to confirm my understanding, expecting to trigger some discussion in case I was wrong. But hotel staff was perfectly aware of the applicable local rules and just skipped ahead to explaining the most convenient route to my room. Apparently the general assumption among visitors is that they would not ask if they were not required to collect it.

Yeah, I don't think its particularly useful with hostile cloud providers that want to keep their legally unchallenged discretion over which of the clearly-not-inteded invoices to cancel and which ones to enforce.

But is is useful in related cases. I have now had two separate incidents where this would have saved me the hassle. Both were service providers which unilaterally tried to deviate from contract terms. One was possibly a unintended billing software upgrade where they suddenly added an extra item to a 10 year contract that did not belong there, the other was an apparently profitable "lets just try and see what percentage of customers notice" dick move. I should not have needed to care about this, both companies should have just been slapped with a hefty fee for requiring their and my bank to take a look, and then figure it out on their own instead of me having to call once to fix the problem for the future, and then call again to remind them about reimbursing the delta from past billing intervals.

I was amazed when, of all the banks, PayPal was the one that has this "show all subscriptions" screen (somewhere tucked away a few settings links deep).

> both sides have to be initiated before a transfer can happen

What would be preventing a forge from answering with a reference to schroedingers octocat when inquired about the yet-undefined properties of a newly created repository? The first pushing client explicitly looks for it, and no final decision has be made server-side until someone wants to take a peek, no?

> who's out here using git hashes as a security tool

Among others, dependency management in Rust [1] and Python [2] sometimes uses references that work similar to https://github.com/rust-lang/rust/commit/ec999ed [3] to suggest one particular version of the project, authored by the specified maintainer.

Unfortunately, it means neither, unless you pushed it. The hash points to whatever the first person uploading it to github submitted. And the author/org name in the URL is window dressing: all the objects go in one big bucket regardless of push permission to one particular fork (because why wouldn't they - today, collisions are believed to be recognizable because the cheapest way to craft them results in clear tells).

[1]: https://doc.rust-lang.org/cargo/reference/specifying-depende...

[2]: https://pip.pypa.io/en/stable/topics/vcs-support/#git

[3]: N.B. the "This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository." warning Github has started to add to URLs like that.

Your suitable mailboxes will be very distinguishable by grepping for past triggers per original/unexpanded recipient. Most older destinations would have thousands of non-spam hits, the suitable ones will have 0-3 with an obvious quick fix. For me it was department-level to-whom-it-may-concern aliases: All the mailing lists and web service signups use the appropriate department/employee name, yet much of the incoming mail sent by humans - and: much of the mailing-list-impostors - comes through one of the aliases that merely clarify the topic/location but end up in the same boxes anyway.

> Most of the junk we've been getting passes DMARC and has an unsubscribe link.

You say that like its a problem.. its a formidable solution!

Has worked for me for many years now: Just fail2ban-style block (groups of) relays that attempt to send an unsubscribe-link destined for a mailbox that never ever subscribes to anything. Those malicious-compliance folks add these unsubscribe links everywhere because they determined that its a cheap method for reducing blocks. That makes them reliably stand out whenever they hit strictly human-to-human mailboxes that simply never have any reason to "unsubscribe". Its like a honeypot, and all it took was a strict policy about what a tiny fraction of mailboxes can and cannot be used for.

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.