/dev/null is an ACID compliant database • Hacker News Board

Re: /dev/null is an ACID compliant database

#191

Post by 1718627440 » Fri, Oct 24, 2025, 9:08 PM UTC

wat10000 wrote: post #186

mort96 wrote: post #155

Earlier quoted context omitted.

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 conta…

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 phys…

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.

Re: /dev/null is an ACID compliant database

#192

Post by wat10000 » Fri, Oct 24, 2025, 9:24 PM UTC

1718627440 wrote: post #191

wat10000 wrote: post #186

Earlier quoted context omitted.

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 phys…

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.

Re: /dev/null is an ACID compliant database

#193

Post by RiverCrochet » Fri, Oct 24, 2025, 9:55 PM UTC

augusto-moura wrote: post #161

tuetuopay wrote: post #129

Earlier quoted context omitted.

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 fu…

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

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.

Re: /dev/null is an ACID compliant database

#194

Post by 1718627440 » Fri, Oct 24, 2025, 10:01 PM UTC

wat10000 wrote: post #192

1718627440 wrote: post #191

Earlier quoted context omitted.

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 w…

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.

Re: /dev/null is an ACID compliant database

#195

Post by genewitch » Fri, Oct 24, 2025, 11:18 PM UTC

wowczarek wrote: post #72

epistasis wrote: post #43

Earlier quoted context omitted.

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 :)

   set "nul1=1>nul"
   set "nul2=2>nul"
   set "nul6=2^>nul"
   set "nul=>nul 2>&1"

just saw this in a .cmd script

Re: /dev/null is an ACID compliant database

#196

Post by nomel » Sat, Oct 25, 2025, 1:40 AM UTC

PlunderBunny wrote: post #75

nomel wrote: post #50

Earlier quoted context omitted.

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?

We've never had a support request either!

Re: /dev/null is an ACID compliant database

#197

Post by exabrial » Sat, Oct 25, 2025, 5:59 AM UTC

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.

Re: /dev/null is an ACID compliant database

#198

Post by sobani » Sat, Oct 25, 2025, 8:00 AM UTC

Sharlin wrote: post #167

jihadjihad wrote: post #73

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

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 sli…

"The Phillips Machine is an analogue computer which uses fluidic logic to model the workings of an economy."

Re: /dev/null is an ACID compliant database

#199

Post by jefftk » Sat, Oct 25, 2025, 12:21 PM UTC

mpyne wrote: post #80

jefftk wrote: post #58

"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.

Re: /dev/null is an ACID compliant database

#200

Post by seanhunter » Sat, Oct 25, 2025, 1:41 PM UTC

pyuser583 wrote: post #4

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.

That is literally what it was added to unix for.