Hacker News Reader

Comment by cluckindan | Hacker News Reader

Always instantly consistent, always available, and perfectly tolerant of partitioning.

Truly, it is the only database which can be scaled to unlimited nodes and remain fully CAP.

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.

Reminds me of Falso.

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

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)

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

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

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

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.

Reply on news.ycombinator.com