5 ms·

Always instantly consistent, always available, and perfectly tolerant of partitioning. Truly, it is the only database which can be scaled to unlimited nodes an

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.

thfuran 1y ago
It's really fast too.
ozim 1y ago
I guess we have a perfect idea for vaporware here. (pun intended) I am putting my marketing hat on right now.
- pasteldream 1y ago
  Reminds me of Falso. https://inutile.club/estatis/falso/ https://inutile.club/estatis/falso/
- the_jeremy 1y ago
  You've been beaten to the punch: https://devnull-as-a-service.com/ https://devnull-as-a-service.com/
  - shakna 1y ago
    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
    - yccs27 1y ago
      > 85,66% guaranteed uptime (we need some sleep, too)
tgma 1y ago
Always available? Clearly you have not experienced situations with no /dev mounted.
- DonHopkins 1y ago
  Even worse, /dev/null replaced by a normal file!
- pasteldream 1y ago
  One easy way to create such a situation is to use bwrap without --dev.
inopinatus 1y ago
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
- alliao 1y ago
  pain
eru 1y ago
Not just instantly consistent on one machine, but globally sharded all across the universe.
geoffbp 1y ago
Is there a case where dev null can fail?
- tgv 1y ago
  I can think of two: whe running out of file descriptors or memory. But then /dev/null1 would fail too.

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.

thfuran 1y ago

It's really fast too.

ozim 1y ago

I guess we have a perfect idea for vaporware here. (pun intended) I am putting my marketing hat on right now.

pasteldream 1y ago
Reminds me of Falso. https://inutile.club/estatis/falso/ https://inutile.club/estatis/falso/
the_jeremy 1y ago
You've been beaten to the punch: https://devnull-as-a-service.com/ https://devnull-as-a-service.com/
- shakna 1y ago
  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
  - yccs27 1y ago
    > 85,66% guaranteed uptime (we need some sleep, too)

tgma 1y ago

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

DonHopkins 1y ago
Even worse, /dev/null replaced by a normal file!
pasteldream 1y ago
One easy way to create such a situation is to use bwrap without --dev.

inopinatus 1y ago

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

alliao 1y ago
pain

eru 1y ago

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

geoffbp 1y ago

Is there a case where dev null can fail?

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