I just really appreciate separating things like access credentials from things like web browsers without running multiple accounts. I do all my most and least secure activities on Qubes and use other computers for a lot of the other stuff in between.
Yeah, I could not do it without other computers to use, but after a year of keeping a system running it, I find myself mostly using my other systems for specific purposes like a windows machine for gaming (no web browsing ever lol), my macbook air for printing, managing photos, doing stuff with my iOS devices, etc.
Windows templates work great for me! I think a big part of the reason I didn't pick it up for daily use before was assuming windows support was not that great. It's definitely specialized, but pretty well supported IMO.
1. I have completely offline templates that I use like vaults, mostly to run rufus and create USB sticks.
2. I have templates to test and build software for work where I baked SSH and VPN keys into the template, but the system drive (including my user account data and settings) get reverted every reboot and the only persistent data, like version tracked project code, is on the extra D: drive.
3. I have FlareVM template setup to do dynamic analysis in disposable qubes without any network connection. They have the integrated file and clipboard transfer to get samples in and keep notes externally.
The only real issue I have noticed is resizing the screen repeatedly seems to crash the GUI driver somehow. The window disappears and I have to kill the Qube. Usually I just resize once when starting, if at all, so it's not a big deal.
There is a huge difference between no value and default value. I had plenty cases where I needed to distinguish them because absent value is a violation of a contract. Defaults are not a solution.
And more. Defaults bring their own problem. Chosen values are neutral only for some operations. The most simplest case - int default value is 0, but it kinda "works" only for sums. With nulls you'll get an error in production. With defaults discovery of the error is postponed even more. It's literally the same as making up values ignoring clients will (and this decision even not ours but designers of the lang).
Defaults are implicit. It's simplifies mistakes due to human factor.
I think the author did a good job of challenging my assumptions going in at least, which is nice.
My initial reaction was that it was a list of fairly complex things, but they are not necessarily complex to implement, even if people commonly over-complicate a couple of those things or make them a pain for other developers to setup, which seems to be part of the point.
Remember that writing bespoke internal software and general-purpose commercial software are very different things with very different budgets, and you will need support staff. Do your research and talk with someone who understands commercial software before planning any kind of spin off. These are two very different goals, even if one would hypothetically fulfil the other.
> Firstly, because some people on the internet like to get angry over opinions that may not match their own, I want to make clear what this blog post is not:
> It is not a call for everyone to immediately drop React and move to web components.
> It is not a blog post declaring React “dead”, or the wrong choice for every project.
> It is not a blog post declaring web components the best solution to all projects.
You might want to consider how well the phrase, "Haters gonna hate," applies to your comment.
I’ve found that while I did spend a lot of time at first figuring out how to write testable code, I now am so much better at writing in this way that I am much more productive since everything has great test coverage. Saves me going back to modules I wrote 2 years ago to add features.
