_______ __ _______
| | |.---.-..----.| |--..-----..----. | | |.-----..--.--.--..-----.
| || _ || __|| < | -__|| _| | || -__|| | | ||__ --|
|___|___||___._||____||__|__||_____||__| |__|____||_____||________||_____|
on Gopher (inofficial)
HTML Visit Hacker News on the Web
COMMENT PAGE FOR:
HTML /dev/null is an ACID compliant database
torcete wrote 3 hours 52 min ago:
I was reading on the information paradox on black holes. I wonder if
the same paradox applies to /dev/null :-D
torcete wrote 3 hours 55 min ago:
Reminds me of the write-only memory (WOM) specs.
HTML [1]: https://en.wikipedia.org/wiki/Write-only_memory_(joke)
devnulled wrote 5 hours 20 min ago:
My secret is out.
senfiaj wrote 5 hours 33 min ago:
The author is a genius. If Amazon used /dev/null instead of DynamoDB,
we would not experience such terrible outages.
taftster wrote 8 hours 6 min ago:
Ah, how cute. An actual "old school" blog. Nostalgia. Tears in eyes.
[1] 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!
HTML [1]: https://jyu.dev/blog/
amai wrote 8 hours 24 min ago:
Can it rollback transactions?
taftster wrote 7 hours 56 min ago:
Yes!
phendrenad2 wrote 8 hours 37 min ago:
Reminds me of this classic highbrow techie banger [1] See the datasheet
also, I especially like the "insertions vs number of remaining pins"
chart:
HTML [1]: https://en.wikipedia.org/wiki/Write-only_memory_(joke)
HTML [2]: https://web.archive.org/web/20120316141638/http://www.national...
qwm wrote 8 hours 39 min ago:
I like this one better
HTML [1]: http://www.supersimplestorageservice.com/
dd_xplore wrote 9 hours 23 min ago:
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 9 hours 8 min ago:
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.
jjrr1018 wrote 9 hours 40 min ago:
HTML [1]: https://vldb.org/cidrdb/papers/2019/cidr2019_116.pdf
vlowther wrote 10 hours 22 min ago:
Before it was an ACID compliant database, it was also the fastest
backup solution on the market:
HTML [1]: https://bofh.bjash.com/bofh/bofh1.html
zdw wrote 10 hours 23 min ago:
The RSS feed on this site is broken.
brunoborges wrote 11 hours 9 min ago:
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 10 hours 29 min ago:
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 4 hours 12 min ago:
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.
Western0 wrote 12 hours 45 min ago:
yes
magicalhippo wrote 13 hours 53 min ago:
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]
HTML [1]: https://en.wikipedia.org/wiki/Triviality_(mathematics)#Trivial...
rollcat wrote 11 hours 58 min ago:
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 11 hours 0 min ago:
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.
yupyupyups wrote 13 hours 32 min ago:
>a nice reminder that concepts like ACID don't exist in a vaccuum.
Except if it's in /dev/null?
luckystarr wrote 14 hours 32 min ago:
Now make an algebra out of the CAP theorem. It's not already one, isn't
it? Didn't read the paper.
xandrius wrote 15 hours 6 min ago:
Reminds me of mangodb: [1] The DB at cloud scale
HTML [1]: https://github.com/dcramer/mangodb
gunalx wrote 15 hours 12 min ago:
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.
dzogchen wrote 15 hours 15 min ago:
It's ACID compliant yes, but it is not a database.
sph wrote 16 hours 28 min ago:
It's ACID compliant. But it's not a database.
ozim wrote 16 hours 23 min ago:
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
jerf wrote 9 hours 41 min ago:
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."
sph wrote 15 hours 53 min ago:
If you have infinite time, you can find your data in /dev/random
ozim wrote 12 hours 45 min ago:
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.
ramon156 wrote 16 hours 30 min ago:
I'm gonna be that guy, tyop at the bottom
> entreprise
Perz1val wrote 16 hours 57 min ago:
Don't forget to feed your void.
`dd if=/dev/zero of=/dev/null bs=500M count=1`
yard2010 wrote 18 hours 39 min ago:
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 18 hours 37 min ago:
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.)
raggi wrote 19 hours 1 min ago:
It's also horizontally scalable:
HTML [1]: https://gist.github.com/raggi/560087#file-shardnull
rollcat wrote 11 hours 41 min ago:
I understand this is supposed to be satire, but IMHO a well-executed
joke should still be well-written and easy to follow. This " unless "
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 8 hours 38 min ago:
There was quite a different context when it was written 15 years
ago, but essentially the same root jokes.
DeathArrow wrote 19 hours 21 min ago:
More than that, /dev/null is infinitely scalable.
novoreorx wrote 19 hours 37 min ago:
What a weird title, you can say it's ACID but it's not a database
sevg wrote 19 hours 35 min ago:
> 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 16 hours 55 min ago:
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.
simultsop wrote 20 hours 31 min ago:
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?
tonyhart7 wrote 20 hours 49 min ago:
it looks promising but what about AI /dev/null usage????
justinhj wrote 21 hours 20 min ago:
Add an mcp server and I'm in
hshdhdhehd wrote 22 hours 19 min ago:
It is also local first, low latency, data residency compliant, SOC2
compliant, zero dependency and webscale.
schonfinkel wrote 14 hours 36 min ago:
Does it have sharding? I heard sharding is the secret sauce for
webscale.
rollcat wrote 11 hours 38 min ago:
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.
yuppiemephisto wrote 22 hours 24 min ago:
And the axiom of empty set is an inaccessible cardinal axiom
dheera wrote 22 hours 44 min ago:
I guess /dev/null is also an excellent source of investment advice, you
are guaranteed to not lose money
blourvim wrote 22 hours 47 min ago:
I love this
jihadjihad wrote 23 hours 34 min ago:
In a similar vein, this is one of the most interesting things Iâve
come across on HN over the years: [1] Past HN post:
HTML [1]: https://www.linusakesson.net/programming/pipelogic/index.php
HTML [2]: https://news.ycombinator.com/item?id=15363029
dang wrote 4 hours 27 min ago:
Thanks! Macroexpanded:
Pipe Logic (2011) - [1] - May 2018 (18 comments)
Pipe Logic â Simulating circuits in the Unix shell (2011) - [2] -
Sept 2017 (10 comments)
/dev/zero has infinite electrons and /dev/null has an infinite
appetite for them - [3] - June 2012 (23 comments)
HTML [1]: https://news.ycombinator.com/item?id=17040762
HTML [2]: https://news.ycombinator.com/item?id=15363029
HTML [3]: https://news.ycombinator.com/item?id=4063459
stefanfisk wrote 8 hours 56 min ago:
That vaguely reminds me of
HTML [1]: https://en.wikipedia.org/wiki/Inerter_(mechanical_networks)
Sharlin wrote 9 hours 16 min ago:
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 9 hours 10 min ago:
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.
lloeki wrote 9 hours 25 min ago:
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 5 hours 32 min ago:
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.
wging wrote 14 hours 11 min ago:
And fastjson is an extremely fast json parser:
HTML [1]: https://github.com/qntm/fastjson
jmux wrote 19 hours 13 min ago:
I hadnât seen this before, this is sick! thanks for posting it here
:)
BiraIgnacio wrote 23 hours 48 min ago:
A strong business opportunity right there.
theandrewbailey wrote 23 hours 50 min ago:
/dev/null is the ultimate storageless function. It's like serverless,
but for PII, and deployable anywhere!
mjb wrote 23 hours 56 min ago:
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 23 hours 44 min ago:
This doesn't work as cleanly for SQL-style transactions where there
are tons of RW transactions, sadly.
bitwize wrote 1 day ago:
Yes, but does it support sharding? Sharding is the secret ingredient in
the web scale sauce.
johnfn wrote 1 day ago:
Not only that, it provides all 3 components of CAP!
_joel wrote 1 day ago:
The Jespsen tests pass quickly too!
tech234a wrote 1 day ago:
This reminds me of the S4 storage service: [1] Discussed on HN a few
times, but apparently not for a few years now:
HTML [1]: http://www.supersimplestorageservice.com/
HTML [2]: https://hn.algolia.com/?q=http%3A%2F%2Fwww.supersimplestorages...
layer8 wrote 1 day ago:
Not on Windows.
munchlax wrote 13 hours 58 min ago:
You could emulate it. Open windows, throw everything out, close it.
jefftk wrote 1 day ago:
"The system transitions from one valid state to another" is clearly
false: the system only has a single state.
mpyne wrote 22 hours 56 min ago:
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 22 hours 37 min ago:
And you can implement /dev/null with multiple states, as long as
you make them all behave the same way.
keithnz wrote 1 day ago:
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.
idontwantthis wrote 1 day ago:
This reminds me of how I would write a HashCode implementation on intro
CS exams in college:
âreturn 5â
1970-01-01 wrote 1 day ago:
So if you could somehow get something stuck in /dev/null would it cause
a panic or what happens?
doublerabbit wrote 1 day ago:
Idea: NaaS. Null as a service.
jibbolo wrote 13 hours 37 min ago:
Somebody thought about that already [1] :)
HTML [1]: https://devnull-as-a-service.com/
charcircuit wrote 1 day ago:
/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.
jonathrg wrote 1 day ago:
You can store any data as long as it doesn't contain any ones
saltcured wrote 22 hours 49 min ago:
And, you don't depend on it remembering how many zeros you wrote
last.
chrisweekly wrote 1 day ago:
seems you've missed the joke
charcircuit wrote 1 day ago:
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.
jfengel wrote 23 hours 18 min ago:
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 18 hours 30 min ago:
Insufficient/incomplete rather than inappropriate, perhaps?
jfengel wrote 11 hours 14 min ago:
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.
brobbin wrote 23 hours 48 min ago:
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 14 hours 5 min ago:
Considering that D in "ACID" stands for "durable", it's a
pretty sloppy joke.
voidfunc wrote 1 day ago:
"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.
gchamonlive wrote 1 day ago:
Best stack cloud providers don't want you to know about, /dev/null for
db and [1] for the backend.
HTML [1]: https://github.com/kelseyhightower/nocode
glenneroo wrote 9 hours 4 min ago:
Totally true! Also did you know that deleting all S3 object buckets
decreases latency? Lots of developers seem to agree:
HTML [1]: https://www.youtube.com/watch?v=PLKrSVuT-Dg&lc=UgxSygpx7d6yF...
philipwhiuk wrote 10 hours 53 min ago:
/dev/null is web-scale ;)
hylaride wrote 13 hours 39 min ago:
My god, AI crawlers probably train on Hacker News, too. The vibe
coders sure are in for a shock in 2-6 months... :-D
bravetraveler wrote 20 hours 1 min ago:
1.0.1 update: more nothing
nomel wrote 1 day ago:
I've never had a single issue with any user after moving our
databases to /dev/null.
crusty_jpeg wrote 9 hours 24 min ago:
It's great. We saw a 2000% throughput increase on our business
analytics platform when we switched to a /dev/null backend.
PlunderBunny wrote 23 hours 23 min ago:
Did you route the support requests to /dev/null as well?
soraminazuki wrote 21 hours 19 min ago:
Haha, I guess support.google.com is an ACID compliant database as
well.
masklinn wrote 19 hours 36 min ago:
My /dev/null of choice is
HTML [1]: https://github.com/orgs/community/discussions/
lgas wrote 22 hours 34 min ago:
This is how a lot of big tech companies scale support.
quietbritishjim wrote 1 day ago:
WTF is going on with the issues and pull requests for that repo?
gchamonlive wrote 22 hours 24 min ago:
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
HTML [1]: https://github.com/kelseyhightower/nocode/commit/80f38e0f1...
thelastgallon wrote 23 hours 4 min ago:
Looks like the code for MCP support is reviewed and merged:
HTML [1]: https://github.com/kelseyhightower/nocode/pull/5540
liqilin1567 wrote 15 hours 45 min ago:
HaHa, it's empty too :)
sundarurfriend wrote 1 day ago:
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 15 hours 33 min ago:
Also GitHub is one of the very few western websites with a
comment section that isnât blocked in China.
SanjayMehta wrote 1 day ago:
They're using it to communicate in code to each other.
QuantumNomad_ wrote 1 day ago:
Well they should stop that and start communicating in nocode
instead.
fennec-posix wrote 1 day ago:
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 22 hours 40 min ago:
Ask Google Translate?
gchamonlive wrote 1 day ago:
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.
hmokiguess wrote 1 day ago:
I guess it is also idempotent then
QuiCasseRien wrote 1 day ago:
Fast and easy to read, funny and fuckingly true !
best post of the week ^^
rezonant wrote 1 day ago:
But is /dev/null web scale?
butteredpecan wrote 1 day ago:
HTML [1]: https://devnull-as-a-service.com/
pasteldream wrote 1 day ago:
reference for the unaware:
HTML [1]: https://youtube.com/watch?v=b2F-DItXtZs
epistasis wrote 1 day ago:
Yes, /dev/null can even power sites like zombo.com
bottled_poe wrote 1 day ago:
Whatâs the I/O throughput of /dev/null ?
CaptainOfCoit wrote 1 day ago:
You start dealing with Heisen-throughput at that point, it goes
as high as you can measure.
epistasis wrote 1 day ago:
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
dinkelberg wrote 1 day ago:
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?
fukka42 wrote 1 day ago:
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.
rezonant wrote 1 day ago:
What's the best hardware for running a /dev/null instance for
production?
__turbobrew__ wrote 1 day ago:
A single resistor at ground voltage.
eru wrote 22 hours 35 min ago:
That doesn't support expected features like 'stat
/dev/null'.
epistasis wrote 1 day ago:
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 23 hours 35 min ago:
> Except for Windows...
copy c:\file nul
It's been there since DOS or more likely CP/M :)
genewitch wrote 1 hour 41 min ago:
set "nul1=1>nul"
set "nul2=2>nul"
set "nul6=2^>nul"
set "nul=>nul 2>&1"
just saw this in a .cmd script
epistasis wrote 21 hours 54 min ago:
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.
epistasis wrote 1 day ago:
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 1 day ago:
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 1 day ago:
> I guess Unix pipes are slow.
Or string concatenation, or pipeviewer.
eru wrote 22 hours 36 min ago:
Compare
HTML [1]: https://codegolf.stackexchange.com/questions/1...
fukka42 wrote 1 day ago:
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.
HTML [1]: https://github.com/coreutils/coreutils/blob/ma...
imcritic wrote 1 day ago:
How does a disaster recovery plan with it look like?
mpyne wrote 22 hours 53 min ago:
sudo mknod /dev/null c 1 3 && sudo chmod 666 /dev/null
might do it on many systems
wolrah wrote 1 day ago:
/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.
tadfisher wrote 1 day ago:
There is never a disaster; reading from /dev/null will return the
same result before and after any external event.
pyuser583 wrote 1 day ago:
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 1 day ago:
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.
tuetuopay wrote 15 hours 22 min ago:
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 9 hours 47 min ago:
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
RiverCrochet wrote 3 hours 4 min ago:
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.
dredmorbius wrote 8 hours 16 min ago:
/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.
MartijnBraam wrote 21 hours 58 min ago:
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 12 hours 41 min ago:
> 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 :)
SanjayMehta wrote 1 day ago:
False.
Wait: that's just not true.
Carry on.
noir_lord wrote 1 day ago:
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.
probably_wrong wrote 15 hours 32 min ago:
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 12 hours 42 min ago:
To be fair, bash won't be the only thing struggling when you
end up in that state.
AdieuToLogic wrote 22 hours 59 min ago:
> 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. :-)
rkeene2 wrote 23 hours 16 min ago:
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]
HTML [1]: https://lists.gnu.org/archive/html/bug-bash/2015-06/msg0...
lhmiles wrote 18 hours 46 min ago:
This was an interesting read.
1718627440 wrote 1 day ago:
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.
tuetuopay wrote 15 hours 21 min ago:
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 10 hours 37 min ago:
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.
wat10000 wrote 5 hours 12 min ago:
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 3 hours 51 min ago:
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 3 hours 35 min ago:
> 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 2 hours 58 min ago:
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.
kevin_thibedeau wrote 5 hours 35 min ago:
> 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.
tuetuopay wrote 9 hours 59 min ago:
> 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.
schoen wrote 10 hours 20 min ago:
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?
latexr wrote 1 day ago:
> 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.
PokestarFan wrote 1 day ago:
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.
gucci-on-fleek wrote 1 day ago:
> 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]
HTML [1]: https://en.wikipedia.org/wiki/Shellshock_%28software_bug...
qwertox wrote 1 day ago:
Amen.
cluckindan wrote 1 day ago:
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.
geoffbp wrote 22 hours 24 min ago:
Is there a case where dev null can fail?
tgv wrote 18 hours 32 min ago:
I can think of two: whe running out of file descriptors or memory.
But then /dev/null1 would fail too.
eru wrote 22 hours 38 min ago:
Not just instantly consistent on one machine, but globally sharded
all across the universe.
inopinatus wrote 1 day ago:
Enterprise DBAs will nevertheless provision separate /dev/null0 and
/dev/null1 devices due to corporate policy. In the event of an
outage, the symlink from null will be updated manually following an
approved run book. Please note that this runbook must be revalidated
annually as part of the sarbox audit, without which the null device
is no longer authorised for production use and must be deleted
alliao wrote 17 hours 26 min ago:
pain
tgma wrote 1 day ago:
Always available? Clearly you have not experienced situations with no
/dev mounted.
DonHopkins wrote 15 hours 9 min ago:
Even worse, /dev/null replaced by a normal file!
pasteldream wrote 1 day ago:
One easy way to create such a situation is to use bwrap without
--dev.
ozim wrote 1 day ago:
I guess we have a perfect idea for vaporware here. (pun intended)
I am putting my marketing hat on right now.
the_jeremy wrote 1 day ago:
You've been beaten to the punch:
HTML [1]: https://devnull-as-a-service.com/
shakna wrote 19 hours 42 min ago:
It's down!
$ telnet devnull-as-a-service.com 9
Trying 2001:19f0:6c01:497:5400:ff:fe69:8cbf...
Connection failed: Connection refused
Trying 45.76.95.197...
telnet: Unable to connect to remote host: Connection refused
yccs27 wrote 16 hours 36 min ago:
> 85,66% guaranteed uptime (we need some sleep, too)
pasteldream wrote 1 day ago:
Reminds me of Falso.
HTML [1]: https://inutile.club/estatis/falso/
thfuran wrote 1 day ago:
It's really fast too.
DIR <- back to front page