The post made me actually take out the laptop again and maybe use it as a server or something like that in the future and for that I'd use ethernet anyway.

The main thing all those have in common is they are either something I frequently use (all mentioned local IPs) or just stupid easy to remember (DNS servers), neither of which isn't possible for IPv6.

From memory isn't localhost for IPv6 not shorter than for IPv4? The answer is yes, it is ::1 and I was thinking of the Multicast and Link-local address prefixes which are ff00:: and fe80:: respectively.

This seems like a recommendation to just really get to the desktop itself + maybe some light usage. Anything more than that and the "recommendation" is fairly useless with the memory hog of apps that are commonly used.

The main reason I think they are pouring money into Flatpak is because that is the main way to install applications on SteamOS (that aren't games shipped via Steam).

My short search really didn't bring up any definition that included the need of the product/service owner knowning that the advertising is happening.

And the message very much qualifies as trying to bring people to buy raycast (or at minimum to use it which usually want people to also pay later on).

But as indicated by my comment in the specific case for lazy loading, the plugin manager is the wrong place to have it. Regarding its other features I am not sure most of them need to be part of the plugin manager either (at least from the "plugin spec" part) and are better suited as extensions to other parts of core neovim (e.g. options for plugins might need better `vim.{o,g}` support for nested objects, unsure). Maybe specifying nested dependencies might make sense to add to `vim.pack`.

All this to say: yea, now it is more verbose, but it doesn't have to be.

[1]: https://github.com/neovim/neovim/issues/35562#issuecomment-3...

But at that point why even encrypt boot and not use something like a signed UKI for decrypting the rest of the disk? That way at least you only have the kernel, its modules and userspace (the initrd usually being a subset of the actual system) as bug/exploit surface instead of also including GRUB and all its modules ontop of that.

Considering it changes nothing on what they actually work on on systemd I would give this a yes. Every time I hear "they will do this or that" it just never really happened. So far it feels more like "the boy who cried wolf" than "slippery slope" to me. But maybe I am missing something?

A lot of the devs have always here and there added features for secure/measured boot and image based OSes and things that make them more usable to daily drive (hermetic /usr/, UKIs, sysext, portable services, mkosi, DDIs, ...). A lot of the things make image based systems more modifiable/user accessible without compromising on the general security aspect.

If they really wanted to lock in Linux users to a single blessed image from them they would have had a better chance when Lennart was working at Microsoft (which generally is the only preinstalled CA) instead of starting a "competing" company (they are targeting a different niche from what I understand).

Like... they could say they entirely ban agents usage in their repo but how likely is that someone that wants to use them just doesn't contribute because of the policy instead of hiding the usage?

IIRC it also effectively is the same policy as the Linux kernel.

Though the main problem would be that there isn't a "national ID number" everywhere in the world, so the format would be near arbitray.