Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

> Someone else in the world reported the problem back in September, and aside from some random person asking a totally useless question, nothing had happened on the thread.

It's a special kind of horror to find, after hours of high-end-googling, the one thread where someone reports the same problem you are experiencing, and it's just the question, and then one other person asking if the problem has been solved because she/he is having the same problem.

The one thing that is worse is if the OP then makes another post that simply says "Solved it! =D", without giving any explanation on how they solved it.



Or when you find a thread where someome is asking the question and the only response is by some wise guy telling him to "search". And of course, searching keeps pointing you back to the same thread.


No no, The very _worse_ thing is when there is only one answer saying he found a solution but doesn't provide any information.


Also, when 4 years later you come back to the thread to find it is was you, asking the question before.


On the plus side, the last time this happened to me, I discovered that someone had posted a really useful answer to my question which helped solve me problem.

The person who had posted the answer was, of course, also me.


this is working as intended; the web is an external memory.


My experience is that said person coming back to my thread is a coworker. Then they tell me they can't get away from me and even after they try to find something on their own I helped them fix it. Quite amusing


haha! OMG, that has happened to me before!


My favorite is "Oh, you can find the answer here: http://brokenlink.com"


At least half of every enterprise software I have used suffers from catastrophic link rot. And when you look at the URLs that do still map or redirect to something marginally on-topic, you just know it's a single API change away from redirecting to "we don't know what you're looking for, try searching here for hundreds of completely off topic (and occasionally broken) links".

No, I am not bitter. Learning where their FTP server is and how to navigate, well, that was gold.


This can often be solved by prepending

    https://web.archive.org/web/*/
to the now broken URL.


Hmm, there must be some extension that detects 404 errors and/or server unresponsive and prompts whether you want to check Google's cache or the Internet archive. That browsers haven't already integrated this (with a configurable list of archiving services, like search engines), is actually rather surprising to me.


There are many such extensions, but yes, we're working on getting directly integrated into Firefox, Chrome, Edge, and if anyone has a contact at Safari (or one of the other browsers), my email addr is in my profile. Thanks.



There are extensions with that kind of functionality, but by now I have that sequence hardwired in my fingers.


And then finding that the page is blocked by a robots.txt that is present now, but probably wasn't when the page originally existed.


Robots.txt is respected retroactively?


Yes, but it is only temporary. As long as you have a robots.txt file excluding some URLs, those URLs will: 1) not be crawled by the Internet Archive crawler, 2) not be shown in the Wayback Machine. Any already-crawled pages will, however, invisibly remain in the archive, and will reappear once they are not in the robots.txt anymore.


Mmmh, that has never happened to me. That is just plain mean.

Now that I think of it, I have seen that happen, but the reply was inevitably "I have already googled the question to death, without finding any useful results."


This EXACTLY!



Yes, thank you. I was kind of thinking of that one but too lazy to look it up.


Someone should reply "tc qdisc add dev eth0 root netem delay 100ms" in the original thread [ https://communities.vmware.com/thread/519888 ] and link to the blog post. Ideally that person would know enough about tc to suggest how to do it only for outbound tcp6 handshakes too.


> suggest how to do it only for outbound tcp6 handshakes too.

Here you go:

    ip6tables -A OUTPUT -t mangle -m multiport -o eth0 --protocol tcp \
              --tcp-flags ALL SYN --dports 80,8080,443 -j MARK --set-mark 6

    tc qdisc del dev eth0 root
    tc qdisc add dev eth0 root handle 1: htb default 1
    tc class add dev eth0 parent 1: classid 1:6 htb rate 10000Mbps
    tc qdisc add dev eth0 parent 1:6 handle 6: netem delay 100ms
    tc filter add dev eth0 protocol ipv6 prio 1 handle 6 fw flowid 1:6
Although, I would personally throw in an extra class to add 200ms delay to legacy IP protocol:

    iptables -A OUTPUT -t mangle -o eth0 -j MARK --set-mark 4
    ip6tables -A OUTPUT -t mangle -o eth0 -m multiport --protocol tcp \
              --tcp-flags ALL SYN --dports 80,8080,443 -j MARK --set-mark 6

    tc qdisc del dev eth0 root
    tc qdisc add dev eth0 root handle 1: htb default 1
    tc class add dev eth0 parent 1: classid 1:4 htb rate 10000Mbps
    tc class add dev eth0 parent 1: classid 1:6 htb rate 10000Mbps
    tc qdisc add dev eth0 parent 1:4 handle 4: netem delay 200ms
    tc qdisc add dev eth0 parent 1:6 handle 6: netem delay 100ms
    tc filter add dev eth0 protocol ip prio 4 handle 4 fw flowid 1:4
    tc filter add dev eth0 protocol ipv6 prio 6 handle 6 fw flowid 1:6

...just to be compliant with draft-howard-sunset4-v4historic-00 once it becomes RFC.


Even worse than "Solved! With no explanation" is being told by ten different people how I shouldn't be doing X anyway, and simply do Y instead.


The worst is when somebody reports "solved it", then you spend four hours figuring out why it didn't work only to learn the kernel changed behavior (this happened to me recently) and the problem can't be fixed.




Consider applying for YC's Winter 2026 batch! Applications are open till Nov 10

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: