Most active commenters

    ←back to thread

    /dev/null is an ACID compliant database

    (jyu.dev)
    529 points swills | 15 comments | 23 Oct 25 21:28 UTC | HN request time: 1.202s | source | bottom
    1. cluckindan ◴[23 Oct 25 22:09 UTC] No.45687983[source]▶
    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.

    replies(6): >>45688157 #>>45688158 #>>45688368 #>>45689353 #>>45690041 #>>45690121 #
    2. thfuran ◴[23 Oct 25 22:25 UTC] No.45688157[source]▶
    It's really fast too.
    3. ozim ◴[23 Oct 25 22:26 UTC] No.45688158[source]▶
    I guess we have a perfect idea for vaporware here. (pun intended)

    I am putting my marketing hat on right now.

    replies(2): >>45688398 #>>45688482 #
    4. tgma ◴[23 Oct 25 22:45 UTC] No.45688368[source]▶
    Always available? Clearly you have not experienced situations with no /dev mounted.
    replies(2): >>45688429 #>>45692796 #
    5. pasteldream ◴[23 Oct 25 22:48 UTC] No.45688398[source]▶
    Reminds me of Falso.

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

    6. pasteldream ◴[23 Oct 25 22:51 UTC] No.45688429[source]▶
    One easy way to create such a situation is to use bwrap without --dev.
    7. the_jeremy ◴[23 Oct 25 22:56 UTC] No.45688482[source]▶
    You've been beaten to the punch: https://devnull-as-a-service.com/
    replies(1): >>45691027 #
    8. inopinatus ◴[24 Oct 25 00:39 UTC] No.45689353[source]▶
    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
    replies(1): >>45691911 #
    9. eru ◴[24 Oct 25 02:21 UTC] No.45690041[source]▶
    Not just instantly consistent on one machine, but globally sharded all across the universe.
    10. geoffbp ◴[24 Oct 25 02:35 UTC] No.45690121[source]▶
    Is there a case where dev null can fail?
    replies(1): >>45691489 #
    11. shakna ◴[24 Oct 25 05:17 UTC] No.45691027{3}[source]▶
    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
    replies(1): >>45692236 #
    12. tgv ◴[24 Oct 25 06:27 UTC] No.45691489[source]▶
    I can think of two: whe running out of file descriptors or memory. But then /dev/null1 would fail too.
    13. alliao ◴[24 Oct 25 07:33 UTC] No.45691911[source]▶
    pain
    14. yccs27 ◴[24 Oct 25 08:23 UTC] No.45692236{4}[source]▶
    > 85,66% guaranteed uptime (we need some sleep, too)
    15. DonHopkins ◴[24 Oct 25 09:50 UTC] No.45692796[source]▶
    Even worse, /dev/null replaced by a normal file!