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.
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.
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...
...because the typical setup assumes λ ≤ μ 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.
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.
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.
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
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.
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.
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.
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.
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.
> 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'être of fish), and the lack of final \n is such an annoyance that handling this specific edge case is worth it.
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?
> 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.
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.
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.
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.
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.
> 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.
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.
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.
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.
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
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?).
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?
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.
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...)
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.
I saw a MongoDb implementation on Github awhile ago that was a wrapper around /dev/null. The thesis was if you're using MongoDb, you probably didn't weren't planning on querying anything later anyway.
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)
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.
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.
/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.
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.)
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.
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.
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.
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.
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.
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.
"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?"
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]
/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.
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.
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.
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
And fastjson is an extremely fast json parser: https://github.com/qntm/fastjson
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:
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.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.
Related: https://en.wikipedia.org/wiki/Phillips_Machine
"The Phillips Machine is an analogue computer which uses fluidic logic to model the workings of an economy."
See also the Glooper in Pratchett's Making Money.
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)
That vaguely reminds me of https://en.wikipedia.org/wiki/Inerter_(mechanical_networks)
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...
It's never too late to learn queueing theory
...because the typical setup assumes λ ≤ μ 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.
I hadn’t seen this before, this is sick! thanks for posting it here :)
Best stack cloud providers don't want you to know about, /dev/null for db and https://github.com/kelseyhightower/nocode for the backend.
I've never had a single issue with any user after moving our databases to /dev/null.
Did you route the support requests to /dev/null as well?
Haha, I guess support.google.com is an ACID compliant database as well.
My /dev/null of choice is https://github.com/orgs/community/discussions/
This is how a lot of big tech companies scale support.
We've never had a support request either!
It's great. We saw a 2000% throughput increase on our business analytics platform when we switched to a /dev/null backend.
My god, AI crawlers probably train on Hacker News, too. The vibe coders sure are in for a shock in 2-6 months... :-D
WTF is going on with the issues and pull requests for that repo?
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.
Also GitHub is one of the very few western websites with a comment section that isn’t blocked in China.
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.
Looks like the code for MCP support is reviewed and merged: https://github.com/kelseyhightower/nocode/pull/5540
HaHa, it's empty too :)
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...
They're using it to communicate in code to each other.
Well they should stop that and start communicating in nocode instead.
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.
Ask Google Translate?
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...
/dev/null is web-scale ;)
1.0.1 update: more nothing
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.
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.
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.
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.
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.
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.
> 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'être of fish), and the lack of final \n is such an annoyance that handling this specific edge case is worth it.
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?
> 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.
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.
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.
> 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.
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.
> 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.
> 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
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...
This was an interesting read.
Depending on how you define "bash" and "bug", funny things happen when you run on a computer with 0 remaining hard drive space.
To be fair, bash won't be the only thing struggling when you end up in that state.
> 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. :-)
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.
Amen.
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.
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
/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.
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.
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
> 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 :)
False.
Wait: that's just not true.
Carry on.
That is literally what it was added to unix for.
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.
You've been beaten to the punch: https://devnull-as-a-service.com/
It's down!
> 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.
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.
This doesn't work as cleanly for SQL-style transactions where there are tons of RW transactions, sadly.
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...
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.)
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.
>a nice reminder that concepts like ACID don't exist in a vaccuum.
Except if it's in /dev/null?
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...
But is /dev/null web scale?
Yes, /dev/null can even power sites like zombo.com
What’s the I/O throughput of /dev/null ?
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
I'm easily reaching 30GB/s with a single client:
A second dd process hits the same speed.My artisanal architecture design uses writes with a few characters and uses unix pipes:
I hope that in my next rewrite I can advance to larger block sizes.Interestingly I tried this as well and was disappointed with the results:
About the same throughput as letting yes output a single character. I guess Unix pipes are slow.> I guess Unix pipes are slow.
Or string concatenation, or pipeviewer.
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/yes.c
Compare https://codegolf.stackexchange.com/questions/199528/fastest-...
What's the best hardware for running a /dev/null instance for production?
A single resistor at ground voltage.
That doesn't support expected features like 'stat /dev/null'.
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...)
> Except for Windows...
copy c:\file nul
It's been there since DOS or more likely CP/M :)
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.
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?
You start dealing with Heisen-throughput at that point, it goes as high as you can measure.
reference for the unaware: https://youtube.com/watch?v=b2F-DItXtZs
https://devnull-as-a-service.com/
"The system transitions from one valid state to another" is clearly false: the system only has a single state.
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.
The claim is not "it's a state machine" but about transitioning from one valid state "to another". That requires more than one state.
And you can implement /dev/null with multiple states, as long as you make them all behave the same way.
I saw a MongoDb implementation on Github awhile ago that was a wrapper around /dev/null. The thesis was if you're using MongoDb, you probably didn't weren't planning on querying anything later anyway.
Before it was an ACID compliant database, it was also the fastest backup solution on the market: https://bofh.bjash.com/bofh/bofh1.html
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)
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.
Reminds me of mangodb: https://github.com/dcramer/mangodb
The DB at cloud scale
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?
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
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.
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.
I guess it is also idempotent then
How does a disaster recovery plan with it look like?
There is never a disaster; reading from /dev/null will return the same result before and after any external event.
/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.
/dev/null is the ultimate storageless function. It's like serverless, but for PII, and deployable anywhere!
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...
I like this one better http://www.supersimplestorageservice.com/
Reminds me of the write-only memory (WOM) specs.
https://en.wikipedia.org/wiki/Write-only_memory_(joke)
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.
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.)
It is also local first, low latency, data residency compliant, SOC2 compliant, zero dependency and webscale.
Does it have sharding? I heard sharding is the secret sauce for webscale.
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.
So if you could somehow get something stuck in /dev/null would it cause a panic or what happens?
https://vldb.org/cidrdb/papers/2019/cidr2019_116.pdf
Yes, but does it support sharding? Sharding is the secret ingredient in the web scale sauce.
It's also horizontally scalable: https://gist.github.com/raggi/560087#file-shardnull
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.
There was quite a different context when it was written 15 years ago, but essentially the same root jokes.
This reminds me of how I would write a HashCode implementation on intro CS exams in college:
‘return 5’
What a weird title, you can say it's ACID but it's not a database
> 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!
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.
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.
I was reading on the information paradox on black holes. I wonder if the same paradox applies to /dev/null :-D
It's ACID compliant yes, but it is not a database.
It's ACID compliant. But it's not a database.
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
If you have infinite time, you can find your data in /dev/random
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.
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."
And the axiom of empty set is an inaccessible cardinal axiom
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.
That read about like my blog 20 years ago.Funny post though, good read!
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.
I guess /dev/null is also an excellent source of investment advice, you are guaranteed to not lose money
More than that, /dev/null is infinitely scalable.
Not only that, it provides all 3 components of CAP!
The Jespsen tests pass quickly too!
The RSS feed on this site is broken.
Can it rollback transactions?
Yes!
A strong business opportunity right there.
Not on Windows.
You could emulate it. Open windows, throw everything out, close it.
Add an mcp server and I'm in
Idea: NaaS. Null as a service.
Somebody thought about that already https://devnull-as-a-service.com/ :)
My secret is out.
it looks promising but what about AI /dev/null usage????
The author is a genius. If Amazon used /dev/null instead of DynamoDB, we would not experience such terrible outages.
Now make an algebra out of the CAP theorem. It's not already one, isn't it? Didn't read the paper.
Don't forget to feed your void. `dd if=/dev/zero of=/dev/null bs=500M count=1`
yes
I'm gonna be that guy, tyop at the bottom
> entreprise
I love this
[dead]
Fast and easy to read, funny and fuckingly true !
best post of the week ^^
/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.
You can store any data as long as it doesn't contain any ones
And, you don't depend on it remembering how many zeros you wrote last.
seems you've missed the joke
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.
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.
Considering that D in "ACID" stands for "durable", it's a pretty sloppy joke.
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.
Insufficient/incomplete rather than inappropriate, perhaps?
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.
"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.
[dead]
[dead]