If you don't have enough control over your applications to have them connect over trusted networks and not untrusted ones, you probably don't have enough control to stop them leaking more information than you would want to the endpoints they connect to.
That's not meant to be snarky; it's a real problem. I have an android phone but I am very conscious that it's doing a lot of things I don't control and I can't really trust it.
A VPN can be part of a carefully implemented security policy, or it can be a thing that might help a little on a generally insecure base, but it can't turn an insecure machine into a secure one.
It's actually interesting why this idea is so totally wrong.
So Telecom Malaysia messed up a config, and Global Crossing accepted their updates automatically.
Global Crossing didn't have to accept the bad update. They generally trust updates from other organisations that are generally trustworthy. They apply checks and restrictions proportionate to the risks involved.
These mistakes happen rarely. If they were to happen more often, major operators would apply more checks and restrictions. If they were to stop happening, operators would apply less checks and restrictions, because they have a cost in manpower, complexity, and loss of flexibility.
That's how the internet works. You could almost say that's what the internet is--the idea of being actively managed by people who know what they're doing and are not bound by exhaustive predefined policies is defining of how the internet came about and how it came to be dominant.
If you want a network guaranteed to be resistant to this kind of f---up, build one. The internet is that network which does not work that way, which is flexible, expandable, mostly "good enough" but not ever designed for absolute reliability.
The regulations protecting investors are far stronger than those protecting consumers. Crowdfunding could not exist if the customers were legally considered investors.
the goal should be to be able to process the vast majority of transactions
That implies the social value of the transactions outweighs the cost of carrying them on the blockchain. If the bulk of transactions are penny-valued "scratch card" gambles (are they still a thing?), that is obviously not true.
Does the author have any evidence for his claim "The limit was temporary"? It was certainly commonly claimed even a couple of years ago that the coming scarcity of blockchain space would lead to an increase in fees.
I would assume the author is talking about in-house software development. If you are delivering software to a client, you don't want them to have to recompile sources to make changes. If the developers of the software are also responsible for its runtime configuration (which is very common in banking, telecoms, etc.) then changing code can be as easy or easier than changing config.
I agree with this too. Pulling constants out to the top a source file is often a mistake. It's useful if someone is looking at the source file to find the constant, but usually it's more likely that they're reading the code to understand it, and then need to know the value of the constant. In these cases it can be better to have a constant but define it close to where it is used.
YES! No system is harder to maintain than one that consists of a huge mesh of configuration files.
No kidding, I have worked on a large company-wide reporting system where the easiest changes to make were to the code. Code changes could be made, tested and released in a fairly straightforward way.
The harder things to change were to configuration files (Spring, things like that). Because they had global effect, and contained elements that were specific to a dev/test/production environment, making and deploying changes to one were more difficult.
But the very hardest things to make changes in were the report and process parameters stored in the database. They were impossible to isolate the effects of since we had no easy way to trace to what functions they might affect, and were generally treated as immutable legacy that you worked around changing rather than touch.
(I wouldn't claim this was a good system)
When you put something in a configuration file, you need to define who is going to change it, and how they are going to test their change. Otherwise you're in danger of muddling together different levels of abstraction, and breaking encapsulation all over the place.
I use a hand-rolled gpg + git + owncloud for myself, but that's not convenient if you don't routinely have terminal windows open.