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.
/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.
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?).
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...
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.
79 comments
[ 22.7 ms ] story [ 105 ms ] threadTruly, it is the only database which can be scaled to unlimited nodes and remain fully CAP.
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.
best post of the week ^^
Considering there is no way to read back data written to /dev/null it will not be useful for storing database data.
‘return 5’
Discussed on HN a few times, but apparently not for a few years now: https://hn.algolia.com/?q=http%3A%2F%2Fwww.supersimplestorag...
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.
https://www.linusakesson.net/programming/pipelogic/index.php
Past HN post: https://news.ycombinator.com/item?id=15363029
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...
"The Phillips Machine is an analogue computer which uses fluidic logic to model the workings of an economy."
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)