This, 100%. The only value of preordering is guaranteeing stock of a physical item that threatens to be out of stock if you were to buy it walk-in. In the modern digital age where downloading tens of gigabytes that take up no space, ship near-instantly on demand, and have theoretically infinite supply, preordering is pointless if the actual game itself is all you care about.

Is this because the kernel assigns that port to that specific process, so that all traffic at that port is associated with only that process?

Yes, that's what ports do. They split your IP connection into 65,536 separate communication lines, that's the main thing, but that is specifically 65,536 1-on-1 lines, not party lines. When a process on your PC reserves port 80, that's it. It's taken. Short of hacking the kernel itself, it cannot be reassigned or stolen until the bound process frees it.

The SO answer you found it interesting, I was not aware that the Linux kernel had a feature that allowed two or more processes to willingly share a single port. But the answer explains that this is an opt-in parameter that the first binding process has to explicitly allow. And even then, traffic is not duplicated to all listening processes. It sounds like it's more of a "first come first serve" to whichever of the processes are free to read the incoming message at the time it arrives, making it more of a load balancing feature that isn't a useful vector for eavesdropping.

To me it comes off like you're irrationally afraid to invoke its name.

I get and appreciate that you're trying to make a statement here, but in my opinion it isn't landing the way you think it is. By giving its name special reverence you're needlessly elevating it, not diminishing it.

The point of the firewall is not to make your computer an impenetrable fortress. It's to block any implicit port openings you didn't explicitly ask for.

Say you install a piece of software that, without your knowledge, decides to spin up an SSH server and start listening on port 22. Now you have that port open as a vector for malware to get in, and you are implicitly relying on that software to fend it off. If you instead have a firewall, and port 22 is not one of your allowed ports, the rogue software will hopefully take the hint and not spin up that server.

Generally you only want to open ports for specific processes that you want to transmit or listen on them. Once a port is bound to a process, it's taken. Malware can't just latch on without hijacking the program that already has it bound. And if that's your fear, then you probably have a lot of way scarier theoretical attack vectors to sweat over in addition to this.

Yes, if you just leave a port wide open with nothing bound to it, either via actually having the port reserved or by linking the process to the port with a firewall rule, and you happened to get a piece of actual malware that scanned every port looking for an opening to sneak through, sure, it could. To my understanding, that's not typically what you're trying to stop with a firewall.

In some regards a firewall is like a padlock. It keeps out honest criminals. A determined criminal who really wants in will probably circumvent it. But many opportunistic criminals just looking for stuff not nailed down will probably leave it alone. Is the fact that people who know how to pick locks exist an excuse to stop locking things because "it's all pointless anyway"?

Back when I was still using Ubuntu MATE about half a year ago or so, I started having this really odd problem where signing into my account after a reboot would bring me to a blank screen with only my desktop background and nothing else. No taskbar, no panels, not even the cursor if I recall correctly.

Some furious Googling brought me to a serverfault thread that suggested that switching to tty7 with CTRL + ALT + F7 followed by ALT + F1 to switch back would alleviate it... and it did! But the problem returned on every login.

So for about six months I just had that as part of my routine on any reboot. Log it, switch to tty7, switch back to tty1. It was stupid and I hated it. Mostly because I didn't understand what I was doing or why it fixed anything.

On a tangent, this is precisely the thing that makes people intimidated by Linux, I think... it's not so much the inability to do things. Rather, even when you are given a way on a silver platter, you don't feel like you're really in control because you don't know what the black magic incantation really does. It's a truly horrible feeling.

I never did resolve the problem. I eventually nuked that OS and paved over its ashes with Debian Testing + KDE Plasma 5, and I haven't looked back.

This question reads a bit to me like someone asking, "Why do trapeze artists perform above nets? If they were good at what they did they shouldn't fall off and need to be caught."

Do you really need a firewall? Well, are you intimately familiar with every smidgeon of software on your machine, not just userland ones but also system ones, and you understand perfectly under which and only which circumstances any of them open any ports, and have declared that only the specific ports you want open actually are at every moment in time? Yes? You're that much of a sysadmin god? Then no, I guess you don't need a firewall.

If instead you happen to be mortal like the rest of us who don't read and internalize the behaviors of every piddly program that runs or will ever possibly run on our systems, you can always do what we do for every other problem that is too intensive to do manually: script that shit. Tell the computer explicitly which ports it can and cannot open.

Luckily, you don't even have to start from scratch with a solution like that. There are prefab programs that are ready to do this for you. They're called firewalls.

The way I understand it is like this:

The grand theory of classic package managers is the idea that lots of programs all need the same core libraries to function. An analogy would be like noticing most construction jobs need nails. So instead of making everyone bring their own copy of nails, resulting in dozens of redundant copies of it lying around, they have a single nails package that everyone can use.

But there are different versions of nails out there. Each version picks up unique new features, and drops legacy ones. Recent builds may incorporate and thus require the new features, making them incompatible with old versions of nails that don't have them. On the other hand, some builds may still use and rely on legacy features of nails, and are thus incompatible with the new versions. You may run into a scenario where you want Software A that needs nails version 14+, but also Software B that can only run on nails v <13, and you just can't, because they don't overlap.

Additionally, there may just be a totally different competing package out there, screws, that does largely the same job as nails, but in a completely different way that is totally incompatible with projects that expect nails. So if you need Software C that relies on nails, but also Software D that relies on screws, you might cause problems by installing both.

