It's the same as glxgears but for EGL and Wayland. It tests that OpenGL works.

The issue DNS solves is the same as the phone book. You could memorize everyone's phone number/IP, but it's a lot easier to memorize a name or even guess the name. Want the website for walmart? Walmart.com is a very good guess.

Behind the scenes the computer looks it up using DNS and it finds the IP and connects to it.

The way it started, people were maintaining and sharing host files. A new system would come online and people would take the IP and add it to their host file. It was quickly found that this really doesn't scale well, you could want to talk to dozens of computers you'd have to find the IP for! So DNS was developed as a central directory service any computer can request to look things up, which a hierarchy to distribute it and all. And it worked, really well, so well we still use it extensively today. The desire to delegate directory authority is how the TLD system was born. The host file didn't use TLDs just plain names as far as I know.

There's definitely been a surge in speculation on domain names. That's part of the whole dotcom bubble thing. And it's why I'm glad TLDs are still really hard to obtain, because otherwise they would all be taken.

Unfortunately there's just no other good way to deal with it. If there's a shared namespace, someone will speculate the good names.

Different TLDs can help with that a lot by having their own requirements. .edu for example, you have to be a real school to get one. Most ccTLDs you have to be a citizen or have a company operating in the country to get it. If/when it becomes a problem, I expect to see a shift to new TLDs with stronger requirements to prove you're serious about your plans for the domain.

It's just a really hard problem when millions of people are competing to get a decent globally recognized short name, you're just bound to run out. I'm kind of impressed at how well it's holding up overall despite the abuse, I feel like it's still relatively easy to get a reasonable domain name especially if you avoid the big TLDs like com/net/org/info. You can still get xyz for dirt cheap, and sometimes there's even free ones like .tk and .ml were for a while. There's also several free short-ish ones, I used max-p.fr.nf for a while because it was free and still looks like a real domain, it looks a lot like a .co.uk or something.

Because if they're not owned, then how do you know who is who? How do we independently conclude that yup, microsoft.com goes to Microsoft, without some central authority managing who's who?

It's first come first served which is a bit biased towards early adopters, but I can't think of a better system where you go to google.com and reliably end up at Google. If everyone had a different idea of where that should send you it would be a nightmare, we'd be back to passing IP addresses on post-it notes to your friends to make sure we end up on the same youtube.com. When you type an address you expect to end up on the site you asked, and nothing else. You don't want to end up on Comcast YouTube because your ISP decided that's where youtube.com goes, you expect and demand the real one, the same as everyone else.

And there's still the massive server costs to run a dictionary for literally the entire Internet for all of that to work.

A lot of the times, when asking those kinds of questions, it's useful to think about how would you implement it such that it would work. It usually answers the question.

In case you didn't know, domain names form a tree. You have the root ., you have TLDs com., and then usually the customer's domain google.com., then subdomains www.google.com.. Each level of dots typically hands over the rest of the lookup to another server. So in this example, the root servers tell you go ask .com at this IP, you go ask .com where Google is, and it tells you the IP of Google's DNS server, then you query Google's DNS server directly. Any subdomain under Google only involves Google, the public DNS infrastructure isn't involved at that point, significantly reducing load. Your ISP only needs to resolve Google once, then it knows how to get *.google.com directly from Google.

You're not just buying a name that by convention ends with a TLD. You're buying a spot in that chain of names, the tree that is used to eventually go query your server and everything under it. The fee to get the domain contributes to the cost of running the TLD.

Mostly because you need to be able to resolve the TLD. The root DNS servers need to know about every TLD and it would quickly be a nightmare if they had to store hundreds of thousands records vs the handful of TLDs we have now. The root servers are hardcoded, they can't easily be scaled or moved or anything. Their job is solely to tell you where .com is, .net is, etc. You're supposed to query those once and then you hold to your cached reply for like 2+ days. Those servers have to serve the entire world, so you want as few queries to those as possible.

Hosting a TLD is a huge commitment and so requires a lot of capital and a proper legal company to contractually commit to its maintenance and compliance with regulations. Those get a ton of traffic, and users getting their own TLDs would shift the sum of all gTLD traffic to the root servers which would be way too much.

