Live data from Hacker News

/dev/null as a Service

devnull-as-a-service.com

71–80 of 96 posts

Re: /dev/null as a Service

#71

Earlier quoted context omitted.

I second this one! makes more sense than plain 200.

I can't believe you guys are debating the correct HTTP return code for a joke service? Besides, it's obviously 200.

Well with the planned dev/random support, this is going to kick ass.

Re: /dev/null as a Service

#73

Earlier quoted context omitted.

I second this one! makes more sense than plain 200.

I can't believe you guys are debating the correct HTTP return code for a joke service? Besides, it's obviously 200.

Does it discard data in a manner compliant with FIPS 140-2? Or NIST SP800-88?

Re: /dev/null as a Service

#74
post #66

One reason I am not a devfs fan is because I'm a mknod(1) user. For example, FreeBSD has one of those famous "_________ is deprecated" bold warnings regarding mknod. It is not deprecated in my usage. I use it all the time. I do not rely on /dev/null. I make my own null character devices as I need them.

> I do not rely on /dev/null.

> I make my own null character devices as I need them.

Why? Is there ever a reason to have more than one file on your system which acts as a /dev/null?

Re: /dev/null as a Service

#76
post #43

Earlier quoted context omitted.

"200" makes sense. See wikipedia article on /dev/null[0]: "discards all data written to it but reports that the write operation succeeded." [0] - http://en.wikipedia.org/wiki//dev/null

wouldn't 202 be better?

204 No Content would.

202 assumes a possibility of further processing, but /dev/null can offer none.

Re: /dev/null as a Service

#77
The website is missing a "meet the founders" page with the pre-pubescent CEO, CTO, Director of Marketing and Director of Customer Excellent, who just happens to be the CTO's little sister.

Re: /dev/null as a Service

#78
post #74
post #66

One reason I am not a devfs fan is because I'm a mknod(1) user. For example, FreeBSD has one of those famous "_________ is deprecated" bold warnings regarding mknod. It is not deprecated in my usage. I use it all the time. I do not rely on /dev/null. I make my own null character devices as I need them.

> I do not rely on /dev/null. > I make my own null character devices as I need them. Why? Is there ever a reason to have more than one file on your system which acts as a /dev/null?

"Why?" Why not?

In my case, the reason is because it's shorter to type.

I would expect most longtime UNIX users have experienced what happens when, for one reason or another, /dev/null is not a null character device and you have scripts or programs writing to it as if it was. By the time you realize that this has happened, it's too late -- data has already been saved to this file.

There may be various workarounds for this. I'm not a professional sysadmin.

But in my case, for my own personal usage systems, by using my own null character device in my own tmpfs mounted folders, I can just test for the success/failure of the mknod command before I start redirecting anything to it.

I don't need a /dev/null. But I do need mknod.

Re: /dev/null as a Service

#79

You guys and your fancy HTTP services. Discard should be enough for everyone. http://tools.ietf.org/html/rfc863

Discard is fundamentally flawed. Because the service does not provide a response the client cannot reliably determine whether the data was successfully discarded.

Without a response there's the possibility that your data could be lost on its way to being thrown away, and you'd never know.

Post reply on HN