zlacker

[parent] [thread] 8 comments
1. yencab+(OP)[view] [source] 2022-10-02 21:37:48
What is better for a desktop user:

1) needing to reload a wifi driver to reinitialize hardware (with a tiny probability of memory corruption) OR choosing to reboot as soon as convenient (with a tiny probability of corrupting the latest saved files)

2) to lose unsaved files for sure and not even know what caused the crash

replies(2): >>Jweb_G+f2 >>notaco+RJ1
2. Jweb_G+f2[view] [source] 2022-10-02 21:55:58
>>yencab+(OP)
The latter, because the "tiny probability of memory corruption" can easily become a CVE.
replies(1): >>P5fRxh+Mb
◧◩
3. P5fRxh+Mb[view] [source] [discussion] 2022-10-02 23:02:03
>>Jweb_G+f2
We have a term for this.

FUD

replies(1): >>Jweb_G+gf
◧◩◪
4. Jweb_G+gf[view] [source] [discussion] 2022-10-02 23:31:00
>>P5fRxh+Mb
Linux has numerous CVEs, and a large percentage stem from memory corruption. That's not FUD, I'm afraid.
replies(1): >>scoutt+I11
◧◩◪◨
5. scoutt+I11[view] [source] [discussion] 2022-10-03 07:29:37
>>Jweb_G+gf
It's FUD. And not only that. The fear of constantly being attacked by an external entity is also paranoic.
replies(1): >>Jweb_G+zck
6. notaco+RJ1[view] [source] 2022-10-03 13:30:02
>>yencab+(OP)
Why focus exclusively on the desktop, or over-generalize from it to other uses? What is appropriate for them is not necessarily so for the many millions of machines in server rooms and data centers. Also, you present a false dichotomy. "Lose unsaved files for sure" is not the case for many systems, and "not even know" is not necessarily the case. Logging during shutdown is a real thing, as is saving a crash dump for retrieval after reboot. Both have been standard at my last several projects and companies.

As I've said over and over, both approaches - "limp along" and "reboot before causing harm" - need to remain options, for different scenarios. Anyone who treats the one use case they're familiar with as the only one which should drive policy for everyone is doing the community a disservice.

replies(1): >>yencab+nQ1
◧◩
7. yencab+nQ1[view] [source] [discussion] 2022-10-03 14:02:17
>>notaco+RJ1
Yes, both need to remain options. Rust-in-kernel needs to be able to support both. That's like half of Linus's ranting there.

The other half is that kernel has a lot of rules of what is safe to be done where, and Rust has to be able to follow those rules, or not be used in those contexts. This is the GFP_ATOMIC part.

◧◩◪◨⬒
8. Jweb_G+zck[view] [source] [discussion] 2022-10-09 04:13:55
>>scoutt+I11
Unfortunately, whether you personally care about this sort of thing isn't good enough anymore. Owned Linux boxes on IoT devices are now being marshaled into massive botnets used to perform denial of service attacks, while other vulnerabilities are exploited to enable ransomware. You having negligent security on your own unpatched box because you don't personally feel like it's a good tradeoff has many negative external consequences. Fortunately, the decision isn't actually up to you (and having fewer vulnerabilities won't influence you negatively anyway, so I'm not sure why you're so angry about it).
replies(1): >>scoutt+Mon
◧◩◪◨⬒⬓
9. scoutt+Mon[view] [source] [discussion] 2022-10-10 12:31:58
>>Jweb_G+zck
> why you're so angry about it

Am I?

You suppose a lot of things about me from literaly a bunch of words.

"A 'tiny probability of memory corruption' can easily become a CVE" is still FUD, because is simply not true in most cases. The words "tiny" and "easily" show the bias here.

The rest of the conversation seems a symptom of Hypervigilance: Fixation on potential threats (dangerous people, animals, or situations).

Fortunately, the decision isn't up to you either.

[go to top]