step 2 of this process involves making a backup. whether they understand how they did so or not.
pixelscript
joined 2 years ago
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.
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.
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.
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.
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.
"iPad babies" seems to be the closest thing we have at the moment. Only time will tell if that sticks.