Many modern laptops no longer support S3 sleep at all. It is likely to be an issue with the bios rather than a linux project. On my laptop, with Ryzen 7 5825U, I had to give up on S3 and use s2idle. Also had to pass "pcie_aspm=off" as a kernel parameter because it would take ages to wake the ssd without it. Overall works ok. Not as good as S3 but better than nothing.
So to check what suspend states your laptop supports run cat /sys/power/mem_sleep. It should print something like s2idle shallow [deep] with the option that is enabled having [] around it. To change the enabled option run echo "s2idle" > /sys/power/mem_sleep. https://wiki.archlinux.org/title/Power_management/Suspend_and_hibernate has more info.
I haven't really noticed much of a difference. I figured it was probably worth actually being able to wake the laptop from sleep rather than having to restart it every time.
For fun and learning. It’s just another tool to go with file level backup.
And the backup for this is 40mb and really fast, but backing up files even when compressed would be hundreds of GB, maybe terabytes, and then you’re paying for that amount of storage online somewhere, uploading for hours…
Picture this: you open and edit one of your documents and save it.
The filesystem promptly allocates some blocks and updates the inodes. Maybe the inode table changed, maybe not. Repeat for some other files. Now your “inode backup” has a completely different picture of what is going on on your disk. If you try to recover the disk using it, all you will achieve is further corruption of the filesystem.
For example once I had a bad cable, and it did a kinda sneaking silent damage. Let’s say 5 or 50 broken files every day. And only after some weeks I noticed some of them, and there was hardly a chance to identify them each day. And sometimes there was damage to the file system, too. It took a while find the root cause.
Today I use ZFS with redundancy and it does the recovery all by itself and my sleep is so much better :-)
“Proper backups” imply that you have multiple backups and a backup strategy. That could mean, for instance, that you would do a full backup, then an incremental/differential backup each week and keep one backup for each month. A bad cable would cause you trouble, no doubt, but the impact would be lessened by having multiple backups points spread over months.
Redundancy is not backup. Read that again.
Redundancy is important for system resilience, but backup is crucial for continuity. Every filesystem is subject to bugs and ZFS is not special. Here’s an article from a couple of days ago. If you’re comfortable with no backups just because you have redundancy, more power to you. I wouldn’t be.
Sure, all the work you do between the moment of the filesystem failure and the last backup is gone. There’s nothing that can be done to mitigate that fact, other that more frequent backups and/or a synchronized (mirror) system.
Backups are just a simple way to keep you from having to explain to your partner that you lost all the pictures and videos you took along the years.
There was a time when Nixpkgs was smaller than the AUR. And, until recently, Nixpkgs was larger than the AUR but still smaller than the combination of the main Arch repos with the AUR.
As it turns out, the current total package count for Arch and the AUR is 85,819.
For nixpkgs unstable, that number is 88,768.
NixOS 23.05 Stable has 83,740.
And considering the mention of 9,147 new packages and 4,015 removed packages, that would mean that 23.11 would have a total of:
88,872 packages. This is more than the current figures for Nixpkgs unstable, but this is going off data from separate sources (NixOS devs and repology, with repology still being slightly outdated)
And, as such, I think it’s fair to say the winner is (drumroll please)…
The USER for having such incredible distributions, giving him the vast breadth of choice for what distro matches their workflow best.
To be fair, the level of support for packages in nixpkgs is inconsistent. My config has a number of backported packages overlaid on top of nixpkgs where upstream is not up to date enough for me.
Package count is interesting to look at, but it doesn’t really give a good picture of software availability. Distributions will split or combine packages differently. For example, the AUR has both binaries and source versions available for many packages.
Firejail has some big security flaws. There us bubblejail, which uses the way better bubblewrap also used for Flatpaks.
But the Bubblewrap and Flatpak Situation is quite complex. Flatpaks, as well as Podman containers, require user namespaces. Through these namespaces programs can get privileged access to system components, which is why secureblue now has bubblewrap-suid installed.
bubblejail maybe uses that binary already, or it needs to be patched too.
To add to this systemd can do everything they can. You can isolate network, do fire-walling, and sandboxing pretty easily. Any OCI container can be used too if you don’t want to install something too.
I don't know what's worse, that this is real or that it appears to be relatively serious and not just taking Ubuntu and doing an UwU text transform on every localized string.
Oh, I have no issues with pony people. I was more disappointed that UwUntu wasn't as UwU as I really hoped it would be after I discovered it was a real thing.
At some level I just wanted it to commit to the bit, even if it's at the cost of usability. Maybe only on 1 Apr or something.
linux
Oldest
This magazine is from a federated server and may be incomplete. Browse more on the original instance.