pixelscript

In theory, not voting is a protest strategy where you tie up a wealth of votes behind some set of issues, and thus incentivize politicians to platform those issues to court those votes.

In reality, next to none of the suits in power want anything to do with your issues, and they are tickled pink that they've managed to convince you to voluntarily self-select out of the process.

Thus gen alpha, who haven't been around long enough to develop an identity resulting in a catchier nickname.

"iPad babies" seems to be the closest thing we have at the moment. Only time will tell if that sticks.

step 2 of this process involves making a backup. whether they understand how they did so or not.

I have lived in a home with a ceiling fan for nearly 30 years and I cannot confidently answer this question off the top of my head.

Maybe that's just tremendous skill issue on my part, but recognizing that all ceiling fans are standardized to spin only one way and knowing which way that is seems like a weird thing to ask of someone who also needs a mnemonic for which way to tighten screws.

Not to mention a rapidly growing segment of the population is unable to read analog 12 hour clocks, so the analogy is not that helpful.

Those are some really theoretical ways to observe a clock face.

How about we just start saying, "torque in, torque out"? When the torque vector points in, the screw goes in (tightening). When it points out, the screw comes out (loosening). As long as you are standing on the side of the screw you can actually work with while working with it (and why wouldn't you be?) this is never ambiguous.

Of course, now we're kicking the can down the road and relying on people wrapping their heads around the right hand rule... Hmm...

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.

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"?

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...