Biz leaders optimistic it can reduce living, breathing cost centers... er, valued workers
And aggregate demand needed to buy the shit they produce. But that's not this corpo's problem. Not until most corpos are doing it.
avidamoeba
joined 1 year ago
Yeah, I think I can see some other funny cases if there's multiple partitions with separate filesystems on them. Just doing the regular tar/rsync with exclusions is likely safer as it would work for either case.
Because if you're not offline, something is writing to the filesystem and changing blocks while you're copying. If you're lucky what you copied would be outdated. If you're less lucky it would cause fs inconsistency which would be cleaned up by fsck. If you are even less lucky you'd end up with silently corrupted files, e.g. a text file with old parts mixed with new. If you're even less lucky, you'd hit a vital metadata part of the fs and it would not be mountable anymore.
To clarify, the filesystem being block-copied has to be offline or mounted RO, not the whole OS. However if that's the root/home filesystem, then you can't unmount it while the OS is online.
If you don't want to deal with that you need a filesystem or volume manager that supports snapshots, then you can copy the snapshot. E.g. snapshot your root LVM vol, then block-copy the snapshot.
Does --one-file-system prevent the need for excluding /dev, /sys, etc.?
If you want to be able to restore the machine completely, with everything installed and configured, then yes you have to backup everything. There's generally two ways, file-level backup where you'd use something like rsync, tar, etc. and block-level where you'd backup the whole partition/disk using something like dd, clonezilla, etc. The latter is the easiest to restore but it's a bit of a pain to backup because the system generally has to be offline, booted from alternative OS. The forner is a bit more difficult to restore but not by much, and it's so easier to backup. You can do it while the system is live. I'd probably try that first. Find documentation on backing up a complete root filesystem with rsync/tar and you're good to go. Some ideas. It's typically a single command which can be run on a schedule.
The built-in GUI backup tool is generally intended for your own user data. In order to be able to backup other things it'll have to run as root or be given caps and that might get more complicated than using straight rsync/tar.
Definitely don't put everything in a single docker-compose file. For one compose files change from the developer to add/adjust things. You want to make updating to the latest one as easy as copying it over the existing one with minor changes if any, ideally none. For another, you shouldn't rely on running any of it manually. If you want to chuck it in a corner, write some systemd unit files to start and restart the docker compose services for you. Finally, it's not too difficult to find what compose files you have once you've forgotten them. Use docker compose ls, plain docker and if all else fails find, grep, ps. Also you can always write what you did and how to find it in a README.md file. Print it and stick it to the box if you have to. The point is to leave breadcrumbs and be able to follow them, not remember shit you can't possibly remember for a long time.
Read more about docker and compose. They're extremely powerful and some of the most important tools out there. They're also very easy to use but you can't just figure them out beyond the absolute basics, you have to RTFM for how to do things. If something looks difficult, read to see what's the best way to do it. Chances are it isn't. At some point you'd be wondering how you've lived without docker. 😂
They are the only thing running in that container/compose environment. That's one of the main points of containerization! If you need to connect it to something else, like a reverse proxy, have it run in its own compose network and connect the two networks together.
It's an article about Ubuntu 24.04 on an Ubuntu-centric blog. It's looking at that particular OS and whatever the OS uses. It doesn't use KDE and it doesn't use vanilla GNOME. As an Ubuntu 22.04 user who's considering upgrading to 24.04 and is curious what's in it, the fact that PPD is used elsewhere is a mere coincidence. 😊
Good change. Balanced mode being battery-unaware prior to this isn't ideal.
Well this change can't improve anything about Power Saver. It only affects Balanced which now should be a bit less of a gas guzzler.
And yes, even the most aggressive power saving we have at the moment isn't anything to write home about. If we paid 10 developers to hunt down power drain issues and submit fixes for a few years we may get closer to macOS. 😂
We don't. That's why we use multiple layers of security. For example keeping all services accessible only via VPN and using a major OS that a lot of production workloads depend on such as Debian, Ubuntu LTS or any of the RHEL copycats. This is a huge plus of the free tier of Ubuntu Pro BTW. It's commercial level security support for $0. Using any of these OSes means that the time between a vulnerability being discovered, patched and deployed is as short as possible. Of course you have to have automatic security updates turned on,
unattended-upgradesin Debian-speak.