doc/faq: update macOS and URLs
authorReto Kromer <lists@reto.ch>
Sun, 10 Feb 2019 16:44:10 +0000 (17:44 +0100)
committerGyan Doshi <ffmpeg@gyani.pro>
Mon, 11 Feb 2019 04:43:31 +0000 (10:13 +0530)
Signed-off-by: Gyan Doshi <ffmpeg@gyani.pro>
doc/faq.texi

index 58986cf..8b165eb 100644 (file)
@@ -76,7 +76,7 @@ the gcc developers. Note that we will not add workarounds for gcc bugs.
 
 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...
 
@@ -516,7 +516,7 @@ in the ffmpeg invocation. This is effective whether you run ffmpeg in a shell
 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.
 
@@ -526,7 +526,7 @@ For example:
 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
@@ -601,7 +601,7 @@ No. These tools are too bloated and they complicate the build.
 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?