Specialized NICs - is this what e.g. Cavium LiquidIO "server adapters" are? I came across those looking through the firmware shipped with Linux.
338 karma · joined February 8, 2017
[ my public key: https://keybase.io/heftig; my proof: https://keybase.io/heftig/sigs/vAGC78N1YQjTEZO96gvqfkVD0fit_mml6IN6XPw-wvo ]
In a classic "fullscreen game" situation, whenever a back buffer is finished, the game would configure the GPU's CRTC (the hardware that generates the data stream that goes to the monitor) to read from this back buffer instead. This turns the back buffer into the current front buffer and releases the old front buffer to act as the next back buffer ("page flipping").
When this happens without any synchronization with the monitor, the buffer can be changed in the middle of the frame, causing the characteristic tearing. With VSync, the game delays the swap until the monitor is between frames.
With Wayland, the game swaps buffers with the compositor instead. Direct scanout means that the compositor will configure the CRTC to read from the game's front buffer. So this is really similar to the "classic" situation, except it involves a bit of inter-process communication.
Otherwise, the compositor has its own set of front and back buffer, and the game's front buffer is copied (composited) into the compositor's back buffer first. So we have another buffer swap that has to be done, and this is what causes the composition lag.
Whether direct scanout happens or not is transparent to the game, which does not need to care.
Wayland enforces VSync by default, though there's a protocol being designed (`zwp_tearing_control_unstable_v1`) so a game can request asynchronous flipping.
The difference to Windows is that Linux allows you to delete (unlink) files that are in use. The inode actually owning the data continues to exist until the program is dead.
However, if the homeserver is using OIDC, the user credentials are handled entirely by the external OIDC provider and the client doesn't get them. But then you should be using OIDC directly and not "Sign in with Matrix."
What is N here? Number of allocations?
PS: The other way around is more obviously broken, with the C++17 lib headers getting compiled using C++11.
In any case, sneakily using nightly features can make using a different Rust version problematic, since these features are free of any stability guarantees.
Arch Linux carries a rather large patch updating some vendored dependency in order to make Firefox 78 compile with a newer Rust. https://github.com/archlinux/svntogit-packages/tree/packages...
This is in contrast to C and C++ compilers like GCC and Clang, where the default "std" setting is often updated with new releases.
You also want them to be low-power even when saturated, otherwise you gain responsiveness from the "performance" cores but your "efficiency" cores aren't actually efficient.
It seems at least Linux's x86_energy_perf_policy tool lets you set multiplier ranges and some performance-vs-power values per-core, which means such a setup doesn't seem impossible on current Intel hardware.
However, unlike UUIDs they don't necessarily exist, are not as likely to be unique (you should only get duplicate UUIDs by cloning filesystems) and are easier to change. This makes them less suitable for mount configuration.
In test 1, the subject was commanded to translate the pictograms into text.
In test 2 the subject was commanded to describe the pictograms verbally.
PS: Actually, the limits for the basic German driver's license (B) are: Max GVWR of 3500 kg. With trailer, if GTWR not above 750 kg, no GCWR restriction, otherwise max GCWR of 3500 kg.
There's an extended license (BE) for max GTWR of 3500 kg and no GCWR restriction. (Max GVWR still 3500 kg.)
https://www.adac.de/verkehr/rund-um-den-fuehrerschein/klasse... (German text).