>[...]

>None of the apps, I repeat, fucking none followed the spec. [...]

>Fun fact: THIS IS STILL THE CASE! The spec advertises a "restore_token" string prop on SelectSources and Start, where no app does this and uses "restore_data" in "options".

Wrong. xdg-desktop-portal has a client API and a compositor API. In the client API the property is called restore_token [1]. In the compositor API the property is called restore_data [2]. Clients do not talk directly to the compositor, they talk to the xdg-desktop-portal application which then talks to the compositor. It is not surprising the the properties would not be called the same.

In the documentation the APIs for app developers and desktop developers are clearly separated on the left hand side [3]. Not only does this have nothing to do with DBus (it would apply to every API where a middleware is used to translate messages), it also shows that the author did not do his due dilligence.

[1]: https://flatpak.github.io/xdg-desktop-portal/docs/doc-org.fr...

[2]: https://flatpak.github.io/xdg-desktop-portal/docs/doc-org.fr...

[3]: https://flatpak.github.io/xdg-desktop-portal/docs/

    please correct them for me. The misinformation has been around for 20 years

    So, if you ever see somebody proposing this

    float a = mix( b, c, step( y, x ) );

    float a = mix( b, c, y > x );

    The variants of mix where a is genBType select which vector each returned component comes from. For a component of a that is false, the corresponding component of x is returned. For a component of a that is true, the corresponding component of y is returned.

All evidence that I have seen suggests that consumers by and large do not care about this kind of privacy. They do not buy iPhones instead of other phones due to the privacy properties.

Therefore Apple's shareholders could order Apple to stay in the UK market.

And if not, then Apple's customers could be compensated with money and other UK-held assets that the government could confiscate.

The asciidoc developers don't seem to consider this an important issue: https://github.com/asciidoctor/asciidoctor/issues/1121

While asciidoc has some nice constructs, this made it a no go the last time I was looking for a documentation language.

One of the advantages of io_uring, unrelated to performance, is that it supports non-blocking operations on blocking file descriptors.

Using io_uring is the only method I recall to bypass https://gitlab.freedesktop.org/wayland/wayland/-/issues/296. This issue deals with having to operate on untrusted file descriptors where the blocking/non-blocking state of the file descriptions might be manipulated by an adversary at any time.

0/0

We shouldn't hope for the impossible.

Never had such an issue before.

>In practice, everything you’re likely to come across will be little endian nowadays, and the ABI you’re using will most likely order your struct from top to bottom in memory, so they will look the same most of the time.

Unfortunately it is not that simple:

https://github.com/mahkoh/repr-c/blob/0c218ac5a6f82034e649fe...

If debian is fine with packaging versions 2.0 and 4.0 but not 0.2 and 0.4, then debian does not understand rust version numbers.

IIRC, one justification for this was to account for systems with non-flat memory where inspecting the value of the old pointer might cause a processor exception.

You'd think that sites choosing wireguard would have a more modern setup and might make heavy use of (self service) ULAs.

  [DHCPv4]
  UseDNS=false
  
  [DHCPv6]
  UseDNS=false