|
|
Subscribe / Log in / New account

Much ado about SBAT

Much ado about SBAT

Posted Jul 20, 2023 18:59 UTC (Thu) by willy (subscriber, #9762)
In reply to: Much ado about SBAT by bluca
Parent article: Much ado about SBAT

Given that both Vitaly and Emmanuel have described it as such, you should probably stop defending it as not-such.

eg https://lwn.net/ml/linux-kernel/87wmz33j36.fsf@redhat.com/

Annoying the people who have to apply your patch is not a good start.


to post comments

Much ado about SBAT

Posted Jul 20, 2023 19:16 UTC (Thu) by bluca (subscriber, #118303) [Link] (2 responses)

There is no such description in the mail you quoted. The reality is that the lkml once again lived up to its standards of being an open sewer. There are people there who are lost causes, but there are also those who ought to know better.

Much ado about SBAT

Posted Jul 20, 2023 19:33 UTC (Thu) by willy (subscriber, #9762) [Link]

Once again you critique the mote in their brother's eye without noticing the beam in your own.

Much ado about SBAT

Posted Jul 28, 2023 15:22 UTC (Fri) by jschrod (subscriber, #1646) [Link]

Then, please stop using the same kind of communication here. Your tone is unwanted.

It doesn't help soliciting favorable sympathies either.

Much ado about SBAT

Posted Jul 20, 2023 19:39 UTC (Thu) by Lionel_Debroux (subscriber, #30014) [Link]

FWIW, I did not feel annoyed by the explicit "(This is not yet ready)" which starts the first message of https://github.com/memtest86plus/memtest86plus/pull/34 , and it looks pretty clear that the other maintainers weren't either.

Yes, I'm aware that memtest86+ isn't a general-purpose OS, and that as such, SB bypasses should be very few and very far between, and therefore, SBAT update handling - if ever needed - shall be a non-issue. The Linux kernel is in a different situation, I fully understand it.
However... there is significant contrast between the way this memtest86+ PR went, and the way this LKML thread (which I did not read entirely) went. Enough that one could argue that there may have been a nicer way to handle the situation on LKML, perhaps ?


Copyright © 2025, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds