Seems like a good reason you should need to "pair" the RF remote to the device, similar to Bluetooth. Otherwise a bad actor in an apartment complex could get a "universal" RF remote and randomly try stuff until they can control your devices.
Honestly I could see arguments going both ways. Pairing prevents unauthorized access, but at the same time, pairing means you need to be able to pair without having a paired device on-hand.
For a passive read-only device (like most satellite/cable receivers 20 years ago), it was probably more important to allow customers to easily replace their lost remotes than it was to prevent pranksters (who could often be dissuaded by more physical means).
The WD in WD-40 stands for "water displacer." It makes water go somewhere else. Secondarily, it is a solvent, and it's great for dissolving glues, like the glue used to affix government-issued tax licenses to automobiles. It's not really a lubricant, but in a pinch it can temporarily function as one.
I like Swiss army knives, but they collect lint and gunk from my pockets. I use WD-40 to dissolve gunk, and to drive out water after an ultrasonic bath, but I lubricate with the light machine oil used for barber's clippers.
It is a blend of oils.
Light oils evaporate (like kerosene does for example), and dissolve thicker oils and grease.
Oils displace water in general and once in the surface pores they prevent water from getting in there again, a mixture containing light oils flows in easier and does that better.
Being predominantly a light oil it is a poor lubricant, but it is better than nothing, and can flow in crevices where thicker stuff would not.
It is really simple and there is no magic.
The name took off as a brand and completely different stuff from the 40th iteration of a Water Displacer formulation is being sold under it as well.
> It's not really a lubricant, but in a pinch it can temporarily function as one.
That's wrong. WD-40 is a literally a lubricant mixed with a solvent that makes it very fluid so it can enter small interstices, the solvent then evaporates quickly, leaving the lubricant in place.
There's not a lot of lubricant in there compared to a pure lubricant, because the solvent takes a significant share of the volume, but it's still a lubricant once the solvent dries up.
You're technically correct, the best kind of correct.
However, if you're looking to lubricate something and have it last for a reasonable time, then WD-40 is a poor choice. However, using WD-40 first to hopefully dissolve contaminants/rust and remove water and then after a quick wipe to remove excess, applying something better such as 3-in-1 or silicone grease etc is a good idea.
The clue is in the name - Water Displacement 40.
If you want a spray on penetrating lubricant, then GT-85 is usually better as it has PTFE included to better lubricate. It still won't last that long though as it'll only make a thin film.
Edit: I've just seen that WD-40 make mention of a bus driver in Asia using WD-40 to remove a python from his bus' under-carriage. If in doubt, spray it with WD-40.
It literally says it is a lubricant on the can but you can’t find a thread on the Internet about it without someone saying that. It is a lubricant, just not a very good one for most situations.
I’m not surprised. If your hobbies include things that take you to the DIY corners of Reddit you are exposed daily to the “WD-40 is not a lubricant” morons who cannot be swayed by either reading the can or Googling.
“WD-40 is not a very good lubricant and you should almost always use something else” is a mouthful I guess, but their denial of reality over something so meaningless is always astounding to me.
There is a certain type that loves to be contrarian, and they keep a whole mental library of "unintuitive factoids" at the ready for the topic to arise.
The unexpected part though, is that I don’t think this is causing people to actually believe that WD-40 is not a lubricant. It’s causing them to post that perhaps.
And it seems like such a strange thing to become emotionally attached to. But these people will sooner die then admit the thing that says it is a lubricant is a lubricant.
>is that I don’t think this is causing people to actually believe that WD-40 is not a lubricant.
Why do you believe this? The vast majority of people commenting on the internet haven't used WD-40 in the past year. Why wouldn't they end up believing a wrong thing that has been confidently stated that they otherwise know nothing about?
People have always loved these factoids, long long before the internet. It was common conversation fodder for upper class folks in history to repeat outright falsehoods as "um actually"s or "You should know"s.
Do you know how many people for whatever reason believe that Columbus believed the earth was round and everyone else thought it was flat, despite all historical evidence being contrary?
Basically "Common consensus is X but I'm super smart and know REAL truth Y" is like the optimal meme shape for the human brain. The biases in our brain will always support such an argument shape, and humans get a reward for relaying that info, correct or not. All our innate and fundamental physiological biases will be triggered by this kind of statement.
IMO the super interesting aspect is the second and third generations of "Um actually" where a previous "um actually" gets further "um actually!"d, and even that gets "um actuallyyyyy"d. I wonder if we will get a cycle at some point!
Some things are lubricants for a little while, until they suddenly become the opposite. Wood glue, for example.
That’s how I would describe the original and most common WD-40 formula: a passable short-term lubricant for quick and dirty jobs, but not a long-term high quality lubricant, like, say, 3-in-1 (graphite) or silicone lubricants.
Adding to the confusion is that WD-40 sells a silicone lubricant that is a much better lubricant for many purposes than the original formula.
Yeah, it mostly evaporates and only leaves a thin film behind. It's better than nothing if there's no lubricant in place, but will actually make things worse if there is a functional lubricant in place.
I've seen stuff like this go the opposite direction with researchers (who generally aren't software engineers):
"I used claude to port a large Rust codebase to Python and it's been a game changer. Whereas I was always fighting with the Rust compiler, now I can iterate very quickly in python and it just stays out of my way. I'm adding thousands of lines of working code per day with the help of AI."
I always cringe when I read stuff like this because (at my company at least), a lot research code ends up getting shipped directly to production because nobody understands how it works except the researchers and inevitably it proves to be very fragile code that is untyped and dumps stack traces whenever runtime issues happen (which is quite frequently at first, until whack-a-mole sorts them out over time).
> Well designed security models don't sell computers/operating systems, apparently.
Well more like it's hard to design software that is both secure-by-default and non-onerous to the end users (including devs). Every time I've tried to deploy non-trivial software systems to highly secure setups it's been a tedious nightmare. Nothing can talk to each other by default. Sometimes the filesystem is immutable and executables can't run by default. Every hole through every layer must be meticulously punched, miss one layer and things don't work and you have to trace calls through the stack, across sockets and networks, etc. to see where the holdup is. And that's not even including all the certificate/CA baggage that comes with deploying TLS-based systems.
> Every time I've tried to deploy non-trivial software systems to highly secure setups it's been a tedious nightmare.
I don't know exactly which "secure setups" you are talking about, but the false equivalency between security and complexity is mostly from security theater.
If you start with insecure systems and then do extra things to make them secure, then that additional complexity interacts with the thing you are trying to do.
That's how we got into the mess with SE Linux, and intercepting syscalls, and firewalls, and all these other additional things that add complexity in order to claw back as much security as possible.
It doesn't have to be that way and it's just an issue of knowing how.
If you start with security (meaning isolation) then passing resource capabilities in and out of the isolation boundary is no more complex than configuring the application to use the resources in the first place.
Look at how people have responded to Rust. On the one hand, the learning curve for memory safety (with lifetimes and the borrow checker) can feel exhausting when moving from something like Ruby. But once you internalize the rules, you're generally cooking without it getting in your way and experiencing the benefits naturally.
Writing secure systems feels similar. If you're trying to back port something, as you said, it can be a pain in the ass. That includes an engineer's default behavior when building something new.
Firewalls are a fundamentally bad approach and are avoidable with good design.
Nothing should have access to the network by default.
You can either get that right by limiting resource access (which is the job of the operating system) or you can get it wrong and have to expose new APIs and hooks to invite an ecosystem of many, slightly different, complicated tools to configure network access.
To give access to the network, you spawn the process with a handle to the port it can listen on, or a handle to a dynamically allocated port that it can only dial out of.
This is no more complicated than configuration, and it doesn't have to be difficult for users.
It can bubble up to a GUI very similar to what the iPhone has for giving access to location, contacts list, etc.
The fact that most "security" people have a knee-jerk reaction to "firewall bad" is exactly the cultural problem that I'm talking about.
It's not a technical problem anymore, the solutions are known, but they aren't widely known, and they aren't known by decision makers.
We've become so used to the wrong way for so long that highly trained people reliably have bad taste.
There's a reason why all security professionals I know use an iPhone.
To my knowledge there hasn't been a single case of an iOS application being able to read the data of another application - or OS files it wasn't explicitly given authorisation to do so.
It can be done, but for desktop it has never been a priority.
A bit like the earliest versions of Windows encountering The Internet for the first time. They were built with the assumption they'd be in a local network at best where clients could be trusted. Then The Internet happened and people plugged their computers directly into it.
it always rubs me the wrong way when people infantilize the masses. The "vulnerable" masses already already partake in lots of harmful substances and practices (tobacco, alcohol, drugs, gambling/lotto), AI videos are just another potential pitfall people will need to learn to be wary of.
I think "learning that absolutely nothing you see with your own eyes can be trusted as reality despite looking completely real" is a valid problem and that we are all somewhat vulnerable there.
I suppose this largely depends on the kind of software that you write. Ideally, you also extract only the part of the external code that you need, audit it, and integrate it into your own code. This way you minimize the attack surface. I don't work on software that is exposed to the Internet however, so admittedly the importance of security vulnerabilities is low.
reply