Live data from Hacker News

/dev/null is an ACID compliant database

jyu.dev

161–170 of 203 posts

Re: /dev/null is an ACID compliant database

#161

Earlier quoted context omitted.

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.

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

Re: /dev/null is an ACID compliant database

#162
post #124
post #123

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

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

Re: /dev/null is an ACID compliant database

#164

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

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

Re: /dev/null is an ACID compliant database

#165
post #50

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.

It's great. We saw a 2000% throughput increase on our business analytics platform when we switched to a /dev/null backend.

Re: /dev/null is an ACID compliant database

#167

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

Re: /dev/null is an ACID compliant database

#168

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…

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.

Re: /dev/null is an ACID compliant database

#169

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.
Post reply on HN