On macOS my experience with Zoom in the browser is that the gallery mode works in Chrome, however in Chrome it has problems with the camera (it reports that the camera is in use, or will hog the cpu and work at about 1 frame per second). On Firefox the camera works fine, but there is no gallery mode. On Safari the gallery mode and camera both work, but audio does not work! So I need to choose whether to do without video, audio, or gallery mode, or I can connect to the meeting twice with two different browsers.
In Unix v1 (1971) it actually did not even track the year. The time system call was documented as "get time of year", and returned "the time since 00:00:00, Jan. 1, 1971, measured in sixtieths of a second" (https://www.bell-labs.com/usr/dmr/www/pdfs/man22.pdf). The operator had to set the time on each boot, and there was no option to set a year. The PDP-7 hardware could increment a counter every 1/60 second but only while it was powered on. Later the time was changed to whole seconds and redefined to be the time since January 1, 1970 00:00:00 GMT (now UTC), but was kept 32 bits.
POSIX does not require EOF to be returned from a blocking read() if the same file descriptor is passed to close() in another thread. Even if it appears to work on some particular OS, consider the case where the reading thread may have called read() but is preempted just before entering the kernel. If another thread then closes the file descriptor, expecting the first thread to see EBADF or EOF, but then the file descriptor is reused (e.g. by accept()) before the first thread resumes, the reading thread may block reading from an unrelated socket. Even if you can guarantee that accept(), open(), or other calls that explicitly allocate a file descriptor will not be called, ordinary library functions are generally allowed to use file descriptors internally (e.g. to read a configuration file), so closing the file descriptor while another thread is reading from it is almost certainly a bug.
If you're going to go with 16 bits per component, please at least increase the color gamut. sRGB is fine if you can only dedicate 8 bits per component, but with 16 bits per component the extra depth is more useful as an increase in the color space rather than only greater precision.
I've investigated this topic for a while. I've been thinking about adding a mandated wide gamut color space.
Even though the wide color spaces "destroy" accuracy in small gradients, it doesn't matter when using 16-Bit. And because farbfeld is 16 Bits, it would definitely be an option.
Care to hit me with a mail (you can find it at the bottom of the page) so I can write you in a more sensible way what I've been thinking. Maybe you can help me decide on which color space to use (Adobe RGB, ProPhoto RGB, ...).
