[HN Gopher] /dev/null is an ACID compliant database
___________________________________________________________________
/dev/null is an ACID compliant database
Author : swills
Score : 576 points
Date : 2025-10-23 21:28 UTC (1 days ago)
(HTM) web link (jyu.dev)
(TXT) w3m dump (jyu.dev)
| cluckindan wrote:
| 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 wrote:
| It's really fast too.
| ozim wrote:
| I guess we have a perfect idea for vaporware here. (pun
| intended)
|
| I am putting my marketing hat on right now.
| pasteldream wrote:
| Reminds me of Falso.
|
| https://inutile.club/estatis/falso/
| the_jeremy wrote:
| You've been beaten to the punch: https://devnull-as-a-
| service.com/
| shakna wrote:
| 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 wrote:
| > 85,66% guaranteed uptime (we need some sleep, too)
| tgma wrote:
| Always available? Clearly you have not experienced situations
| with no /dev mounted.
| pasteldream wrote:
| One easy way to create such a situation is to use bwrap
| without --dev.
| DonHopkins wrote:
| Even worse, /dev/null replaced by a normal file!
| inopinatus wrote:
| 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 wrote:
| pain
| eru wrote:
| Not just instantly consistent on one machine, but globally
| sharded all across the universe.
| geoffbp wrote:
| Is there a case where dev null can fail?
| tgv wrote:
| I can think of two: whe running out of file descriptors or
| memory. But then /dev/null1 would fail too.
| pyuser583 wrote:
| I've used /dev/null for exactly this purpose. I have output that
| needs to go somewhere, and I don't want to worry about whether
| that somewhere can handle it.
|
| Later on in deployment, it will go somewhere else. Somewhere that
| has been evaluated for being able to handle it.
|
| In that way, /dev/null is to storage what `true` is to execution
| - it just works.
| CaptainOfCoit wrote:
| Bug free software is a pipe dream, but if there is anything
| I've never encountered any bugs with, /dev/null and true is
| certainly in the top 3.
| noir_lord wrote:
| Joking aside I can't ever remember seeing a bug in either
| bash or zsh, never seen either crash or segfault and anytime
| I've had weirdness it's always turned out to be me missing
| something.
|
| Both (along with a lot of the standard utilities) are a
| testament to what talented C programmers plus years of people
| beating on them in unintended ways can achieve in terms of
| reliability/stability.
| qwertox wrote:
| Amen.
| gucci-on-fleek wrote:
| > I can't ever remember seeing a bug in either bash
|
| Shellshock [0] is a rather famous example, but bugs like
| that are rare enough that they make the news when they're
| found.
|
| [0]
| https://en.wikipedia.org/wiki/Shellshock_%28software_bug%29
| PokestarFan wrote:
| I've been able to trigger a segfault in zsh with certain
| plugins, a directory with a lot of files/folders, and globs
| with a bunch of * characters.
| 1718627440 wrote:
| Programs not outputting a final newline to stdout leave a
| prompt that doesn't start on column 0, and readline seams
| to not takes this into consideration, but still optimizes
| redraws and overwrites so you get an inconsistent display.
| This bugs seam to exist in a lot of shells and interactive
| programs. The program causing the issue isn't POSIX conform
| though.
| latexr wrote:
| > seams
|
| The correct spelling is "seems". I first assumed it was a
| typo, but since you did it twice I thought you might like
| to know.
| tuetuopay wrote:
| I don't get why this is still the case on classic shells.
| fish properly puts the prompt on column zero, while
| outputting a small "line return arrow" at the end of the
| command to indicate it lacked one.
| mort96 wrote:
| It's arguably not the shell's role to protect against
| garbled output. Do you expect a shell to reset the TTY
| state after every command too in case you accidentally
| `cat /dev/urandom` and the terminal emulator enters a
| weird state due to random escape sequences?
|
| The newline is a line terminator, a command outputting an
| incomplete line without a line terminator is producing
| garbled non-textual output. Files which contain
| incomplete lines without a line terminator are similarly
| garbled non-textual files and not very different from
| /dev/urandom or any other binary file.
| schoen wrote:
| I understand the terminal-garbling issue and know that I
| should run "reset" in this case (and that it wasn't the
| shell's fault), but I bet a lot of users who aren't very
| familiar with this might feel that the shell is "in
| charge of" the terminal or "in charge of" the whole
| interaction, and so that it actually should be more
| proactive in making sure that the terminal is in a
| visible sensible, usable, understandable state as often
| as possible -- in this case probably whenever a program
| exits and a new prompt is displayed?
| tuetuopay wrote:
| > a command outputting an incomplete line without a line
| terminator is producing garbled non-textual output
|
| I would argue that no, there are many valid cases for
| commands to not produce a final \n in their output. The
| first example that come to mind is curl'ing a REST API
| whose body is a single line of JSON. Many of those will
| not bother with a final \n, and this does not qualify as
| "garbled output" in my book. I would even go as far as
| saying that a shell just printing the prompt at whatever
| place the cursor happens to be is a side-effect of how
| terminal emulation works and the fact it's just a
| character based terminal.
|
| This is actually something that Warp does pretty well,
| with a strong integration with the shell where your
| command is in a dedicated text box, by the virtue of it
| being GUI and leveraging GUIs. (I don't use it however,
| I'm too much of a sucker for dense UIs).
|
| However I do agree with your argument that it's not the
| role of the shell to protect you against `cat
| /dev/urandom` or `cat picture.png`. And fish indeed does
| not try.
|
| IMHO a shell is built for humans when in interactive mode
| (one of the raison d'etre of fish), and the lack of final
| \n is such an annoyance that handling this specific edge
| case is worth it.
| kevin_thibedeau wrote:
| > The newline is a line terminator, a command outputting
| an incomplete line without a line terminator is producing
| garbled non-textual output.
|
| A command could very well be manipulating the cursor on
| its own and intentionally not writing newlines when it
| wants to overwrite text such as in a progress bar.
| wat10000 wrote:
| If you were designing a command-line interface from
| scratch, you'd definitely make it so that the command
| prompt gets displayed consistently and reliably after
| each command terminates, regardless of what garbage it
| spewed. The only reason we see anything different is
| because UNIX systems happened to grow that way, and
| everything gets crammed through an interface that was
| originally designed to show characters on physical paper.
|
| With the design we actually have, the shell is the only
| thing in the chain that _could_ reset the TTY state and
| ensure that the prompt gets displayed consistently each
| time, and it should. I wouldn 't go so far as to say that
| I expect it to (my expectations for computers are not
| high in general) but it ought to.
| 1718627440 wrote:
| command-line interface != shell
|
| Maybe that should be actually the job of the terminal
| emulator instead. It could happen when a new pseudo
| terminal is (de)allocated, which is ordered by the shell.
| wat10000 wrote:
| > command-line interface != shell
|
| I realize that. That's why I was talking about a
| hypothetical where it was designed all together, instead
| of evolving over the decades like we did.
|
| In the situation we actually have, the shell is the only
| single entity that's in a position to actually do this.
| The terminal emulator doesn't know when a command
| completes. Of course, it doesn't _have_ to be solved in a
| single entity. It would make sense to have the shell
| signal command completion to the terminal emulator, and
| let the terminal emulator do whatever it wishes with that
| information, which could include resetting any garbage
| state.
| 1718627440 wrote:
| I don't think we really disagree.
|
| I think that even when you would design it all today the
| distinction between interface and running program would
| still be useful, otherwise every program would need to
| implement it's own interface and a shell does more than
| just communicate interactively with the computer. It's
| also a task runner, program orchestrator, controls
| program selection and allows for automating other
| programs.
|
| > It would make sense to have the shell signal command
| completion to the terminal emulator, and let the terminal
| emulator do whatever it wishes with that information,
| which could include resetting any garbage state.
|
| The thing is, it kinda works this way already. I'm not
| that knowledged about the actual interaction, but the
| shell already tells my terminal what the current
| directory is, which programs it has invoked, so that my
| terminal emulator can show me this in the chrome.
|
| Ok, so my stance is: Yes it is not the job of the shell
| to modify the output of some program, but it is the job
| of the shell to tell the terminal emulator to do that,
| when the user requests this. I'm positively minded, that
| actually someone can chime in and say "ah, that's just
| not the default, you can configure bash, readline, etc.
| to do that though." I think the thing is, that bash just
| assumes that programs are POSIX-compliant and POSIX
| specifies, that every programs outputs a newline.
| Actually POSIX doesn't define it as newline, it defines
| it as the end of line. A program that forgets LF doesn't
| have forgotten to advance output a newline, it has output
| an incomplete line in that reading.
| rkeene2 wrote:
| I had a fun bug where bash would run scripts out of order!
|
| This would lead to impossible states, like
|
| if cat foo | false; then echo hmm; fi
|
| Producing output sometimes, depending on whether or not
| `cat foo` or `false` return value was used
|
| [0] https://lists.gnu.org/archive/html/bug-
| bash/2015-06/msg00010...
| lhmiles wrote:
| This was an interesting read.
| AdieuToLogic wrote:
| > Joking aside I can't ever remember seeing a bug in either
| bash or zsh, never seen either crash or segfault and
| anytime I've had weirdness it's always turned out to be me
| missing something.
|
| Given that this statement begins with "joking aside", I
| have to assume it is either a meta-joke or an uninformed
| opinion. Taking the subsequent sentence into account
| thoroughly reinforces the former.
|
| Well played. :-)
| probably_wrong wrote:
| Depending on how you define "bash" and "bug", funny things
| happen when you run on a computer with 0 remaining hard
| drive space.
| CaptainOfCoit wrote:
| To be fair, bash won't be the only thing struggling when
| you end up in that state.
| SanjayMehta wrote:
| False.
|
| Wait: that's just not true.
|
| Carry on.
| MartijnBraam wrote:
| Ah you've never encountered /dev/null not existing yet, so
| when you try to trash data it will actually create a normal
| file there so every other program that uses it will actually
| append that file.
|
| Luckily it's usually a tmpfs
| CaptainOfCoit wrote:
| > Ah you've never encountered /dev/null not existing yet
|
| I feel like that'd happen because of some other bug, I
| wouldn't consider that a bug in /dev/null :)
| tuetuopay wrote:
| The only bug with it was due to my own stupidity. I wanted a
| quick way to see how fast a drive was, thus sending one of
| its large files to /dev/null was fine. Except I went too fast
| and cp'd the file to /dev/null.
|
| It took a while before noticing I had no more /dev/null on
| the machine (read: the time needed to fill the rootfs). In a
| panic, I removed the file.
|
| Seeing the machine collapse due to /dev/null missing was fun.
| augusto-moura wrote:
| Wait, you can actually remove /dev/null? I always thought
| of it as a special driver file
|
| I guess that might not be true for all nixes out there
| dredmorbius wrote:
| /dev/null is a _device_ file, and can be removed by root,
| or any user with write access to the /dev directory
| itself.
|
| You can recreate it with 'mknod /dev/null c 1 3; chmod
| 666 /dev/null'.
|
| The '1 3' are the major and minor device numbers,
| respectively, which are assigned / maintained by LANA,
| the Linux Assigned Numbers Authority.
| RiverCrochet wrote:
| Each item in the unix filesystem can be one of the
| following: file, directory, symlink, device node, socket,
| fifo.
|
| So nothing's stopping you from making it a normal file
| and capturing all the output programs send to it.
|
| For super funsies you can make it a symlink or socket,
| but I think most programs won't work if it's a socket.
|
| Nothing also is stopping you from removing it and
| mknod'ing a /dev/null into another device file, such as
| the one /dev/full or /dev/zero uses, or /dev/fb0 if you
| wanna be really silly.
| imcritic wrote:
| How does a disaster recovery plan with it look like?
| tadfisher wrote:
| There is never a disaster; reading from /dev/null will return
| the same result before and after any external event.
| wolrah wrote:
| /dev/null is globally redundant across almost every *nix-ish
| system in operation. Just reinstall your software on whatever
| is convenient and all the same data will be there.
| mpyne wrote:
| sudo mknod /dev/null c 1 3 && sudo chmod 666 /dev/null
|
| might do it on many systems
| rezonant wrote:
| But is /dev/null web scale?
| epistasis wrote:
| Yes, /dev/null can even power sites like zombo.com
| bottled_poe wrote:
| What's the I/O throughput of /dev/null ?
| epistasis wrote:
| Single client, I'm getting ~5GB/s, both on an 8-year-old
| intel server, and on my M1 ARM chip.
|
| However with a single server, it doesn't perfectly linearly
| scale with multiple clients. I'm getting
|
| 1 client: 5GB/s
|
| 2 clients: 8GB/s
|
| 3 client: 8.7GB/s
| fukka42 wrote:
| I'm easily reaching 30GB/s with a single client:
| dd if=/dev/zero of=/dev/null bs=1M status=progress
|
| A second dd process hits the same speed.
| epistasis wrote:
| My artisanal architecture design uses writes with a few
| characters and uses unix pipes: yes |
| pv > /dev/null
|
| I hope that in my next rewrite I can advance to larger
| block sizes.
| fukka42 wrote:
| Interestingly I tried this as well and was disappointed
| with the results: yes $(printf %1024s |
| tr " " "y") | pv > /dev/null
|
| About the same throughput as letting yes output a single
| character. I guess Unix pipes are slow.
| 1718627440 wrote:
| > I guess Unix pipes are slow.
|
| Or string concatenation, or pipeviewer.
| fukka42 wrote:
| yes doesn't do string concatenation, at least not in the
| loop that matters. It just prepares a buffer of bytes
| once and writes it to stdout repeatedly.
|
| https://github.com/coreutils/coreutils/blob/master/src/ye
| s.c
| eru wrote:
| Compare https://codegolf.stackexchange.com/questions/1995
| 28/fastest-...
| rezonant wrote:
| What's the best hardware for running a /dev/null instance
| for production?
| epistasis wrote:
| I usually do a kubernetes cluster on top of VMs. But
| sometimes when I really want to scale the standard cloud
| server less platforms all support /dev/null out of the
| box. (Except for Windows...)
| wowczarek wrote:
| > Except for Windows...
|
| copy c:\file nul
|
| It's been there since DOS or more likely CP/M :)
| epistasis wrote:
| Still need an adapter library though! Fortunately there
| are about 7 competing implementations on npm and most of
| them only have 5-6 transitive dependencies.
| __turbobrew__ wrote:
| A single resistor at ground voltage.
| eru wrote:
| That doesn't support expected features like 'stat
| /dev/null'.
| dinkelberg wrote:
| How did you measure this? Do you know that /dev/null is
| the limiting factor, or could it be the data source that
| is limiting?
| CaptainOfCoit wrote:
| You start dealing with Heisen-throughput at that point, it
| goes as high as you can measure.
| pasteldream wrote:
| reference for the unaware:
| https://youtube.com/watch?v=b2F-DItXtZs
| butteredpecan wrote:
| https://devnull-as-a-service.com/
| QuiCasseRien wrote:
| Fast and easy to read, funny and fuckingly true !
|
| best post of the week ^^
| hmokiguess wrote:
| I guess it is also idempotent then
| gchamonlive wrote:
| Best stack cloud providers don't want you to know about,
| /dev/null for db and https://github.com/kelseyhightower/nocode
| for the backend.
| quietbritishjim wrote:
| WTF is going on with the issues and pull requests for that
| repo?
| gchamonlive wrote:
| In nocode you fix nothing and you don't change anything,
| that's why issues and pull requests are a mess, they
| literally cannot be dealt with by design.
| fennec-posix wrote:
| Had to see for myself, and yeah... that's a whole lot of
| chaos. I'm sure I'd get the joke if I could read Chinese
| though.
| eru wrote:
| Ask Google Translate?
| SanjayMehta wrote:
| They're using it to communicate in code to each other.
| QuantumNomad_ wrote:
| Well they should stop that and start communicating in
| nocode instead.
| sundarurfriend wrote:
| The less substance there is to it, the easier it is to talk
| about.
|
| The Chinese comments ("issues") also seem to be the same kind
| of jokes as the English ones, "no code means no bugs,
| perfect", etc., from the few I tried getting translations of.
| I imagine this went viral on Chinese social media, which
| makes sense since it's the sort of joke that's easy to
| translate and doesn't depend on particular cultural
| assumptions or anything.
| bspammer wrote:
| Also GitHub is one of the very few western websites with a
| comment section that isn't blocked in China.
| thelastgallon wrote:
| Looks like the code for MCP support is reviewed and merged:
| https://github.com/kelseyhightower/nocode/pull/5540
| liqilin1567 wrote:
| HaHa, it's empty too :)
| gchamonlive wrote:
| This commit is interesting, it used to support /dev/null
| natively, but for the sake of supporting windows you now have
| to use /dev/null externally by writing nothing at all
|
| https://github.com/kelseyhightower/nocode/commit/80f38e0f103.
| ..
| nomel wrote:
| I've never had a single issue with any user after moving our
| databases to /dev/null.
| PlunderBunny wrote:
| Did you route the support requests to /dev/null as well?
| lgas wrote:
| This is how a lot of big tech companies scale support.
| soraminazuki wrote:
| Haha, I guess support.google.com is an ACID compliant
| database as well.
| masklinn wrote:
| My /dev/null of choice is
| https://github.com/orgs/community/discussions/
| crusty_jpeg wrote:
| It's great. We saw a 2000% throughput increase on our
| business analytics platform when we switched to a /dev/null
| backend.
| bravetraveler wrote:
| 1.0.1 update: more nothing
| hylaride wrote:
| My god, AI crawlers probably train on Hacker News, too. The
| vibe coders sure are in for a shock in 2-6 months... :-D
| philipwhiuk wrote:
| /dev/null is web-scale ;)
| glenneroo wrote:
| Totally true! Also did you know that deleting all S3 object
| buckets decreases latency? Lots of developers seem to agree:
| https://www.youtube.com/watch?v=PLKrSVuT-Dg&lc=UgxSygpx7d6yF...
| charcircuit wrote:
| /dev/null is not a database. By this logic is a hard disk a
| database, is a CD a database. No. They are storage mediums. You
| could store a database on them, but they themselves are not a
| database.
|
| Considering there is no way to read back data written to
| /dev/null it will not be useful for storing database data.
| chrisweekly wrote:
| seems you've missed the joke
| charcircuit wrote:
| It's not a funny one if it was one. Of course something is
| going to be a bad database if it's not a database.
| voidfunc wrote:
| "Its not funny" says the one guy in a room where literally
| everyone else is laughing and riffing on the joke.
|
| Your humor unit might be defective.
| brobbin wrote:
| It's nerd humor. You're not supposed to find it funny, but
| nod along approvingly while noticing how awfully clever you
| are for noticing the attempt at being funny.
| dmytrish wrote:
| Considering that D in "ACID" stands for "durable", it's a
| pretty sloppy joke.
| jfengel wrote:
| It's not a great joke, to be sure. But the essence of it is
| that it's a _good_ database, by relevant but inappropriate
| standards.
| tgv wrote:
| Insufficient/incomplete rather than inappropriate,
| perhaps?
| jfengel wrote:
| The problem with the joke, as I see it, is that it only
| works with a colloquial definition of ACID. If it worked
| with a formal definition, it would be funnier by having a
| twinge of insight.
|
| It's as if the joke requires two steps away from reality:
| first to apply the definition to a domain where it
| doesn't apply, then mis-reading the definition to make it
| fit. Having to go two steps like that spoils the feeling
| of insight that makes a joke like this work.
|
| The article doesn't belabor the gag, which is a point in
| its favor. It has to hit you with its punch line and then
| quit before it wears out its welcome.
| jonathrg wrote:
| You can store any data as long as it doesn't contain any ones
| saltcured wrote:
| And, you don't depend on it remembering how many zeros you
| wrote last.
| doublerabbit wrote:
| Idea: NaaS. Null as a service.
| jibbolo wrote:
| Somebody thought about that already https://devnull-as-a-
| service.com/ :)
| 1970-01-01 wrote:
| So if you could somehow get something stuck in /dev/null would it
| cause a panic or what happens?
| idontwantthis wrote:
| This reminds me of how I would write a HashCode implementation on
| intro CS exams in college:
|
| 'return 5'
| keithnz wrote:
| took a while to pipe my multi-terabyte db to /dev/null but now
| that I have I'm saving a ton of money on storage.
| jefftk wrote:
| "The system transitions from one valid state to another" is
| clearly false: the system only has a single state.
| mpyne wrote:
| One of the first state machine you'll ever learn about in
| undergrad permits transitions from a state back to itself, so I
| don't see this as a barrier.
| eru wrote:
| And you can implement /dev/null with multiple states, as long
| as you make them all behave the same way.
| layer8 wrote:
| Not on Windows.
| munchlax wrote:
| You could emulate it. Open windows, throw everything out, close
| it.
| tech234a wrote:
| This reminds me of the S4 storage service:
| http://www.supersimplestorageservice.com/
|
| Discussed on HN a few times, but apparently not for a few years
| now:
| https://hn.algolia.com/?q=http%3A%2F%2Fwww.supersimplestorag...
| johnfn wrote:
| Not only that, it provides all 3 components of CAP!
| _joel wrote:
| The Jespsen tests pass quickly too!
| bitwize wrote:
| Yes, but does it support sharding? Sharding is the secret
| ingredient in the web scale sauce.
| mjb wrote:
| Best of all, /dev/null is also serializable (but not strict
| serializable) under many academic and textbook definitions.
|
| Specifically, these definitions require that transactions appear
| to execute in _some_ serial order, and place no constraints on
| that serial order. So the database can issue all reads at time
| zero, returning empty results, and all writes at the time they
| happen (because who the hell cares?).
|
| The lesson? Demand real-time guarantees.
| mjb wrote:
| This doesn't work as cleanly for SQL-style transactions where
| there are tons of RW transactions, sadly.
| theandrewbailey wrote:
| /dev/null is the ultimate storageless function. It's like
| serverless, but for PII, and deployable anywhere!
| BiraIgnacio wrote:
| A strong business opportunity right there.
| jihadjihad wrote:
| In a similar vein, this is one of the most interesting things
| I've come across on HN over the years:
|
| https://www.linusakesson.net/programming/pipelogic/index.php
|
| Past HN post: https://news.ycombinator.com/item?id=15363029
| jmux wrote:
| I hadn't seen this before, this is sick! thanks for posting it
| here :)
| wging wrote:
| And fastjson is an extremely fast json parser:
| https://github.com/qntm/fastjson
| lloeki wrote:
| Around 2004-2005 during some research at the end of my
| curriculum I happened to be doing with some specific jobs that
| were parallelised and data flowing as it was processed along a
| component diagram for visualisation, and it looked very
| familiar....
|
| So I had this idea that you'd design code to be applied to a
| processing unit of specific capacity which would lead to
| execution flowing at a certain speed when applied a certain
| computation potential... and surprise surprise the relation
| would be uh, linear, and say you increase a loop's count and so
| the code would _resist_, or you'd increase computation
| potential to increase the flow.
|
| So uh, yeah, Ohm's law but it's _code_ that's resistive.
|
| And then I started to look for the pattern and find code with
| inductive properties, and code with capacitive properties, and
| some deeper properties emerged when you started modelling stuff
| with multiple processing units and data flowed around, split
| (map?), rejoined (reduce?).
|
| And there was something strangely efficient about a way to see
| code that way and optimise using _laws_ describing the whole
| execution flow using familiar tools as a whole instead of
| thinking in gritty details barely higher-level than MOV AX...
| you "just" had to design code and the execution system so that
| it would operate in this kind of framework and allow that kind
| of analysis to identify bottlenecks and weird interplay actions
| across components.
|
| And then I brought that up to my mentor and he said "well
| that's complete lunacy, stop thinking about that and focus on
| your current work" and, uh, case closed.
|
| That was the young and naive me who thought that research labs
| were made to do think-outside-the-box connect-the-dots
| innovative stuff...
| kevindamm wrote:
| It's never too late to learn queueing theory
|
| ...because the typical setup assumes l <= m so all arriving
| jobs eventually get serviced.
|
| I think there's a lot of unmet potential in design of
| interfaces for pipelines and services that really gets at the
| higher level you mention. There are some universal laws, and
| some differences between practice and theory.
| Sharlin wrote:
| This is probably old news to people interested in nonstandard
| methods of computation, but it just occurred to me that the
| fluid-based analogy to transistors is straightforward to
| construct: S | |
| -------| | G \/\/|##| | -------| |
| | | D
|
| This is essentially a pressure regulator, except that the
| pressure is controlled by an independent signal. Pressure in G
| pushes a spring-loaded piston to block flow from S to D (a
| slightly different construction instead allows flow when G has
| pressure). Modulating the pressure in G can also used to
| modulate the flow, based on F = -kx. This simple construction
| has some issues, such as the fact that the pressure needed to
| move the piston depends on the pressure in S-D.
| duped wrote:
| This analogy goes pretty deep.
|
| Fun fact, in British English the term for a vacuum tube
| triode is "valve" precisely because it operates like a valve.
| FETs (particularly JFETs) follow the same analogy (which is
| why FET and triode amplifier circuits look basically the
| same) using the field effect instead of thermionic emission.
| stefanfisk wrote:
| That vaguely reminds me of
| https://en.wikipedia.org/wiki/Inerter_(mechanical_networks)
| dang wrote:
| Thanks! Macroexpanded:
|
| _Pipe Logic (2011)_ -
| https://news.ycombinator.com/item?id=17040762 - May 2018 (18
| comments)
|
| _Pipe Logic - Simulating circuits in the Unix shell (2011)_ -
| https://news.ycombinator.com/item?id=15363029 - Sept 2017 (10
| comments)
|
| _/ dev/zero has infinite electrons and /dev/null has an
| infinite appetite for them_ -
| https://news.ycombinator.com/item?id=4063459 - June 2012 (23
| comments)
| blourvim wrote:
| I love this
| dheera wrote:
| I guess /dev/null is also an excellent source of investment
| advice, you are guaranteed to not lose money
| yuppiemephisto wrote:
| And the axiom of empty set is an inaccessible cardinal axiom
| hshdhdhehd wrote:
| It is also local first, low latency, data residency compliant,
| SOC2 compliant, zero dependency and webscale.
| schonfinkel wrote:
| Does it have sharding? I heard sharding is the secret sauce for
| webscale.
| rollcat wrote:
| You can deploy /dev/null on any number of nodes, and expect
| exact consistency, high availability, and perfect partition
| tolerance with concurrent writes and reads bounded only by
| your hardware/kernel.
| justinhj wrote:
| Add an mcp server and I'm in
| tonyhart7 wrote:
| it looks promising but what about AI /dev/null usage????
| simultsop wrote:
| You need an FAQ section, we have so many questions for this
| marvellous solution.
|
| Is it portable to all linux distros?
|
| Where is the ubuntu command to install it?
|
| What license does it use, is it free or else?
|
| Is it really open source or source only?
| novoreorx wrote:
| What a weird title, you can say it's ACID but it's not a database
| sevg wrote:
| > What a weird title, you can say it's ACID but it's not a
| database
|
| You're right, we should ban jokes that aren't 100% correct!
| novoreorx wrote:
| Sorry if you feel my words mean. I'm not criticizing the
| joke, I just think it could make a better title, even for a
| joke, by adding quotes around "database" or calling it a
| "storage service," since it does allow data to be read. A
| good joke is both entertaining and difficult to deny.
| DeathArrow wrote:
| More than that, /dev/null is infinitely scalable.
| raggi wrote:
| It's also horizontally scalable:
| https://gist.github.com/raggi/560087#file-shardnull
| rollcat wrote:
| I understand this is supposed to be satire, but IMHO a well-
| executed joke should still be well-written and easy to follow.
| This "<statement> unless <condition>" is just terrible to read,
| and I can't even tell if FFI is necessary here, or a part of
| the joke. Funny not funny.
| raggi wrote:
| There was quite a different context when it was written 15
| years ago, but essentially the same root jokes.
| yard2010 wrote:
| I love vacously truths (not sure if this is how you say it in
| English)
|
| All the people I've met in London were androids.
| tczMUFlmoNk wrote:
| The term is correct. Grammatically, we would say, "I love
| vacuous truths", or, "I love vacuously true statements". (To my
| ear the second version sounds very slightly more appropriate,
| because in mathematics "vacuously true" is a bit of a set
| phrase, but both are fine.)
| Perz1val wrote:
| Don't forget to feed your void. `dd if=/dev/zero of=/dev/null
| bs=500M count=1`
| ramon156 wrote:
| I'm gonna be that guy, tyop at the bottom
|
| > entreprise
| sph wrote:
| It's ACID compliant. But it's not a database.
| ozim wrote:
| W just need R&D money to solve reading back from it, but that's
| just a matter of time we can definitely solve it in a year or
| two.
|
| This tech is just around the corner I promise, then we will be
| first to the market and all the big tech companies will want to
| buy us out, imagine how much we can earn.
|
| /s
| sph wrote:
| If you have infinite time, you can find your data in
| /dev/random
| ozim wrote:
| If you pay or get some people to finance R&D we can make it
| work, I guess we could market it as data recovery solution
| because I guess we can find every data in there, even from
| thumb drive someone lost in 2004.
| jerf wrote:
| It's nearly solved now.
|
| "ChatGPT, I had a database here but it seems to have gone
| missing. It had a table with "User", "Email", and "Amount
| Paid"; can you reconstruct it for me?"
|
| ...
|
| "I dunno boss, that's what the AI said."
| dzogchen wrote:
| It's ACID compliant yes, but it is not a database.
| gunalx wrote:
| You say it is always empty, but. I have seen weird issues coming
| from /dev/null not actually being empty but being a file or
| symlink (dont remember) With garbage data.
| xandrius wrote:
| Reminds me of mangodb: https://github.com/dcramer/mangodb
|
| The DB at cloud scale
| luckystarr wrote:
| Now make an algebra out of the CAP theorem. It's not already one,
| isn't it? Didn't read the paper.
| magicalhippo wrote:
| Reminds me of how in the math lectures, our professor would
| always point out he was ignoring the trivial solution[1].
|
| That /dev/null is ACID compliant is the trivial solution of
| databases.
|
| Still, a jolly good read, and a nice reminder that concepts like
| ACID don't exist in a vaccuum.
|
| [1]:
| https://en.wikipedia.org/wiki/Triviality_(mathematics)#Trivi...
| yupyupyups wrote:
| >a nice reminder that concepts like ACID don't exist in a
| vaccuum.
|
| Except if it's in /dev/null?
| rollcat wrote:
| You can dismiss it as a triviality, but in CS it's always worth
| considering (what you assume to be) an "identity" value, and
| its edge cases. Does your DSP algorithm work with near-zero
| values as well as it does with "true" zero?
|
| (hint: look up subnormal floats.)
| magicalhippo wrote:
| I was only dismissing it in the sense that if you were
| picking a database to use, you'd avoid the "trivial solution"
| of /dev/null.
| Western0 wrote:
| yes
| brunoborges wrote:
| I get the joke, but IMO it doesn't pass Durability test, as what
| is sent to it (i.e. transactions) are _not_ durable.
|
| Durability in ACID is about the durability of the data that is
| sent to the database (in this ironic post, /dev/null) once
| committed.
|
| "[...] completed transactions (or their effects) are recorded
| [...]"
|
| But I will give it that ACI do make sense!
|
| #PedanticMode
| PTOB wrote:
| Let's test that:
|
| 1. Nothing stored in /dev/null is durable. 2. Nothing is stored
| in /dev/null. 3. Ergo, /dev/null exhibits durability.
|
| Thank you, I'll take my check at the door.
| brunoborges wrote:
| You are missing the part where the data did exist and that
| after something/someone sent it to /dev/null, the data was
| gone. Therefore, the data did not endure. The Durability test
| of ACID failed for /dev/null.
| zdw wrote:
| The RSS feed on this site is broken.
| vlowther wrote:
| Before it was an ACID compliant database, it was also the fastest
| backup solution on the market:
| https://bofh.bjash.com/bofh/bofh1.html
| jjrr1018 wrote:
| https://vldb.org/cidrdb/papers/2019/cidr2019_116.pdf
| dd_xplore wrote:
| One question though, if for some reason a poorely designed app
| discards data through /dev/null, is it tamper proof? Meaning can
| any other process or user access that information? (In runtime)
| dragonwriter wrote:
| I think it is possible for a process with root to delete the
| existing /dev/null and replace it with a normal file (likely to
| produce system instability) or a new character device (could
| probably be mostly transparent to anyone who didn't know where
| to look for it storing its data), in which case anything sent
| to it could be captured.
| qwm wrote:
| I like this one better http://www.supersimplestorageservice.com/
| phendrenad2 wrote:
| Reminds me of this classic highbrow techie banger
|
| https://en.wikipedia.org/wiki/Write-only_memory_(joke)
|
| See the datasheet also, I especially like the "insertions vs
| number of remaining pins" chart:
|
| https://web.archive.org/web/20120316141638/http://www.nation...
| amai wrote:
| Can it rollback transactions?
| taftster wrote:
| Yes!
| taftster wrote:
| Ah, how cute. An actual "old school" blog. Nostalgia. Tears in
| eyes.
|
| https://jyu.dev/blog/
|
| And the production of articles is about right too.
| . "Hello World" - The start of something great. [Dec 2024]
| . "Comparison is the Thief of Joy" - Link to another article.
| [Apr 2025] . "/dev/null is an ACID compliant
| database" - Funny, insightful. [Aug 2025]
|
| That read about like my blog 20 years ago.
|
| Funny post though, good read!
| senfiaj wrote:
| The author is a genius. If Amazon used /dev/null instead of
| DynamoDB, we would not experience such terrible outages.
| devnulled wrote:
| My secret is out.
| torcete wrote:
| Reminds me of the write-only memory (WOM) specs.
|
| https://en.wikipedia.org/wiki/Write-only_memory_(joke)
| torcete wrote:
| I was reading on the information paradox on black holes. I wonder
| if the same paradox applies to /dev/null :-D
___________________________________________________________________
(page generated 2025-10-24 23:02 UTC)