I say do it, if it simplifies the architecture. For example if you are using firestore with a redis cache layer, that's 2 dbs. If you can replace 2 dbs with 1 db (postgres), I think it's worth it. But if you are suggesting using a postgres cache layer in front of firestore instead of redis... to me that's not as clear cut.
As someone who works on medical device software, I see this as a huge plus (maybe a con for FOSS specifically, but a net win overall).
I'm a big proponent of the go-ism "A little copying is better than a little dependency". Maybe we need a new proverb "A little generated code is better than a little dependency". Fewer dependencies = smaller cyberseucity burden, smaller regulatory burden, and more.
Now, obviously foregoing libsodium or something for generated code is a bad idea, but probably 90%+ of npm packages could probably go.
I feel npm gets held to an unreasonable standard. The fact is tons of beginners across the world publish packages to it. Some projects publish lots of packages to it that only make sense for those projects but are public anyway then you have the bulwark pa lager that most orgs use.
It is unfair to me that it’s always held as the “problematic registry”. When you have a single registry for the most popular language and arguably most used language in the world you’re gonna see massive volume of all kinds of packages, it doesn’t mean 90% of npm is useless
FWIW I find most pypi packages worthless and fairly low quality but no ones seems to want to bring that up all the time
I think you are completely oblivious to the problems plaguing the NPM ecosystem. When you start a typical frontend project using modern technology, you will introduce hundreds, if not thousands of small packages. These packages get new security holes daily, are often maintained by single people, are subject to being removed, to the supply chain attacks, download random crap from github, etc. Each of them should ideally be approved and monitored for changes, uploaded to the company repo to avoid build problem when it gets taken down, etc.
Compare this to Java ecosystem where a typical project will get an order of magnitude fewer packages, from vendors you can mostly trust.
If these packages get security holes daily, they probably cannot "just go" as the parent comment suggested (except in the case of a hostile takeover). If they have significant holes, then they must be significant code. Trivial code can just go, but doesn't have any significant quality issues either.
I'm not, in the least. I'm aware of the supply chain issues and CVEs etc.
One thing I want to separate here is number of packages is not a quality metric. For instance, a core vue project on the surface may have many different sub dependencies, however those are dependencies are sub packages of the main packages
I realize projects can go overboard with dependencies but its not in and of itself an issue. Like anything, its all about trade offs and setting good practices.
Its not like Java as an ecosystem has been immune either. The `Log4Shell` vulnerability was a huge mess.
My point isn't to bash the Java ecosystem, but nothing is immune to these issues and frequency is a fallacy reason to spread FUD around an ecosystem because it lacks context.
It's a matter of community culture. In the Node.js ecosystem, all those tiny packages are actually getting widely used, to the extent that it's hard to draw a line between them and well-established packages (esp. when the latter start taking them as dependencies!). Python has been npm'ified for a while now but people are still generally more suspicious of packages like that.
I am utterly confused at how you think rewriting entire libraries have less security holes than battle-hardened libraries that 1000s of other people use.
- Generating your own left pad means you don't have to pull in an external left pad
- Which in turn means left pad doesn't show up on your SBOM
- Which in turn means CVEs won't show up for left pad when you run your SBOM through through SCA
- Which means you don't have to do any CVE triage, risk analysis, and mitigation (patching) for left pad
- It also means you don't have to do SOUP testing for left pad
Now imagine you've done that for a dozen libraries that you are only using a small piece of. That's a ton of regulatory and cybersecurity work you've saved yourself. I never claimed generating code makes your software more secure, I claimed it can reduce the regulatory and cybersecurity burden on your SDLC, which it does as demonstrated above. Taken to the extreme (0 external dependencies), your regulatory burden for SOUP and SCA goes to zero.
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.
This definition doesn't make any sense. Virtually anything not a solid or gas is a lubricant under atmospheric conditions. Water is one of the best lubricants you can find.
"lubricant mixed with a solvent" - doesn't make sense. A solvent is a lubricant. Acetone for example, is a phenomenal lubricant. I'm not sure how you're going to stop it from evaporating, but it's a lubricant. Water is a solvent as well, for example.
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