They need to stop it from “answering” anything about real time events. For another example, I tried going to SDF and noticed my SSH connection attempts immediately failing. Some additional commands showed some more info.
amcclure@ocelot:~$ ping sdf.orgPING sdf.org (205.166.94.16) 56(84) bytes of data.64 bytes from sdf.org (205.166.94.16): icmp_seq=1 ttl=241 time=58.9 ms64 bytes from sdf.org (205.166.94.16): icmp_seq=2 ttl=241 time=64.7 ms^C--- sdf.org ping statistics ---2 packets transmitted, 2 received, 0% packet loss, time 1001msrtt min/avg/max/mdev = 58.856/61.759/64.663/2.903 msamcclure@ocelot:~$ lynx 205.166.94.16 --dumpLooking up 205.166.94.16Making HTTP connection to 205.166.94.16Alert!: Unable to connect to remote host.lynx: Can't access startfile http://205.166.94.16/amcclure@ocelot:~$ lynx http://sdf.org --dumpLooking up sdf.orgMaking HTTP connection to sdf.orgAlert!: Unable to connect to remote host.lynx: Can't access startfile http://sdf.org/amcclure@ocelot:~$ lynx https://sdf.org --dumpLooking up sdf.orgMaking HTTPS connection to sdf.orgAlert!: Unable to connect to remote host.lynx: Can't access startfile https://sdf.org/amcclure@ocelot:~$ ping cdn.redhat.comPING cdn.redhat.com (2600:1480:4000:1f3::) 56 data bytes64 bytes from g2600-1480-4000-01f3-0000-0000-0000-0000.deploy.static.akamaitechnologies.com (2600:1480:4000:1f3::): icmp_seq=1 ttl=51 time=2.77 ms64 bytes from g2600-1480-4000-01f3-0000-0000-0000-0000.deploy.static.akamaitechnologies.com (2600:1480:4000:1f3::): icmp_seq=2 ttl=51 time=2.16 ms64 bytes from g2600-1480-4000-01f3-0000-0000-0000-0000.deploy.static.akamaitechnologies.com (2600:1480:4000:1f3::): icmp_seq=3 ttl=51 time=2.13 ms^C--- cdn.redhat.com ping statistics ---3 packets transmitted, 3 received, 0% packet loss, time 2003msrtt min/avg/max/mdev = 2.133/2.355/2.771/0.294 msamcclure@ocelot:~$ ping cdn.redhat.com -4PING cdn.redhat.com (23.206.56.100) 56(84) bytes of data.64 bytes from a23-206-56-100.deploy.static.akamaitechnologies.com (23.206.56.100): icmp_seq=1 ttl=51 time=2.37 ms64 bytes from a23-206-56-100.deploy.static.akamaitechnologies.com (23.206.56.100): icmp_seq=2 ttl=51 time=1.96 ms64 bytes from a23-206-56-100.deploy.static.akamaitechnologies.com (23.206.56.100): icmp_seq=3 ttl=51 time=1.62 ms^C--- cdn.redhat.com ping statistics ---3 packets transmitted, 3 received, 0% packet loss, time 2003msrtt min/avg/max/mdev = 1.615/1.983/2.371/0.308 msamcclure@ocelot:~$
If the cdn.redhat.com pings weren’t proof of anything: it’s not the network interface/connection on ocelot.aperware.com that’s having issues. Trying to search Google brought forth some less-than-good fruit.

We were told that “by their fruits you shall know them” after all, and since the LLM hasn’t brought forth good fruits… ya know…
Here was a second source showing the downtime by the way.

Not a good look for Google or the tech industry as a whole when AI and especially LLMs are still the big thing that too many people treat as the greatest thing ever in recent years. If that’s not bad enough, there will be people who read this and say that the problem is my “prompt” (formerly known as a “search query”) was bad. Apparently “you’re just prompting it wrong.”
Over on the orangesite we have a comment responding to one that pointed out how demoing an LLM requires a ginormous prompt, saying: “The gigantic prompt has a side benefit though: it’s documentation on design and rationale that otherwise would typically not get written.” Documentation that only applies to a singular specific run of the program though. Different runs and different models give vastly different results, so what’s being documented? Something that will be here today and gone not much later the same day?
On that thought, maybe LLMs were even more of a mistake than many of us had already realized they were. LLMs might be “here to stay” but that shouldn’t mean we need to be forced to use them if we don’t want to.




