mark4o

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.

It won't even work on Windows, macOS, or iOS.

I suspect that the reason for switching from ### to XXX is that grep ### requires quoting in the shell.

In https://support.apple.com/en-us/HT207617 Apple admits that this may lead to arbitrary code execution.

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.

The bug is architecture independent, although a particular exploit may work only on a specific architecture.

Existing image formats support color profiles, which allow use of colors beyond sRGB.

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.

Monty wrote up a detailed response to this in 2010: http://people.xiph.org/~xiphmont/lj-pseudocut/o-response-1.h...

An FFmpeg developer has already volunteered to continue the libav merges: http://lists.ffmpeg.org/pipermail/ffmpeg-devel/2015-August/1...

The message on the FFmpeg site http://ffmpeg.org/index.html#message sounds hopeful for a reconciliation of the forks.