Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

/dev/null is an ACID compliant database

jyu.dev

Post reply on HN
Print view View original

151–160 of 203 posts

Re: /dev/null is an ACID compliant database

#151

Post by jfengel »

tgv wrote: post #115
jfengel wrote: post #76

Earlier quoted context omitted.

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?

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.

Re: /dev/null is an ACID compliant database

#152

Post by brunoborges »

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

Re: /dev/null is an ACID compliant database

#153

Post by magicalhippo »

rollcat wrote: post #148
magicalhippo wrote: post #140

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]: https://en.wikipedia.org/wiki/Triviality_(mathematics)#Trivi...

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

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.

Re: /dev/null is an ACID compliant database

#155

Post by mort96 »

tuetuopay wrote: post #130
1718627440 wrote: post #53

Earlier quoted context omitted.

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.

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.

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.

Re: /dev/null is an ACID compliant database

#156

Post by PTOB »

brunoborges wrote: post #152

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

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.

Re: /dev/null is an ACID compliant database

#159

Post by schoen »

mort96 wrote: post #155
tuetuopay wrote: post #130

Earlier quoted context omitted.

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.

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…

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?

Re: /dev/null is an ACID compliant database

#160

Post by tuetuopay »

mort96 wrote: post #155
tuetuopay wrote: post #130

Earlier quoted context omitted.

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.

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…

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

Post reply on HN