News for hackers. Stuff that matters.
Re:Make Linux Fast Again by kjs3 on Tuesday June 14, 2022 @08:51PM (#31747898)
Oh...can't wait for this to start showing up in production. And, just like every other time 'advice' like this is taken uncritically, when something bad happens the devs will just point at us and say "security problem...all on you" and never face a single consequence. But, hey, they got rid of 'useless' security and some-guy-on-the-Internet said they will get 25% back.
Re:Make Linux Fast Again by fargle on Tuesday June 14, 2022 @11:27PM (#31748798)
Is it a security problem on a single user gaming computer or a laptop?

Generally not.

If your production system is managed competently, I'm certain that there are engineers that can assess risk vs. performance and whether spectre and similar issues warrant those mitigations in your specific environment and make the appropriate design decisions.

If on the other hand your system is managed by "best-practices", distro defaults, and what "some-guy-on-the-internet said", well then you have much bigger problems.

Also, best website ever.

Re:Make Linux Fast Again by mnahkies on Wednesday June 15, 2022 @08:03AM (#31751719)
I'd be interested in some companion material to evaluate the cost/benefit tradeoff here.

My gut says that single user machines it doesn't matter so much, however these same machines probably run a lot of untrusted JavaScript that may be able to exploit things.

A crud rest service receiving requests from the open internet, probably a bad idea to disable mitigations on that machine.

On the other hand, a video transcoder or similar picking tasks off a queue and writing back to storage maybe it's fine? Though I'll admit I'm not sure that there wouldn't be ways to cause (sensitive) data to get into the output file, so would default to leaving everything enabled, especially since the input to transcode would be arbitrary

Re:Make Linux Fast Again by kjs3 on Thursday June 16, 2022 @08:18PM (#31772601)
1) The canonical use case is "steal your login credentials/crypto keys". So yes you have to care about single users, if the single user has access to sensitive info.

2) No, most people (not just engineers) are bad at risk assessment. Like thinking "my single user system shouldn't care about this".

3) I was talking about prod environments, not your random laptop.