https://github.com/iorate/ublacklist
I use this, and there exist big lists of sites to block on github.
moonpiedumplings
joined 2 years ago
#1 things holding back Nix adoption is piss poor documentation
The docs are bad because there is this massive split between flakes and nonflakes , where flakes are considered "unstable" and "experimental" but a ton of people use them. The official docs, due to flakes being experimental, can't really touch on that topic at all, and the unofficial docs will mostly be flakes only. And some things can only be done via flakes or only via channels, so that furthers the issue.
There was another discourse post about it, and it was agreed that the nix team just needs to choose something, as the problem is the split and indecisivice, rather than flakss or channels (old way) being uniquely bad.
where Nix “3rd party” tooling shines is in documentation
Determinate systems nix ships with flakes enabled by default. Official nix does not. This means thay determinate nix has a much easier time documenting their product as they exclusively use flakes.
The problem and potential conflict of interest documented in that thread, is that many of the determinate systems employees are big nix contributors with much power over nix official
including Eelco Dostra, the inventor of nix and the creator of flakes. Despite clearly doing recent work with flakes, and clearly contributing to making flakes the "default" in determinate nix, very little effort has been put into making flakes official by these same contributors.
The fear is that nix official is being intentionally kept bad, in order to push the product of determinate systems nix.
[moonpie@osiris ~]$ du -h $(which filelight)
316K /usr/bin/filelight
K = kilobytes.
[moonpie@osiris ~]$ pacman -Ql filelight | awk '{print $2}' | xargs du | awk '{print $1}' | paste -sd+ | bc
45347740
45347740 bytes is 43.247 megabytes. That is to say, the entire install of filelight is only 43 megabytes.
KDE packages have many dependencies, which cause the packages themselves to be extremely tiny. By sharing a ton of code via libraries, they save a lot of space.
The documentation has long since been changed.
Note that the anon user is able to become root without a password by default, as a development convenience. To prevent this, remove anon from the wheel group and it will no longer be able to run /bin/su.
https://github.com/SerenityOS/serenity/commit/a2a6bc534868773b9320ec3ca7399283cf7a375b (this seems to have also switched to gender neutral language in other parts.'of the documentation and comments as well).
Original drama: https://github.com/SerenityOS/serenity/pull/6814
The FSF doesn't seem to have teeth when it comes to things like this, instead it's the SFC who intervenes.
In January, the Software Freedom Conservancy, an open source advocacy group that intervened to help Suhy several years ago, submitted an amicus brief to the Ninth Circuit
Give us your fstab and lsblk.
Or, the specific piece of information I want is where the kernels are located. When /boot is part of the root subvolume (not the default setup, sadly), then the kernels will be snapshpotted along with the rest of the filesystem. /boot/efi would be where the efi system partition is, and where the bootloader is installed.
If /boot is instead the efi parition (default setup lmao), then this means that when you restored a snapshot of your root subvolume, your kernels were not downgraded. I suspect that older kernels attempting to read/view newer kernel modules would cause this boot failure.
If the root account is locked, which cachyos does by default, then you won't get anything from this screen.
I had to fix by usb booting and troubleshooting (a different issue though, I was playing with initramfs generation).
What are you using to view this? Nushell?
Same here.
But it's not plug and play on windows, which I used to demonstrate that windows doesn't always have better hardware support.
I always wonder how Docker works on macOS with a more UNIX-style kernel than Linux
It doesn't. Macos also uses a virtual machine for docker.
but is it really that hard to do Docker/OCI out of Linux?
Yes. The runtimes containers use are dependent on cgroups, seccomp, namespaces, and a few other linux kernel specific features.
You could implement a wine like project to run the linux binaries that containers contain, and then run some sandboxing to make it be a proper container, but no virtual machines or virtual machine container runtimes* are easier.
Linuxulator, a freebsd project does the above.
https://people.freebsd.org/~dch/posts/2024-12-04-freebsd-containers/
*these are much lighter than a normal vm, I'll need to check if this is what macos does. I know for a fact docker on windows uses a full Linux vm though.
Because one of the features of Linux that Microsoft is most interested in is docker/oci containers, but that is a feature specific to the Linux kernel (and thus requires a virtual machine).
It's not just protection against security, but also human error.
https://github.com/MrMEEE/bumblebee-Old-and-abbandoned/issues/123
https://hackaday.com/2024/01/20/how-a-steam-bug-once-deleted-all-of-someones-user-data/
Just because I trust someone to write a program in a modern language they are familier in, doesn't mean I trust them to write an install script in bash, especially given how many footguns bash has.