No, they can quit whenever they want, they just don’t want to.

But it’s past me, I swear. Reckless acts of a younger man.

Yeah, it’s crazy how much a person can change in 20 minutes.

That sounds like admitting defeat “you don’t care about any arguments I could make”

So not a fallacy?

And so, the problem wasn’t the ai/llm, it was the person who said “looks good” without even looking at the generated code, and then the person who read that pull request and said, again without reading the code, “lgtm”.

If you have good policies then it doesn’t matter how many bad practice’s are used, it still won’t be merged.

The only overhead is that you have to read all the requests but if it’s an internal project then telling everyone to read and understand their code shouldn’t be the issue.

SystemG ^{sadly doesn’t exist}

The one I forgot, obviously.

DNS turns a domain name into an IP which can then be used to send data through your router, a dns server is the server which is used to do this conversion (www.google.com turns into an IP 1.2.3.4 (that isn’t the actual IP of google)).

There are many dns servers, normally your local devices use your router as the dns server, which forwards it to your ISP which they further transfer it over global dns servers.

Alternatively you could use Google’s DNS server (8.8.8.8) or cloudflares DNS server (1.1.1.1) but if the one on your router works then just use it.

nameserver is the same as DNS server

Tldr: set the router IP as your dns server, you only need this one.

…that’s the valid response, does ping www.google.com work and curl www.google.com return a bunch of text?

If ping www.google.com doesn’t work then your system isn’t using the correct dns server, though your local dns server works (as seen by the prior dig).

If curl works then…you have a working internet connection, maybe check the browser settings for proxy or something.

That seems correct, don’t change anything in there, try the command dig @<routerip> www.google.com or nslookup www.google.com <router ip> if the dig command is not found.

No one can ping 4.4.4.4, it doesn’t answer pings.

This seems like a dns issue, check cat /etc/resolv.conf and try setting the dns server in Networkmanager to “8.8.8.8”.

Gluster is EOL is my biggest takeaway.

…No really, has anyone used this warranty and if so, what does it actually do? (And I mean strictly home users)

Maybe they don’t officially offer support for those PCs?
Not like they offer any actual support for home users anyways…

Did he stutter?

NVK seems to be moving way faster than I expected.

The truth hurts.

But…an onion address doesn’t need a cert?

Nobody expects the spanish fediverse

see systemd.unit(5), systemd.service(5), systemd.socket(5), systemd.device(5), systemd.mount(5), systemd.automount(5), systemd.swap(5), systemd.target(5), systemd.path(5), systemd.timer(5), systemd.slice(5), systemd.scope(5) systemd.link(5), systemd.netdev(5), systemd.network(5) and honorable mentions podman-systemd.unit .container, .volume, .network(…again), .kube, .image, .build and .pod