The reason that it took so long to find was that the cross-section of production is very low, the decay signatures are hard to separate from the background, the specific energy scale it existed at was not well-defined, and building the LHC was (to put it mildly) difficult and expensive.
Roughly, if you'll forgive a bad analogy from a long-lapsed physicist, it was the equivalent of trying to find a very weak glow from a specific type of bug hiding at an unknown location in a huge field of corn. Except that your vision was very bad, so you had to invent a new type of previously-unimaginably excellent eyeglasses to see the thing. Also before you could even start looking you had to expend a painful amount of time and money building a flashlight so incredibly huge that it needed new types of cryogenic cooling inventing, just to stop it from melting when you switched it on.
If you had a software bug that you were almost certain was there, but you needed half of the world's GPU clusters for three years to locate and prove it, then that would be a Higgs-Bugson.
"NFS is lot like heroin:
at first, it seems amazing.
But then it ruins your life"
(This is a place that did almost EVERYTHING via NFS including different applications communicating via shared files on NFS mounts. It also had the weird setup of using BOTH Linux AND Windows permissions on NFS mounts shared between user desktops [windows] an servers [linux])
The fact that the development team is globally distributed both necessitates this kind of knowledge serialization and preserves it for posterity. It's completely different from tapping a colleague sitting next you on the shoulder, and saying "psst, can you approve this quick? It's just a bunch of fixes".
- https://docs.kernel.org/process/submitting-patches.html#desc...
- https://github.com/torvalds/linux/blob/master/Documentation/...
- https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...
Git's own guidelines also have a nice description on how to write a better commit message:
- https://git-scm.com/docs/SubmittingPatches
- https://github.com/git/git/blob/master/Documentation/Submitt...
- https://git.kernel.org/pub/scm/git/git.git/tree/Documentatio...
>NFS with Kerberos
secure, simple, battle tested. no crazy architecture
works so well a bug showed up in the kernel :-)
What exactly are you trying to highlight here? Most code has bugs. This one is someone forgetting to stick to actual behavior described in 1997, it's a mistake, mistakes happen. Which one of "secure", "simple", "battle tested" and "no crazy architecture" do you think this disproves?
Or do you think CIFS or Ceph have no bugs?
I don't think they're being snarky.
I know, not directly related to the article. Just needed to vent bitterly.
Look at all the syzbot automation on the kernel mailing list, as an example of how the process continues to improve.
IMHO the best Linux experience really is to run bleeding edge versions of everything. I wasted a great deal more time backporting patches before I started doing that, than I have spent chasing new bugs since.
NFS can be run over TCP or UDP. Does the retransmission occur when using UDP?
Weirdly enough this also means that if you’re running with TCP you can have retransmits at the NFS/SunRPC level and at the TCP level depending on your configuration.
This was the first time I heard of "higgs-bugson". The term sounded so forced that I had to know how it differed from Heisenbug. In short, it doesn't[1].
Then why did it even exist?
The term somehow made it to the "Heisenbug"'s Wikipedia page[1], so I checked the sources. There were two and both end up at the same site: Jeff Atwood's blog post[2] quoting some StackOverflow answers to a poll-like question ("what's a programming term you coined?") because he wanted to remove lighthearted content from the site as he thought it clashed with SO's mission of educating people and advancing their skills[3].
There was a proposal on Meta StackExchange about undeleting that question with the answers, but it was refused by Jeff Atwood again because it invited "made up stuff"[4] among other reasons.
So, Wikipedia in the end, has this term in Heisenbug page because someone just blurted out something in 2010, it was copy-pasted to a blog, and then got scooped up by some news outlet. There are no other sources. Kagi doesn't find any instances of the term before it was coined on StackOverflow in 2010. For all we know, "gingerbreadboy" from England invented it.
The irony is that the term somehow made it to the literature -hence the blog post here- because someone was just having fun at StackOverflow. It obviously either sounded good, or just clicked that others started using it. StackOverflow deleted the content that actually made a small part of computer science history because it wasn't "serious".
In other words, StackOverflow cut off one of its history-making parts because it had an incomplete and simplistic view of useful. I think it might be possible to draw a line from their understanding of communities and societal dynamics to the downfall of StackOverflow after the emergence of AI[5].
[1] https://en.wikipedia.org/wiki/Heisenbug
[2] https://blog.codinghorror.com/new-programming-jargon/
[3] https://stackoverflow.blog/2010/01/04/stack-overflow-where-w...
[4] https://meta.stackexchange.com/questions/122164/can-we-un-de...
[5] https://blog.pragmaticengineer.com/stack-overflow-is-almost-...
No; he wanted to remove discussion and socialization, because it clashed with SO's mission of presenting useful information without parsing through others' discussion.
https://meta.stackexchange.com/questions/2950
https://meta.stackexchange.com/questions/19665
https://meta.stackexchange.com/questions/92107
https://meta.stackexchange.com/questions/131009
> In other words, StackOverflow cut off one of its history-making parts because it had an incomplete and simplistic view of useful.
How does this in any way demonstrate that the view of usefulness was "incomplete" or "simplistic"?
How is the deleted content "useful"?
> I think it might be possible to draw a line from their understanding of communities and societal dynamics to the downfall of StackOverflow after the emergence of AI[5].
What downfall?
Before you point at any of the incoming-question-rate statistics: why should they be interpreted as representing a "downfall"? That is, why is it actually bad if fewer questions are asked?
Before you answer that, keep in mind that Stack Overflow already has more than three times as many publicly visible questions about programming as Wikipedia has articles about literally anything notable.
I agree, but also SO has certainly gone through ups and downs. It does feel as though it's now in a terminal "down" having invested its limited resources in things lots of the dedicated members didn't seem to want, instead of basic improvements to moderation and to chat features.
- a Heisenbug is stochastic and potentially non-local, but
- a Higgs-Bugson is a bug that is known to exist (in prod) but is extremely hard to observe in the lab (during dev/testing).
I can see it being a useful distinction. A bug that I can't even reproduce at all sits in a different ring of hell from, say, a memory corruption bug that makes the program crash on random unrelated lines of code.
Worse yet, the kernel runs in supervisor mode.
This kernel design is bankrupt. There's much better available, such as seL4+Genode.
Absolutely. And yet, it is that much easier to keep a tiny codebase bug-free.
And only that tiny codebase has to run with supervisor privileges.
I am sure that the tech community would love to read the details of your great success in deploying microkernels for large variety of production workloads.
Microkernels have severe limitations when it comes to transactional boundaries of calling multiple subsystems and rolling back on failure.
Linux has too much inertia to reinvent itself instantly or completely into XYZ.
What would add more value would be gradual conversion to Rust and adding formal verification to C and Rust like specifying invariants in comments/metadata like frama-c and/or flux.
PS: Religious judgement opinion wars are rarely constructive.
