Also note that (some of) the gcc developers believe this is not a bug or
not a bug they should fix:
-@url{http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11203}.
+@url{https://gcc.gnu.org/bugzilla/show_bug.cgi?id=11203}.
Then again, some of them do not know the difference between an undecidable
problem and an NP-hard problem...
or invoke ffmpeg in its own process via an operating system API.
As an alternative, when you are running ffmpeg in a shell, you can redirect
-standard input to @code{/dev/null} (on Linux and Mac OS)
+standard input to @code{/dev/null} (on Linux and macOS)
or @code{NUL} (on Windows). You can do this redirect either
on the ffmpeg invocation, or from a shell script which calls ffmpeg.
ffmpeg -nostdin -i INPUT OUTPUT
@end example
-or (on Linux, Mac OS, and other UNIX-like shells):
+or (on Linux, macOS, and other UNIX-like shells):
@example
ffmpeg -i INPUT OUTPUT </dev/null
FFmpeg is already organized in a highly modular manner and does not need to
be rewritten in a formal object language. Further, many of the developers
favor straight C; it works for them. For more arguments on this matter,
-read @uref{http://www.tux.org/lkml/#s15, "Programming Religion"}.
+read @uref{https://web.archive.org/web/20111004021423/http://kernel.org/pub/linux/docs/lkml/#s15, "Programming Religion"}.
@section Why are the ffmpeg programs devoid of debugging symbols?