With the gTLDs and ccTLDs we have at least there's a decent amount of decentralization going, so .ca is managed by Canada for example, and only Canada has jurisdiction on that domain, just like only China can take away your .cn. If everyone got TLDs the namespace would be full already, all the good names would be squatted and waiting to sell it for as much as possible like already happens with the .com and .net TLDs.

There's been attempts at a replacement but so far they've all been crypto scams and the dotcom bubble all over again speculating on the cool names to sell to the highest bidder.

That said if you run your own DNS server and configure your devices to use it, you can use any domain as you want. The problem is gonna get the public Internet at large to recognize it as real.

WireGuard works great for that.

Not sure if Voyager exposes such a setting (probably?), but on Tesseract I'd do something like this:

Voyager for Lemmy, at least for me, pushes political content like crazy.

No content is being pushed to anyone, Lemmy's algorithms are very simple. It's just there's a lot of it.

You can unsubscribe from or block the politics and news communities, especially worldnews, and it should get rid of a lot of it. I find the experience to be better when subscribing to the stuff you want rather than remove the stuff you don't want.

Epic is anti-consumer and also anti-Linux, they don't make any effort to support other platforms, the app is shit.

Meanwhile, Steam is

• Actively working with the FOSS community to help preserve old games
  • Kernel improvements for better graphics performance
  • Lots of VR and HDR work
  • Many contributions to the open-source AMD drivers
• Has been supporting Linux gaming for a decade with no signs of backing down
• They have a portable Linux gaming console experience, and it's intentionally left wide open for users to mess with
  • They've taken several community features and built them into the OS
• Their DRM is weak and unintrusive
• Their anticheat is ununtrusive
• The sales are pretty good
• They have tons of features for users:
  • Family sharing
  • Remote Play Together
  • Remote Play
  • Streaming
  • Community forums for every game
  • Mod workshop
  • Matchmaking
  • Steam Chat / Voice Chat / Streaming

The only appealing thing for EGS is, EGS takes a lower cut from the developers who just pockets it and doesn't even result in lower prices for users. As a Linux user, praise our Lord GabeN for all the good Valve has done for gamers. Even for the developers, most are quite happy with the services they get back from that 30% cut.

I'd say the dislike is mainly that for the users, EGS doesn't bring in anything new or interesting or useful that Steam didn't already do well, and goes directly against a lot of the good Steam has been doing. It's just a store that makes big developers slightly more happy.

Isn't he the same person who calls adblocking piracy?

He's also got a generally nuanced opinion of piracy, in that it's justifiable in some situations. If you call it piracy and you're okay with piracy then it's not really a contradiction.

Being willing to talk about it despite working against your interests isn't always bad depending on context.

Basically, the SUID bit makes a program get the permissions of the owner when executed. If you set /bin/bash as SUID, suddenly every bash shell would be a root shell, kind of. Processes on Linux have a real user ID, an effective user ID, and also a saved user ID that can be used to temporarily drop privileges and gain them back again later.

So tools like sudo and doas use this mechanism to temporarily become root, then run checks to make sure you're allowed to use sudo, then run your command. But that process is still in your user's session and process group, and you're still its real user ID. If anything goes wrong between sudo being root and checking permissions, that can lead to a root shell when you weren't supposed to, and you have a root exploit. Sudo is entirely responsible for cleaning the environment before launching the child process so that it's safe.

Run0/systemd-run acts more like an API client. The client, running as your user, asks systemd to create a process and give you its inputs and outputs, which then creates it on your behalf on a clean process tree completely separate from your user session's process tree and group. The client never ever gets permissions, never has to check for the permissions, it's systemd that does over D-Bus through PolKit which are both isolated and unprivileged services. So there's no dangerous code running anywhere to exploit to gain privileges. And it makes run0 very non-special and boring in the process, it really does practically nothing. Want to make your own in Python? You can, safely and quite easily. Any app can easily integrate sudo functionnality fairly safely, and it'll even trigger the DE's elevated permission prompt, which is a separate process so you can grant sudo access to an app without it being able to know about your password.

Run0 takes care of interpreting what you want to do, D-Bus passes the message around, PolKit adds its stamp of approval to it, systemd takes care of spawning of the process and only the spawning of the process. Every bit does its job in isolation from the others so it's hard to exploit.