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.
> 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.
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?).
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.
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.
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.)
/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.
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.
/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.
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
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.
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.
Looks like the code for MCP support is reviewed and merged: https://github.com/kelseyhightower/nocode/pull/5540
HaHa, it's empty too :)
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
https://github.com/kelseyhightower/nocode/commit/80f38e0f103...
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?
They're using it to communicate in code to each other.
Well they should stop that and start communicating in nocode instead.
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.
> 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 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.
> 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
> 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.
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
False.
Wait: that's just not true.
Carry on.
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.
Always available? Clearly you have not experienced situations with no /dev mounted.
One easy way to create such a situation is to use bwrap without --dev.
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/
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.
"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.
And you can implement /dev/null with multiple states, as long as you make them all behave the same way.
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
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?
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.
Compare https://codegolf.stackexchange.com/questions/199528/fastest-...
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
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.
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/
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...
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
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.)
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?
/dev/null is the ultimate storageless function. It's like serverless, but for PII, and deployable anywhere!
It's also horizontally scalable: https://gist.github.com/raggi/560087#file-shardnull
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.
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.
I guess it is also idempotent then
So if you could somehow get something stuck in /dev/null would it cause a panic or what happens?
And the axiom of empty set is an inaccessible cardinal axiom
It is also local first, low latency, data residency compliant, SOC2 compliant, zero dependency and webscale.
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.
Don't forget to feed your void. `dd if=/dev/zero of=/dev/null bs=500M count=1`
I'm gonna be that guy, tyop at the bottom
> entreprise
Not only that, it provides all 3 components of CAP!
The Jespsen tests pass quickly too!
A strong business opportunity right there.
Not on Windows.
More than that, /dev/null is infinitely scalable.
Yes, but does it support sharding? Sharding is the secret ingredient in the web scale sauce.
This reminds me of how I would write a HashCode implementation on intro CS exams in college:
‘return 5’
Add an mcp server and I'm in
I guess /dev/null is also an excellent source of investment advice, you are guaranteed to not lose money
Idea: NaaS. Null as a service.
it looks promising but what about AI /dev/null usage????
I love this
/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.
"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.
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?
Fast and easy to read, funny and fuckingly true !
best post of the week ^^