Soft

In the former the caller does not retain access to T until Fn returns.

Isn't it still the case that net_cls cgroup is not available with cgroups v2?

This will stop working since kallsyms_lookup_name is no longer exported by recent kernels. See [1].

[1]: https://lwn.net/Articles/813350/

I don't think there are that many situations where it is actually productive to prevent user from selecting and copying text even if it's just part of the UI. To focus on your example, copying user interface text might be useful for users who are not sufficiently proficient in the language that the app/website is written in and would like to copy the text into something like Google Translate. This is especially a problem with many mobile apps that prevent selecting text.

The problem with seccomp is that it operates at the level of system calls. An application could use seccomp to, for example, restrict what system calls it can invoke. However libraries usually consider what system calls they use an implementation detail that can be changed at any time. This forces the application programmer to pay attention to library internals.

I think it is useful for projects to have a searchable unique names. Also, I think the desktop files for those programs also include a generic name describing program's function that an application launcher can decide to show instead.

For example, my KDE application menu refers to applications using these generic description ("Web Browser" instead of Firefox, "Music Player" instead of Spotify).

According to OSI [1], it is not open source if it cannot be used freely in commercial context.

[1]: https://opensource.org/faq#commercial

My understanding is that impl Iterator<Item = i32> in return position means that there is some single concrete type that implements the Iterator trait that we are simply not going to name. This way, the compiler can do dispatching statically. If different paths returned values with different types there wouldn't be just a single type that is known at compilation time. That is why the extra indirection via trait objects is required in the example.

Aside from handling details on how the actual drawing happens, Wayland compositors also dictate how window management is done. Obviosly, there is a lot of room for different designs in that space. Just look at how many different Window Managers there exist for X. My understanding is that wlroots handles a lot of heavy lifting related to drawing and input handling making experimentation with new compositors a lot easier.

Not that I agree with your point, but cyclomatic complexity checks are actually implemented as a compiler plugin in rust-clippy project[1]. You'll get a compile time warning if your function becomes too complex.

[1]: https://github.com/Manishearth/rust-clippy/wiki#cyclomatic_c...

Sure we can secure a certain piece of information if no one has to ever access it. Hard drive in a locked box inside some bunker type of thing. It becomes hard when the information must be easily accessible to multiple persons operating from different places.