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

51–60 of 203 posts

Re: /dev/null is an ACID compliant database

#51

Post by charcircuit »

chrisweekly wrote: post #49
charcircuit wrote: post #31

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

seems you've missed the joke

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.

Re: /dev/null is an ACID compliant database

#52

Post by jonathrg »

charcircuit wrote: post #31

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

You can store any data as long as it doesn't contain any ones

Re: /dev/null is an ACID compliant database

#53

Post by 1718627440 »

noir_lord wrote: post #22
CaptainOfCoit wrote: post #10

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.

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.

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.

Re: /dev/null is an ACID compliant database

#54

Post by 1718627440 »

fukka42 wrote: post #40
epistasis wrote: post #25

Earlier quoted context omitted.

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.

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.

> I guess Unix pipes are slow.

Or string concatenation, or pipeviewer.

Re: /dev/null is an ACID compliant database

#56

Post by __turbobrew__ »

rezonant wrote: post #26
fukka42 wrote: post #20

Earlier quoted context omitted.

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.

What's the best hardware for running a /dev/null instance for production?

A single resistor at ground voltage.

Re: /dev/null is an ACID compliant database

#57

Post by fukka42 »

1718627440 wrote: post #54
fukka42 wrote: post #40

Earlier quoted context omitted.

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.

> I guess Unix pipes are slow. Or string concatenation, or pipeviewer.

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.

https://github.com/coreutils/coreutils/blob/master/src/yes.c

Post reply on HN