Enterprise DBAs will nevertheless provision separate /dev/null0 and /dev/null1 devices due to corporate policy. In the event of an outage, the symlink from null will be updated manually following an approved run book. Please note that this runbook must be revalidated annually as part of the sarbox audit, without which the null device is no longer authorised for production use and must be deleted

pain

Not just instantly consistent on one machine, but globally sharded all across the universe.

It's really fast too.

I guess we have a perfect idea for vaporware here. (pun intended)

I am putting my marketing hat on right now.

You've been beaten to the punch: https://devnull-as-a-service.com/

It's down!

    $ telnet devnull-as-a-service.com 9
    Trying 2001:19f0:6c01:497:5400:ff:fe69:8cbf...
    Connection failed: Connection refused
    Trying 45.76.95.197...
    telnet: Unable to connect to remote host: Connection refused

> 85,66% guaranteed uptime (we need some sleep, too)

Reminds me of Falso.

https://inutile.club/estatis/falso/

Always available? Clearly you have not experienced situations with no /dev mounted.

Even worse, /dev/null replaced by a normal file!

One easy way to create such a situation is to use bwrap without --dev.

Is there a case where dev null can fail?

I can think of two: whe running out of file descriptors or memory. But then /dev/null1 would fail too.