When in doubt - C4!
When in doubt - C4!
I don’t think that’s what ‘market share’ is trying to represent, but without any context - yeah. You can lump in android phones and set-top boxes and signage and industrial controllers while you’re at it.
Is OP adding the Android share to Linux? That would certainly do it.
Only makes sense if you know their definition of ‘Linux’ though.
I think you’d only have to read it once, then you should be able to just filter it out next time you see it.
- Sent from my iPhone
Why use separate partitions over subvolumes within btrfs?
Well at that point, just don’t install any kernel mode EDR software at all.
NixOS can be set up for impermanence where all config is recreated every boot and nothing persists besides the nix store. There’s helpers for ephemeral home also, so you can have something like TailsOS. I’m sure you could do that with other distros but you’d need absolute discipline to have everything the machine needs provisioned at boot.
I think having an A partition and a B partition (I’m assuming that’s how SteamOS works) wouldn’t help in this case. If the A partition downloaded the definition file, crashed and failed to reboot; the bootloader could failover to the B partition - which would then download the definition file, crash and fail to reboot. It would have to keep rolling back to a last known good snapshot until the update got withdrawn.
You could have an ephemeral set up that wipes /var
and /etc
and recreates them every boot. I don’t think these EDR tools would like that very much though.
Yeah, you’d need to snapshot their data directory and roll that back. The previous kernel module may well have had the bug already, just not a malformed config file to trip it.
Also, if the driver booted ok, but then panicked soon after, would that count as a bad boot? The description seems to indicate the boot counters get reset as soon as a boot succeeds.
It’s not that clear cut a problem. There seems to be two elements; the kernel driver had a memory safety bug; and a definitions file was deployed incorrectly, triggering the bug. The kernel driver definitely deserves a lot of scrutiny and static analysis should have told them this bug existed. The live updates are a bit different since this is a real-time response system. If malware starts actively exploiting a software vulnerability, they can’t wait for distribution maintainers to package their mitigation - they have to be deployed ASAP. They certainly should roll-out definitions progressively and monitor for anything anomalous but it has to be quick or the malware could beat them to it.
This is more a code safety issue than CI/CD strategy. The bug was in the driver all along, but it had never been triggered before so it passed the tests and got rolled out to everyone. Critical code like this ought to be written in memory safe languages like Rust.
I’d unsubscribe from !linux@lemmy.ml for a start.
I’m pretty sure this update didn’t get pushed to linux endpoints, but sure, linux machines running the CrowdStrike driver are probably vulnerable to panicking on malformed config files. There are a lot of weirdos claiming this is a uniquely Windows issue.
Is there any reason to keep the existing set-up? If it’s just one drive, you could replace it with another and install Alma or something fresh. Then you could copy over whatever config the old system had to get up and running again. You could swap to the old drive if you needed to revert. If you have a spare machine, you could stand up the fresh setup side-by-side with the old one before swapping over.
I find it odd, because venv is a “Suggested package”, actually. It isn’t in the list of new packages that will be installed with python3 by default.
I think the next major release of apt is supposed to be easier to read. Unless Debian neuter it.
I mean, we have systemd-bsod now…
Not that I’ve ever seen it of course.
Ah, that’s the misunderstanding. The original comment was talking about “watching something on another pc”. Like playing a video from a desktop PC on a laptop in another room. So it’s the samba server we want to prevent from sleeping, not the client. Yes it’d be nice to have a 24/7 media server set up, but for the simple case of sharing a file from one PC to another, it’d be nice for the server not to sleep in the middle of it by default.
For sure, I don’t know the internals of Samba, but surely the server knows that it’s serving a file no matter how the client accesses it. I don’t think a few dbus messages would cause issues.
I have my own service that looks at the network traffic via /proc and a few other things. That sends the system to sleep itself if everything looks truly idle.
I do think it would be nice for a file server like samba to inhibit sleep using the standard interface for it. But yeah, I appreciate there are complications, like video playback is presumably pulling a small extent of a file at a time, so there would have to be some kind of timer before releasing the inhibition or the system would sleep between transfers.
EDIT: I just took a look; with loglevel set to 3 for smb and smb2 I see log messages like:
smbd_smb2_read: fnum 1712966762, file my_video.mkv, length=262144 offset=82366464 read=262144
These occur at most 10 seconds apart when playing a video over a share from another host. I don’t see why the smbd daemon couldn’t inhibit sleep untill smbd_smb2_read hasn’t run for a minute or so. You could have a script that monitors that log output and does this externally but it’d be nice to have built in.
Not every program or service on your system
Of course not, but plenty do when running a task where the user is unlikely to make inputs and also doesn’t want the machine to sleep. Firefox can call org.gnome.SessionManager.Inhibit over dbus with the “video-playing” description, same for VLC. Transmission can call that interface while a transfer is in progress (with a config toggle). It seems a pretty reasonable default for samba to do the same while a long-running file transfer is ongoing.
[Samba] doesn’t copy your files for you.
Sure but it has to know when a transfer is running. It would be nice to have the option to inhibit sleep if the transfer is runs for a significant amount of time.
It should use systemd-inhibit (or whatever the dmesg dbus service is) to tell the system it’s busy. How else would the system know?
Have you tried
sfc /scannow
?