Since when? To me, anything not webview-based is native, though you have varying degrees of integration into the platform.

>Getting any example application to work is so incredibly ridiculous, that every second I program on Wayland, I yarn for the times I did Win32 programming.

And that comes from the core of how Wayland is designed.

In Win32, the stable interface / ABI is the set of C functions provided by the operating system through DLLs. These are always dynamically loaded, so Microsoft is free to change the internal interface used for controlling windows at any time. Because of this, decades-old .exes still run fine on Windows 11.

In Wayland, the stable interface is the binary protocol to the compositor, in addition to the libwayland-client library plus extensions. Instead of that socket being an "implementation detail", it's now something that all programs that just want to make a window have to deal with. You also can't just use the socket and ignore the libwayland libraries, because mesa uses libwayland-client and you probably want hardware acceleration.

The other big issue is the core Wayland protocol is useless; you have to use a bunch of protocol extensions to do anything, and different compositors may implement different versions of them. On Win32, Microsoft can just add another C function to user32.dll and you don't have to think about protocol how that gets transformed into messages on the socket layer, or compatibility issues with different sets of extensions being supported by different compositors.

https://github.com/FFmpeg/FFmpeg/blob/master/libavformat/udp...

https://github.com/search?q=IPPROTO_UDPLITE&type=code

https://github.com/tormol/udplite

https://github.com/nplab/packetdrill

https://github.com/python/cpython/blob/4e96282ee42ab51cf325b...

https://github.com/search?q=repo%3Aviveris%2Frohc%20udplite&...

It does indeed, but they are not compatible and at least the C atomics cannot be used from C++.

>C++ also has it's own designated initializer like syntax.

One that is far more limited. This is valid C, but not C++.

  struct bar {
      int a;
      int b;
  };
  
  struct bar tmp = {
      .b = 0,
      .a = 0,
  };

Ultimately, what difference does it make? The file explorer in Windows 10 is much faster than the one in Windows 11, and it's very noticeable. Turn on the old context menus, and try right clicking a file. Instant in Windows 10, visible delay in Windows 11.

That's a hallmark of GPT spam, so it's not surprising there's hallucinations.

https://gitflic.ru/project/magnolia1234/bypass-paywalls-fire...

I did that because TFA is talking about encrypting 32 bit IDs, which is 1/4th of an AES block. There aren't multiple blocks to do at once in this scenario, and throughput numbers do not apply because each instruction depends on the result of the one before.

You mention doing multiple IDs at once, but the overhead of pulling multiple IDs into a single batch from something akin to URLs in web requests is likely gonna be worse than any gains.

>Instead of this, you should use as identifier an unpredictable random number. Such identifiers can be generated with AES in batches, at maximum throughput, and stored until they are needed for assignment to a record.

Now you lose the ability to sort the records in a database, and I fail to see what AES gives you here over any other random number generator.