121–130 of 203 posts
Earlier quoted context omitted.
You've been beaten to the punch: https://devnull-as-a-service.com/
It's down! $ telnet devnull-as-a-service.com 9 Trying 2001:19f0:6c01:497:5400:ff:fe69:8cbf... Connection failed: Connection refused Trying 45.76.95.197... telnet: Unable to connect to remote host: Connection refused
> entreprise
It's ACID compliant. But it's not a database.
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 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
Earlier quoted context omitted.
WTF is going on with the issues and pull requests for that repo?
The less substance there is to it, the easier it is to talk about. The Chinese comments ("issues") also seem to be the same kind of jokes as the English ones, "no code means no bugs, perfect", etc., from the few I tried getting translations of. I imagine this went viral on Chinese social media, which makes sense since it's the sort of joke that's easy to translate and doesn't depend on particular cultural assumptions…
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.
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.
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.
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 fun.
Earlier quoted context omitted.
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.