With Docker, the internal network is just a bridge interface. The reason most firewall rules don't apply is a combination of:

• Containers have their own namespace including network namespace, so each container have a blank iptables just for them.
• For container communication, that goes through the FORWARD table, not the INPUT/OUTPUT ones.
• Docker adds its own rules to ensure that this works as expected.

The only thing that should be affected by the host firewall is the proxy service Docker uses to listen on a port on the host and send it to the container.

When using Docker, each container acts like an independent machine, and your host gets configured to act as a router. You can firewall Docker containers, the rules just need to be in the right place to work.

The sandboxing is almost always better because it's an extra layer.

Even if you gain root inside the container, you're not necessarily even root on the host. So you have to exploit some software that has a known vulnerable library, trigger that in that single application that uses this particular library version, root or escape the container, and then root the host too.

The most likely outcome is it messes up your home folder and anything your user have access to, but more likely less.

Also, something with a known vulnerability doesn't mean it's triggerable. If you use say, a zip library and only use it to decompress your own assets, then it doesn't matter what bugs it has, it will only ever decompress that one known good zip file. It's only a problem if untrusted files gets involved that you can trick the user in causing them to be opened and trigger the exploit.

It's not ideal to have outdated dependencies, but the sandboxing helps a lot, and the fact only a few apps have known vulnerable libraries further reduces the attack surface. You start having to chain a lot of exploits to do anything meaningful, and at that point you target those kind of efforts to bigger more valuable targets.

You can't, at that point you assume your correspondent is compromised. It's not just recall but also malware and credential stealers. Doesn't matter if recall is taking screenshots, if the messaging client itself is pwned via malware then they have full access to as much history as is available.

The problem with a different spoof for each domain is that this behavior on its own can be used as a fingerprint based on timestamp and IP in access logs.

Hiding among the crowd is probably better, especially since newer versions of Chrome all report the same UA you blend in even more.

You can block them and over time it should get better, or you can write a script that does some checks and blocks them for you.

Also, series F but they're only deploying on one server? Try scaling that to a real deployment (200+ servers) with millions of requests going through and see how well that goes.

And also no way their process passes ISO/SOC 2/PCI certifications. CI/CD isn't just "make do things", it's also the process, the logs, all the checks done, mandatory peer reviews. You can't just deploy without the audit logs of who pushed what when and who approved it.

No, if you deleted the btrfs driver it would simply fail to mount due to the missing driver, if it's a separate module in the first place. Same with LUKS, if you don't have the tools or the drivers installed for it, it'll just not mount it. You'd have to be accessing the drive directly with something like dd to corrupt it.

Yeah, I used to not block ads but they're so invasive these days. If 2 banner ads pop on at the top and bottom of the screen with a full screen app on top with ads between every paragraph and a PIP video ad on top, yeah, I don't even bother reading the article.

And I sure as hell am not subscribing to a $10/mo subscription because someone linked to a paywalled article either. It's so crazy those sites just assume every visitor is a recurring visitor that might subscribe. Definitely wish there was some sort of micropayment thing, like pay 25 cents to view it or something.

My point was really that data can't be that exensive even with including transit fees like Cogent and Level3, because I can use TBs of bandwidth every month and OVH doesn't even bother measuring it.

If my home ISP gives me a gigabit link, yes I pay for all the cabling and equipment to carry that traffic. But that's it, I already pay for infrastructure capable of providing me with gigabit connectivity. So why is it that they also want me to pay per the GB?

In Europe they can provide gigabit connectivity for dirt cheap with no caps, they don't even bother with tiered speed plans there, how come my $120+/mo Internet in the US isn't sufficient to cover the bandwidth costs? It's ridiculous, even StarLink doesn't have data caps.

But somehow communities with crappy DSL that can barely do 10 Mbps still have ridiculously low data caps. It's somehow not a problem for most ISPs in the world, except US ISPs, the supposedly richest and most advanced country in the world.

Yeah sure, then why is it that my entire bare metal server leased from OVH costs less than my Internet connection, and is fully unmetered access too.

I pay for a data rate and I should be able to use the full amount as I please. If we paid for the amount of data then why are we advertising speeds and paying for speeds?

The error says /home is a symlink, what if you ls -l /home?

Since this is an atomic distro, /home might be a symlink to /var/home.

Docker, Distrobox, Toybox, systemd-nspawn, chroot.

Technically those all rely on the same kernel namespace features, just different ways to use it.

That's also what Flatpaks and Snaps do. If you only care about package bloat, an AppImage would do too but it's not a sandbox like Flatpak.

auto rollbacks and easy switching between states.

That's the beauty of snapshots, you can boot them. So you just need GRUB to generate the correct menu and you can boot any arbitrary version of your system. On the ZFS side of things there's zfsbootmenu, but I'm pretty sure I've seen it for btrfs too. You don't even need rsync, you can use ssh $server btrfs send | btrfs recv and it should in theory be faster too (btrfs knows if you only modified one block of a big file).

and the current r/w system as the part that gets updated.

