Readit NewsThat all-consonant keyword always makes it seem like I'm reading Hungarian notation when reading Rust for instance. An other options I've seen for instance in Pony, "fun", is already an English word with a completely different meaning.
Even the "function" from Javascript seems fine to me.
[1] https://www.velopen.com/blog/adding-type-safety-to-object-id...
Even if you, as the company selling the software, can accept all of the above, a license server still is a liability. You sold someone a product and now you need to keep a public API running "forever" (as defined in your legalese). If something goes wrong on your end you are now denying the product you already sold to your customers who already paid for it. I know this is in the end all mitigated by some legalese, which is a whole different can of worms. You also need to make sure your license API is secure and can not leak user data or be twisted into exploiting your software during license checking. There is an ongoing cost to keep the infrastructure running.
As a sibling comment pointed out you can use local only license management like license keys or just nothing like WinRAR or FUTO Keyboard[1]. Yes, you will get users not paying for your software, there will be keygens out there. But even if you use a remote license check, there will be cracks on day 1, if your software is popular enough. I know this is an old and flawed argument, but if someone is willing to navigate a website full of malware infested, blinking ads to avoid paying for your software, they probably would not pay for it anyway.
As an example of what the end stage of hooking up every software to a remote API looks like, Stop Killing Games [2] has done a great job of highlighting just how bad it has gotten in the gaming market. I know there have been some heated discussions around the movement, but the core idea of being able to keep using the software you paid for, is something I absolutely support.
[1] https://keyboard.futo.org/
[2] https://www.stopkillinggames.com/ https://hn.algolia.com/?dateRange=pastYear&query=stop%20kill...
It’s almost comical how weak the security/privacy argument for MV3 is. Chrome could have developed a sandboxed web request inspection framework to prevent data exfiltration, but they didn’t even try. Instead they nerfed ad blockers without adding any security.
I've used ultrasonic humidifiers in the past and clean them well enough to avoid humidifier lung, but stopped when I noticed the air quality sensor on my air filter would go nuts when using the humidifier with anything other than distilled water. Which makes sense in hindsight, since any ultrasonic humidifier is essentially blasting everything in the water all over your house. Any contamination in the humidifier or the water is going straight into your lungs.
Steam and evaporative humidifiers have their own downsides, but their respective processes of producing water vapor seem to carry less non-water things with it. Which again makes sense given the physical processes involved.
Dave and toDesktop have build a product that serves many people really well, but I'd encourage everyone building desktop software (no matter how, with or without toDesktop!) to really understand everything involved in compiling, signing, and releasing your builds. In my projects, I often make an argument against too much abstraction and long dependency chain in those processes.
If you're an Electron developer (like the apps mentioned), I recommend:
* Build with Electron Forge, which is maintained by Electron and uses @electron/windows-sign and @electron/osx-sign directly. No magic.
* For Windows signing, use Azure Trusted Signing, which signs just-in-time. That's relatively new and offers some additional recovery mechanisms in the worst case.
* You probably want to rotate your certificates if you ever gave anyone else access.
* Lastly, you should probably be the only one with the keys to your update server.
There's plenty of magic. I think that Electron Forge does too many things, like trying to be the bundler. Is it possible to set up a custom build system / bundling with it or are you forced to use Vite? I guess that even if you can, you pull all those dependencies when you install it and naturally you can't opt out from that. Those dev dependencies involved in the build process are higher impact than some production dependencies that run in a sandboxed tab process (because a tiny malicious dependency could insert any code into the app's fully privileged process). I have not shipped my app yet, but I am betting on ESBuild (because it's just one Go binary) and Electron Builder (electron.build)