There is no such thing.
Containers are just separated from the rest of your system by cgroups. You can even see the executable running in containers with ps and top. They’re native binaries running on the same kernel as the rest of your system.
Distrobox is not a feature of immutable distros. It runs just fine on Debian. As does flatpak.
Read again. You completely misunderstood.
Yeah, this is the “fun” of bazite. If you want to do the things it does well (desktopy things) it works well. But then things that are trivial in other distros are a pain. And the “solution” is to actually run one of those other distros in a container. It’s ridiculous.
Bazite is for people who want a computer to be like an iPhone near as I can tell.
Flatpak is simply a sandboxed application, similar to a Docker container. Its better to have natively installed applications over sandboxed if you are seeking the highest level of performance.
This is bullshit. Containers run natively on your system just like “native” [sic] applications.
I wouldn’t use arch for anything.
But even without , the arch way isn’t insane either: when something kernel-related breaks, boot with a live system on USB and fix it.
That is not a replacement for “arrow-key down during boot to select an older kernel”.
I have a server with a RAID card and the kernel at some point introduced a bug with the driver that prevented that server from booting. So I select the older kernel at boot, get the system up and running, mark that kernel as the default until the bug is fixed.
It’s not crazy, it doesn’t take long, you just need to know how the system works.
I know how the system works very well thankyouverymuch. But that’s an insane option when having multiple older kernels is so easy to do and common.
That’s… Insanity. Keeping at least one old kernel is amazingly useful if you run into issues with an update.
Don’t feel silly! It’s a common mistake, easy to fix, and easy to make. I’ve seen experienced developers do something similar.
It seems you’ve resolved the issue at this point but remember you can always run commands by specifying their full path as well (should you end up in a similar situation). All the PATH variable does is set the default locations to search when you don’t provide a full path to a binary.
e.g. /bin/ls or /usr/bin/vi
UDP — Blocked. Deprioritized. Dropped. “Security risk.”
It’s this actually a thing? I’ve never seen any corporate network that blocks UDP. HTTP/3 will even rely on it.
Since it’s just to monitor AI agents streaming the text is exactly what they want. You could watch them over a modem.
Ssh port forwarding and socks proxying. Unless they block port 22.
Edit: If they do block port 22 run ssh on port 443.
AI is so much faster than reading docs. And you get context specific responses that you can drill into. When used correctly it’s very useful.
This was using it… incorrectly though…
Different distros vary a bit here, and it will differ if you’re on a system using efi.
Sometimes /boot isn’t mounted by default (it’s not needed unless you’re updating a kernel). You may be seeing a symlink or placeholder there.
If you’re using efi there will probably be /boot/EFI or something where your kernel is stored.
The drive got whipped [sic]
Oh, it was just sitting there and “got wiped”? Not because of a command you ran?
Sorry to be snarky but when asking for help you need to provide what you did, what error message you see now or what you expect to happen and what is actually happening. Also what OS you’re using would be helpful.
Presumably you should be able to get the drive back into a usable state - but I’m not familiar with SAS drives.
Am I the only one who has no idea what their problem is now? Just that there was an error about DIF but… What’s the issue now?
Looks like an ORM? I used to use these a lot but these days I just write SQL. Far too many performance issues and fighting with a library to do what I could just write in SQL in 5 mins. Type safety doesn’t really seem like a big sell here. Most SQL libs already let you “getInt()”.
That’s exactly how people defend something that is a pain.