You can blame the ever-increasing complexity of MS Windows for that. My parents are now on Linux, being that the only things they do on it, other than open the occasional email attachment, are all browser-based. It's easier for me to occasionally run an apt-get upgrade remotely than it is to try to keep Windows free of infestations.
Add me to the list that recommends Energysage for a basic rooftop solar resource.
You didn't mention your state. The regulatory environment differs significantly between states, and determines what the electric company can do, since they're generally state-regulated public utilities. If you can sell excess electricity back to your utility at retail rates, it makes little sense IMO to buy a battery. However, if the utility will only pay wholesale rates for your excess, a battery can be cost effective, depending on your daily production/use cycle.
Also look up "solar value deflation" and understand that, as more people install solar, the value of it will decrease as net metering regulations and connection vs. distribution costs get shifted. Read up on the difficulties people with solar leases have encountered when trying to sell their home. For that reason alone, I'd recommend buying, even if it means a second mortgage or HLOC to pay for it.
I'm personally holding out for more efficient panels, cheaper batteries, and home-scale bio-fuel production for excess energy so I can size my install to support being truly off-grid throughout all four seasons.
Great points, I will definitely look at the solar value deflation data, thanks. Your conclusion may be mine as well, I just want to understand the tech and market well enough to be able to make a good decision when it is time to jump in.
I'm pretty sure this is more feature rich than dnsmasq, but the golang ipkg on the latest OpenWRT release is 99MB. My overlay filesystem started at less than 24MB.
This software not for users like us.
Perhaps someone will implement equivalent functionality using C or Python libraries for those of us that run by choice in a resource-constrained or embedded environment.
That's going to be the golang compiler - you can cross compile static binaries from your PC that will run on ARM. The final binary size should be a few mb.
If having a PhD in computer science (programming languages), being reasonably smart, and using the language for 20 years (up to and including most C++14 stuff) doesn't make you an expert in that language, then your language is far too difficult.
In fact, C++ is far too difficult and there are very few genuine experts in it. For example, who can explain why using push_back on a vector<map<T,unique_ptr>> is not conformant to the Standard, without looking it up? (I'll save you some time: https://bugs.chromium.org/p/chromium/issues/detail?id=683729...)
There's also a definitional bait-and-switch going on here. C++ proponents use "C++" to mean "the language that lots of projects have been using for 20 years and lots of programmers know" when espousing its popularity. But when necessary, the meaning changes to some "'modern', 'safe' subset of C++" ... that few programmers know well and few projects stick to rigorously. The exact definition of that subset changes depending on the situation, too.
Hi. In the linked "confessions" blog you've taken the path of making some claims about a topic and supported them through who you are, instead of facts.
People who disagree with your claims will question if who you are is relevant.
C++ is difficult, and there are few experts. My thesis is that one doesn't need to be an expert to write safe C++ code, but they do need access to quality libraries focused on safety, and good practices focused on safety.
Banning some unsafe C functions, saying "use smart pointers" or making a list of UB is useful, but not enough.
C++ can be written much more safely than it normally is, but it seems that's not happening. I'm not sure why, it could be that the performance loss of additional runtime verification is not acceptable, that the adequate learning resources are not available or that it's not an important topic for the C++ community.
P.S: I'll gladly have the kind of error you linked to. It's at compile time, I will try to figure it out and worst case rewrite my code. UB is the problem.
The first link has no relevance to the discussion, and the second I had indeed read before posting. Need I point out that C++ IS NOT C. Being a good C++ programmer does not make you a good C programmer, and vis versa. I would argue, in fact, that many of the capabilities that a knowledgable, current C++ coder depends on would make them more liable to encounter issues coding in C, std::auto_ptr being chief among them.
Someone who has something which is indeed better and knows it will believe everything should be rewritten thus; someone who has something which is middling or worse but believes it to be better will think the same thing.
The interesting question is not whether or not the author is a Rust proponent; it's whether or not Rust is an improvement on C. As neither a C nor a Rust programmer, it appears to me that the answer is unequivocally 'yes' — and this despite the fact that Rust is roughly as intelligible as Mandarin to me.
How often have we seen politicians champion an issue only to find out that it's over-compensation for the presence of that issue in their personal life... cough Foley cough
