> I hope this philosophy do not reach the Linux kernel.
Well, I hope it does. Albeit it almost certainly will not, because Linus is opposed to it. But ever since I read Joe Duffy's blog posts on the Midori research project at MS, I have been convinced that using panics leads to increased reliability, not decreased. From his blog[1]:
"Given that bugs are inherently not recoverable, we made no attempt to try. All bugs detected at runtime caused something called abandonment, which was Midori’s term for something otherwise known as “fail-fast”."
And:
"Abandonment, and the degree to which we used it, was in my opinion our biggest and most successful bet with the Error Model. We found bugs early and often, where they are easiest to diagnose and fix."
I think that the Midori team's work shows that a practice of "there's a bug, stop everything" leads to more reliable software. Sure, there's an initial period of pain where you're fixing a ton of bugs as they cause the software to panic. But you reap the rewards of that effort. I don't think Linux will ever move towards a model like this, but I think it would be beneficial in the end if they did.
All these people giving recs are doing it wrong. You can determine if an anime is worth your time by merely looking at the title and what the source material is and the following simple system:
Candidates start with 5 points. If they have a positive score after applying the system, they're at least worth checking out (although they will not necessarily be good). If not, you are likely wasting your time.
1) Every word in the title past the third is worth -1 point. This includes particles and abbreviations.
2) Each word in the subtitle is worth -0.5 points.
3) Any of the following words or close synonyms are worth -2 points on top of any other penalties:
Academy, Ability, Cheat, Dungeon, Elf, Game, Goblin, Harem, Hero, Idol, Isekai, Level, Loop, Maou, MMO, Mob, Online, Overlord, Party, Player, Re(used as a prefix), Reincarnation, "The Animation"(verbatim only), Vampire, Villainess, Virtual, VR, VTuber, Wizard
4) Subtract an additional point for every word that implies this is a remake, spinoff, adaptation or sequel, such as "Kai", "Gaiden", "2nd" (3rd, etc.), "New", et cetera.
5) Even though you already subtracted a point for "Isekai" in step 3. If the title contains the word "Isekai", subtract an additional 5 points.
6) Apply the following adjustment based on the source material:
History: +3 (Applying only to direct adaptations of historical events, not merely using historical theming)
Literary Fiction: +2
Original Work: +1
Other: +1
OVA: +0.5
Live Action: +0
Web Animation/Motion Comic/Music Video: +0
Comic: +0
Video Game: -1
Light Novel: -1
Writeup of someone's D&D session: -1
CCG: -2
Web Novel: -5
Mobile Game: -10
"Multimedia Project" (This is just a mobile game that doesn't exist yet): -10
Social Media Post: -100
The right kind of mitigations targets the 1st order primitive; the root cause of the bug.
Hardware solutions: CHERI (Morello, CheriIoT), MTE
Software mitigations: kalloc_type+dataPAC, AUTOSLAB, Firebloom, GuardedMemcpy, CastGuard, attack surface reduction
Safe programming languages: Rust, Swift
MTE/CHERI play pretty nicely - they help ensure that whatever bugs we have in these areas are killed at their root cause… MSR, MSRC and Azure Silicon pushed for… scaling CHERI down to RISC-V32E, the smallest core RISC-V specification.
CHERI-based microcontroller that aims to… get very strong security guarantees if we are willing to co-design the instruction set architecture (ISA), the application binary interface (ABI), isolation model, and the core parts of the software stack… our microcontroller achieves the following security properties:
Deterministic mitigation for spatial safety (using CHERI-ISA capabilities).
Deterministic mitigation for heap and cross-compartment stack temporal safety (using a load barrier, zeroing, revocation, and a one-bit information flow control scheme).
Fine-grained compartmentalization (using additional CHERI-ISA features and a tiny monitor).
> There are around 13 billion lines of open source C and C++, which end up in various TCBs. This number gets even bigger when you include proprietary code… if we all stopped writing C/C++ code now and every software engineer focused on rewriting legacy code in safe languages (and on the assumption that everything can be written in safe languages) then it would take 5-10 to replace everything and we’d likely see a lot of logic bugs because we’d be replacing old well-tested code with new code that would need different algorithms and data structures to fit with allowable idioms in safe languages.
> If we didn’t do the rewriting thing and just stopped writing code in C/C++, then at normal code replacement rates, our TCBs would be entirely safe in around 50 years. If we don’t all agree to stop writing C/C++, it’s at least 100 years.
> In contrast, if the major CPU vendors shipped CHERI CPUs in five years, most machines (and all high-value ones) would have memory safety within 15 years of today, without needing programmers to change their behaviour.
My sister in law writes recipes. She has a recipe column in a newspaper and wrote a few high quality recipe books. I saw them in a bookstore. So she's reasonable successful. Her pieces are charming, her recipes inspiring.
The thing is. At a birthday party when I was talking to her, she confessed to me that she never actually tries her recipes. When it's time to do a new piece, she sits down at her computer and makes up a recipe. She is experienced and knowledgeable she it usually turns out ok. But if you make her recipe you may well be the first one to do it. What is worse, she claims that virtually all recipe books are made like this.
So if you cook from a recipe you'll have to adjust to realities and modify it were needed, because the recipe writer sure as hell didn't do it for you.
Well, I hope it does. Albeit it almost certainly will not, because Linus is opposed to it. But ever since I read Joe Duffy's blog posts on the Midori research project at MS, I have been convinced that using panics leads to increased reliability, not decreased. From his blog[1]:
"Given that bugs are inherently not recoverable, we made no attempt to try. All bugs detected at runtime caused something called abandonment, which was Midori’s term for something otherwise known as “fail-fast”."
And:
"Abandonment, and the degree to which we used it, was in my opinion our biggest and most successful bet with the Error Model. We found bugs early and often, where they are easiest to diagnose and fix."
I think that the Midori team's work shows that a practice of "there's a bug, stop everything" leads to more reliable software. Sure, there's an initial period of pain where you're fixing a ton of bugs as they cause the software to panic. But you reap the rewards of that effort. I don't think Linux will ever move towards a model like this, but I think it would be beneficial in the end if they did.
1: https://joeduffyblog.com/2016/02/07/the-error-model/#bugs-ar...