What a distro is is essentially a group of devs declaring that they are putting together some specific list of libraries (like, say, nails v14), and then sculpting up a bundle of software around those specific libraries. Can't cope with nails v14? That sucks. No package for you, then.

In that sense, distros are differentiated by what libraries and other low-level system softwares are available to the programs you wish to install on them. If you want your program to be available natively on every distro, it needs to be compatible with every competing set of libraries each distro has elected to use.

It is possible to just say "fuck it" to the distro's built-in libraries, and instead bundling the specific version of nails or screws or whatever you project needs directly with it. Build your own with blackjack and hookers, as it were. That's exactly what Flatpak does, among others. But it's trading flexibility for redundancy. In the age of cheap and plentiful storage memory, many people think this trade is well worth it. But it makes many formalists cringe.

imagine if every application on your desktop reacted differently depending on how many times you clicked a spot

yeah, wow, imagine. different applications using different design patterns for different contexts. perish the thought!

Is that also OK just because one browser started doing it and every other browser copied that function?

one browser did an arguably useful thing, every other browser agreed it was arguably useful, and it became a widely adopted feature? sounds ok to me. gee, it's almost like this is how standard patterns come to be, or something...

I admire the respect you have for those who ask questions like this, but I think I disagree.

If there is something egregiously wrong with the premise of what a person is seeking to do, and there are no qualifying statements in their query about why they do in fact need to do this specifiic thing in this specific way, chances are high that they are uneducated about why the premise of what they're trying to do is flawed, and they are best served by being course corrected. Giving them the answer they're looking for to continue the bad thing while hiding your suggestion of what they should be doing instead in a footnote is just enabling them to double down on the short term path of least resistance that will probably come back to bite them again later.

If they really did know what they were doing with regards to doing an otherwise unsafe and/or unsupported thing, or if the restrictions tied their hands from using the obvious replacement solution, it either should have appeared in their question prompt, or it should be in the first replies to the first round of answers.

I say, withhold outdated advice unless the context of the conversation makes it explicitly clear that the old advice is genuinely required and not substitutable with current advice. But also don't be smug, rude, dismissive, or standoffish about it. Don't argue with someone who says they really do need a specific solution.

That said, this only applies in really cut and dry cases like this one, where there very clearly is an indisputable thing you shouldn't be doing, and a drop-in replacement you should be using. The ones I hate are moreso those you may see on StackOverflow where the question is like, "how do I do in JavaScript?" and five of the seven responses including the accepted answer offer a solution in some big dumb framework or lib that they apparently expect you to just incorporate into your project.

I believe your "checkup" and their "routine cleaning" are the same thing.

Lots of people (myself included) refer to it as a "cleaning" because, well, regardless of anything else, that's what they actually do to you. I don't know anyone who goes to a dentist just to have them look but they don't touch. They clean you, too. That's almost always the only physical takeaway effect of one of these visits.

Also, a dentist cleans your teeth in a way you almost certainly can't. Their practiced hands know exactly what needs to be scraped away, and they can make informed decisions on what tool to do it with and how aggressively to not cause enamel damage. Not to mention they can, y'know, actually see what they're doing in there. So a "simple cleaning" isn't quite as pedestrian as it sounds. It's not something you can fully replicate by scraping around blindly with a metal pick in your mouth.

I'd argue this is at the root of all fringe theories and why they all seem to attract the same archetypes of people.

We are living in an era of history where long traditional societal norms are in rapid turnover. The "old ways of doing things" are dying off, and the new ways that replaced them are often a revolving door. Very little in the world at any given time feels stable and secure.

Institutional trust is breaking down. Interacting with the world in good faith is increasingly leaving you open to abuse by bad actors. Why trust anything, then? Trust is for rubes. You're an intelligent, free, and independent thinker. You should question anything and everything that is simply handed down to you. Especially if it is unintuitive. To not do so is to be railroaded.

And it's that last part in particular that identifies the most fertile candidates for a good conspiracy theory. Like, is the Earth round? It looks flat to me. Essentially all evidence you can throw at the notion falls either into at least one of, "I witnessed it, trust me bro", "hope you like letters in your math equations" (people who can't intuit math won't be impressed by any proofs), or "you can do this experiment at home, you just need / so you can watch for ". A depressing sum of people in the world will remain unconvinced by any demonstration that isn't simple, intuitive, and of an overwhelmingly obvious magnitude. Complex answers or answers that observe tiny effects are scams.

And just like that, we've abandoned rational thought and replaced it with trust-averse thought. We've invented the notion that the world is a hostile place where anyone trying to hand you something is an agenda-pusher trying to extract something of value from you. All of the world's major institutions are shams designed to keep you complacent in some sort of world order that is merely using you. To participate in it is to further your enslavement.

In that hellish headspace, conspiracy theories almost feel like a haven. Finally! A group of real thinkers who share your frustrations about the world! The underground movement working to free us all from the hostile system!

Except, no. At best it's just a bunch of people who are wrong indulging in a little harmless escapism. At worst it's a mass of people getting Immanuel Goldstien'd by the very kind of well-spoken swindler they're breaking their collective backs bending over to avoid in the first place. Regardless the form it takes, my hypothesis remains: proliferation of conspiracy theories is merely a symptom of a lack of trust.