The article is about utility scale solar and storage I believe not home installations. It also mentions towards the end that in cold norther climates adding wind to the mix makes sense
There are TONS of incentives to increase energy efficiency.
Most local electric and gas companies will do free energy audits. Many will offer rebates if you install tankless water heaters, heat pumps, and insulation. Installers get kickbacks from manufacturers and tax credits if you buy higher efficiency equipment. Lenders will give you 0% loans to fund it all. The Feds and many States offer tax credits for all of the above.
I've done every single thing on this list in the last 5 years, some in Texas, some in Indiana.
A well built home with more insulation will, according to physics, lose less heat in any given scenario. So policies that push for things that improve buildings can reduce energy use.
Do you think we have reached peak building efficiency or something?
> It's like math was forced to run on assembly language despite there were more high-level languages available and more apt for the job.
I'm not a mathematician but that doesn't sound right to me. Most math I did in school is comprised concepts many many layers of abstraction away from its foundations. What did you mean by this?
My math classes were theorem, lemma, proof all day long, no conceptualization, no explanation; low-level formulas down to axioms. Sink or swim, figure it out on your own or fail.
I know I'm in the small minority of Discord users who mostly uses it as a voice chat room while gaming with my friends, but for that use case the best alternative I've found seems to be Mumble.
I recently set up a Mumble server on my home server and it seems great so far, was able to get my friends connected pretty easily. We'll see how the voice quality and latency compare to Discord.
Huh. I’d have said majority. It was always my impression that a) gamers make up the vast majority of discord users (with all their gamification and gaming features), and b) that gamers mainly care about voice chat (which is what people almost always talk about when it comes to discord and gaming).
That may be true but the sense I get from Gen Z folks who I've talked to is that for them Discord is almost more of a social network for interacting with a community. Their activity might be centered around gaming but they're using Discord to find people they don't already know to play with, talk about the game, etc. For those folks, Mumble will not be even close to an alternative to discord.
Myself, though, I basically only use it to talk to the same guys I've been gaming with since we met in middle school 20-some years ago, and for that Mumble seems perfect.
It's semantics, really. Run the server executable on any computer in your house. Done. If you don't leave your computer on 24/7, the Mumble server isn't up 24/7. Oh well. If you use it to talk to friends, you'll presumably have your computer on when you want to use it yourself anyway.
> If you use it to talk to friends, you'll presumably have your computer on when you want to use it yourself anyway.
I tried this in the past but it didn't work. Now if your friends want to play you need to start the server for them. What if you're not at home? You basically end up making your pc a 24/7 server. Or you need to coordinate so that someone else runs the server in those cases, but that ends up creating more confusion. And let's not start talking about port forwarding issues...
All these issues are solvable, but they add so much friction when all you want to do is play with some friends.
Mumble servers used to be just a few dollars a year (haven't looked in a long time). But even that is enough friction to prevent adoption. Plus it doesn't support any of the non-voice features.
What does the 'ad network and search engine' have to do with it? Wouldn't any organization who serves lots of traffic have the same cost cutting goals you mentioned?
Yes, to expand: Both search and ads mean serving immense amounts of traffic and users while earning tiny amounts of revenue per unit of each. The dominant mid-90s model of buying racks of Sun and NetApp gear, writing big checks to Oracle, etc, would have been too expensive for Google. Instead they made a big investment in Linux running on large quantities of commodity x86 PC hardware, and building software on top of that to get the most out of it. That means things like combining workloads with different profiles onto the same servers, and cgroups kind of falls out of that.
Other companies like Yahoo, Whatsapp, Netflix also followed interesting patterns of using strong understanding of how to be efficient on cheap hardware. Notably those three all were FreeBSD users at least in their early days.
It is the unfortunate reality that we tend to only remember the creator(s) of the first version (if anyone). Not just cgroups, but a lot of tech or protocols.
Anyways digging it up, looks like the primary author was at Facebook for a year before cgroupsv2, redhat for three years before that, and Google before that. So... I don't know haha you'd have to ask him.
As I commute on a motorcycle (often in the rain, causing lower visibility) this is terrifying to me and I hope regulators in my state don't let it happen here until Tesla can prove their "camera only" approach is safe.
> The attacker already had access to ... my Google Authenticator codes, because Google had cloud-synced my codes.
This was such an obvious mis-feature I can't believe they actually rolled it out. For those using Google Authenticator you can and should disable cloud sync of your TOTP codes.
I can understand it. Ordinary users were getting locked out of their accounts when losing their phones. Some of those stories hit HN.
Don't disable cloud sync unless you have a backup of all your TPTP secret keys. It's dangerous to advise people to disable cloud sync without mentioning backups. Being locked out of thousands of dollars in your crypto account is as damaging as losing that crypto to hackers.
In that case wouldn't you be better off just disabling 2FA? The problem with the cloud sync is that users like the one in the article think they have 2FA but in fact if their Google account is compromised all their accounts using Google Authenticator TOTP second factors are also compromised.
TOTP isn't that great, you should definitely use a hardware and/or pass key for important and financial services. That said your cloud synced Google Authenticator can be behind a Google account with strong 2FA (i.e. not SMS nor TOTP), then it's mostly fine.
The lesson here is really not to ever share codes you receive by SMS, and preferably disable phone as recovery and second factor.
> And then there’s the code that we rely on for bank transactions, package deliveries, medical results, satellite launches, airline flight paths, self-driving cars, mortgage payments, and nuclear power plants. This is durable code, and it’s going to stay that way.
I can tell you from first hand experience that, since long before LLMs were invented, critical software supporting these industries is held together with duct tape and baling wire (and Excel). "Durable" does not mean "good". In my experience production code is often ugly, poorly abstracted, full of special cases and hacks, but most importantly it works.
