This is not true. Solar and wind are already cheaper than fossil fuel generation for new capacity. Source: https://www.scientificamerican.com/article/wind-and-solar-en...

This was the case a year ago, but they have really stepped up their game, at least in the Northeast. I now find the EA chargers to be (almost) always functional.

Today's voice assistants are the opposite. They are unreliable and completely unstable. They don't have a clear list of commands they understand, let alone some sort of menu system - the documented commands on the manufacturer's websites often don't work. They also randomly change what they can do: stuff stops working for no obviously reason.

For example - yesterday, my son's Nest Audio suddenly refused to set a music alarm, claiming "this device doesn't support that feature yet" (it's literally a speaker for music...). It worked the day before.

The F150's towing capacity appears to be 5,000 to 14,000 pounds (random source: https://veteransfordtampa.com/ford-f-150-towing-capacity). You could tow a 1,300 pounds trailer with a regular car, e.g. the 2023 Ioniq 5 has 2,300 pounds of towing capacity.

In Python land one of those seems to come along every couple of years. They start over and implement a solution for some subset of the problem space. Then they realize the Python packaging mess is much, much bigger than anticipated and progress stalls. At that point there are 15 partial "standard" packaging solutions for Python, where there were 14 before. None of them are feature complete, and they don't really coexist well or at all.

Cue the obligatory https://xkcd.com/927/ and https://xkcd.com/1987/

On the minus side, the article seems to try to make some weird, more general point that is just scaremongering: "omg the sky is falling, sometimes components with hidden defects cause failure on a large scale years later".

The author also suggests this has never happened before, which is of course false. I guess they never heard of the "capacitor plague" cf. https://en.wikipedia.org/wiki/Capacitor_plague, which was a lot more serious.

Didn't that defeat the purpose of the critical thinking course?

Perhaps. But 10-20 years ago, solar/wind/storage was a lot more expensive and a lot less efficient. The situation is quite different now.

> Who should we blame in 10-20 from now if people still are burning coal, oil and gas? Who will take responsibility for the inaction?

Realistically, there will probably still be knuckleheads who will be burning coal, oil and gas in 10-20 years from now. But hopefully they will be a very small minority.

The main thing that gives me hope is that it is now so much cheaper to build/run renewables than fossil fuel plants, that the latter will be phased out sooner rather than later, just for economic reasons. Those 6 out of touch old people on the supreme court are trying to delay things - and their actions will have very bad consequences for all of us - but the trend is clear.

But... we all know that it takes a lot longer to build a nuclear plant (on the order of 10-20 years) than it does to build (large) solar or wind farms (on the order of 1-5 years).

So.... yeah, if it was magically possible to replace all coal with nuclear right now, that would be a net improvement in terms of carbon output and general pollution.

But we live in the real world, and that is not possible, so I'm not sure what point you are trying to make, to be honest.

I'm pretty sure that enough solar/wind + storage can be built to replace a significant percentage (30%? 50%?) of the remaining coal plants, before the first new nuclear plant's plans and siting are even finalized, let alone before a new nuclear plant is fully operational.

And it's going to be a lot cheaper, too.

My experience with these has been decidedly mixed. As in, you define them and never, ever see an alert.

Probably not, but instead they get to bill their working hours in 6 minute increments. And they have to bill a high number of hours a day. Praise yourself lucky if you don't have to do that!

Yeah. And based on the idiotic bills coming out of the NC state government (bathroom bills, now this anti-EV nonsense), these organizations need to step up their lobbying.

I think you're underestimating what it would take to solve the problem (even one as "simple" as this one). But, let's assume there is an off the shelf open source solution that is perfect for your environment and requires no changes and integrates easily in your corporate processes without any work (this is already very unrealistic...).

Then, you need to run it and provide 24/7 uptime for your 10k users, which are presumably spread across multiple timezones. Your 0.5 FTE is going to be on call 24/7? Good luck filling that position.

Finally, how are you going to support the 10k users? Is that 0.5 FTE going to answer all the support requests?

I'm not saying it's bad to do things in house - and there are really good reasons to do so. You just have to be realistic. It's going to take a whole lot more than 0.5 FTE to run even a "simple" service like this with the kind of reliability and support your 10k users will demand.

Suddenly that $80k/mo to make it someone else's problem doesn't sound so bad :)

It all depends on context though - for a company as massive as Tesla, 20+ open postings for SWE is nothing. It certainly doesn't warrant alarm bells, I think.

Join Curii (https://www.curii.com) as DevOps Engineer! We are the small but mighty team that builds Arvados (https://arvados.org/), an open source platform for large scale computation and data management. Most of our customers and users are in life sciences, in the genomics space.

We're looking for a DevOps engineer with strong analytical skills to join the Arvados engineering team.

We're a friendly and well functioning team that loves free and open source software and open science. Our team is in 4 countries and we operate mostly in the Eastern timezone (Americas). We are remote first.

Feel free to contact me with questions (e-mail address in profile), and by all means apply at https://www.linkedin.com/jobs/view/devops-engineer-at-curii-...