Solving the housing crisis
pixelscript @ pixelscript @lemmy.ml Posts 0Comments 240Joined 2 yr. ago
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.
I don't understand why anyone would ever get onto a new commercial social media platform again now the Fediverse exists.
Lots of reasons:
- It's bigger and less fragmented. More content, more diversity, more activity, and it's all in one easy place.
- No extra conceptual hurdles to overcome like "what is an instance" or "which instance do I join".
- Network effect. See point 1. Unless you are some kind of FOSS enthusiast or a refugee of every other social media platform due to your vulgar, sexual, illegal, and/or politically extreme interests, your friends, followed creators, and other people of interest have a far higher chance of being on BlueSky than the Fediverse.
- An actual algorithm. Many people who jump to the Fediverse hate it, but a silent majority of casual users actively want it. Meticulously curating your own feed is not a boon to them, it is a chore.
A lot of the crap that the Fediverse did not inherit from its commercial counterparts is precisely what a lot of users are there for. And a lot of the expanded tooling and control the Fediverse alternatives offer are pearls before swine with most of these folks. Overall it just makes the Fediverse appear flakey, underbaked, and devoid of content.
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.
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.
Permanently Deleted
My household growing up was drowning in thermoses and water bottles. In large part due to having two kids in competitive high school sports and one in competitive highschool arts and sciences.
It's one thing to have a bunch of kids who need and use water bottles on the regular, but it's entirely another thing when all these institutions simultaneously declared, "Trophies? Ribbons? Placards? Those utter wastes of space? We should be giving these kids useful prizes for winning their events!" Cue racking up four or five cheap, flimsy water bottles and other assorted crap per kid per year...
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.
deleted by creator
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
<X>
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.This kinda flies in the face of what I heard the Palworld devs are: a rag-tag handful of nobodies on a budget of $0 making a Steam game in their free time.
I heard they didn't even use a version control system because they didn't know how to use one, they just put a copy of the code repo on a flash drive once a day, and when they ran out of drives, they went to the store to buy more.
If even a slightly less embellished version of half of what I've heard is true, I wager none of these people got anywhere near a lawyer before putting this game out.
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.
Private contractors also prefer building single family homes because they get paid way more to do 50 individual houses than put up an apartment that houses 50.
We aren't here because people are stupid. We are here because this is where all the incentives align.