That kind of goes against the immutable thing. What I'd do is make a script that mounts a fork of the current snapshot readwrite into a temporary directory, chroot into it, install packages, exit chroot, unmount and then commit those changes as a snapshot. That's the closest I can think of that's easy to DIY that's basically what rpm-ostree install does. It does it differently (daemon that manages hardlinks), but filesystem snapshots basically do the same thing without the extra work.

However, I think it would be good to use OStree

I found this, maybe it'll help: https://ostreedev.github.io/ostree/adapting-existing/

It looks like the fundamental is the same, temporary directory you run the package manager into and then you commit the changes. So you can probably make it work with Debian if you want to spend the time.

All you really have to do for that is mount the partition readonly, and have a designated writable data partition for the rest. That can be as simple as setting it ro in your fstab.

How you ship updates can take many forms. If you don't need your distro atomic, you can temporarily remount readwrite, rsync the new version over and make it readonly again. If you want it atomic, there's the classic A/B scheme (Android, SteamOS), where you just download the image to the inactive partition and then just switch over when it's ready to boot into. You can also do btrfs/ZFS snapshots, where the current system is forked off a snapshot. On your builder you just make your changes, then take a snapshot, then zfs/btrfs send it as a snapshot to all your other machines and you just boot off that new snapshot (readonly). It's really not that magic: even Docker, if you dig deep enough, it's just essentially tarballs being downloaded then extracted each in their own folder, and the layering actually comes from stacking them with overlayfs. What rpm-ostree does, from a quick glance at the docs, is they leverage the immutability and just build a new version of the filesystem using hardlinks and you just switch root to it. If you've ever opened an rpm or deb file, it's just a regular tarball and the contents pretty much maps directly to the filesytem.

Here's an Arch package example, but rpm/deb are about the same:

max-p@desktop /v/c/p/aur> tar -tvf zfs-utils-2.2.6-3-x86_64.pkg.tar.zst 
-rw-r--r-- root/root    114771 2024-10-13 01:43 .BUILDINFO
drwxr-xr-x root/root         0 2024-10-13 01:43 etc/
drwxr-xr-x root/root         0 2024-10-13 01:43 etc/bash_completion.d/
-rw-r--r-- root/root     15136 2024-10-13 01:43 etc/bash_completion.d/zfs
-rw-r--r-- root/root     15136 2024-10-13 01:43 etc/bash_completion.d/zpool
drwxr-xr-x root/root         0 2024-10-13 01:43 etc/default/
-rw-r--r-- root/root      4392 2024-10-13 01:43 etc/default/zfs
drwxr-xr-x root/root         0 2024-10-13 01:43 etc/zfs/
-rw-r--r-- root/root       165 2024-10-13 01:43 etc/zfs/vdev_id.conf.alias.example
-rw-r--r-- root/root       166 2024-10-13 01:43 etc/zfs/vdev_id.conf.multipath.example
-rw-r--r-- root/root       616 2024-10-13 01:43 etc/zfs/vdev_id.conf.sas_direct.example
-rw-r--r-- root/root       152 2024-10-13 01:43 etc/zfs/vdev_id.conf.sas_switch.example
-rw-r--r-- root/root       254 2024-10-13 01:43 etc/zfs/vdev_id.conf.scsi.example
drwxr-xr-x root/root         0 2024-10-13 01:43 etc/zfs/zed.d/
...

It's beautifully simple. You could for example install ArchLinux without pacman, by mostly just tar -x the individual package files directly to /. All the package manager does is track which file is owned by which package (so it's easier to remove), and dependency solving so it knows to go pull more stuff or it won't work, and mirror/download management.

How you get that set up is all up to you. Packer+Ansible can make you disk images and you can maybe just throw them on a web server and download them and dd them to the inactive partition of an A/B scheme, and that'd be quite distro-agnostic too. You could build the image as a Docker container and export it as a tarball. You can build a chroot. Or a systemd-nspawn instance. You can also just install a VM yourself and set it up to your liking and then just dd the disk image to your computers.

If you want some information on how SteamOS does it, https://iliana.fyi/blog/build-your-own-steamos-updates/

More information about storing electrons and light and other information like with most likely aliens abducting and exploiting people as a resource in a text document called “Information about totalitarian and manipulative aliens.odt”, also with picture in the post perhaps also prove these aliens are real:

That's more like cocaine and meth levels than Adderall at this point

Then those can pay the $10/mo for the cellular based version. Or even then, one could just... provide their own SIM, if only they'd let you. Most carriers let you have an extra data only SIM to your line for fairly cheap for iPads and laptops, why not for your car?

The thing was deliberately engineer such that paying them is the only option. And those servers will inevitably get shut down at some point, making it all useless anyway.

Why does the government keep trying to regular fake Internet money? The whole point of it was that it was a free for all. Who the fuck cares if crypto bros get fucked, if you want real securities you go to a real bank and open a real investment account.

I'm talking about the new one they made from scratch in Rust: https://system76.com/cosmic

Counter argument to that is, it would suck to be unable to reinstall your OS because it can't load a text file.

It's instance dependent and likely small on bigger instances to reduce storage costs as it can grow really big. I don't know the exact number for lemmy.ml.