- There seem to be a few camera manufacturers listed under "Supporters" on the introduction page, namely Goodcam and RunCam.
- Pretty much every EV does regenerative baking, because it (greatly) extends range. Even hybrids have done this since the very earliest mass-market models (the 1997 Prius has it). EV brakes see a lot less wear and tear than ICE brakes.
- Not for everyone: https://www.instagram.com/_dskdrv_/
- > And EA is basically always broken.
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.
- VIM is well designed and stable, so you can learn the interface and be confident that it will work for you next time you use it. It's an amazing tool.
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.
- There is a school of thought that developers should have hardware that is a generation behind the cutting edge, to make sure that their output will perform really well in the real world, on the latest hardware...
- I'm confused - are you missing a zero?
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.
- > A “burn all the packaging down and start over” path?
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/
- Compared to the dumpster fire aka Python packaging, Go versioning is easy and predictable indeed.
- On the plus side, the article provides an explanation for why this is happening, with some detail.
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.
- > ... found that the entire book was annotated with all of his answers, anecdotes, and various other helpful notes.
Didn't that defeat the purpose of the critical thinking course?
- > People who made those exact arguments 10-20 years ago where wrong, since those plants would have prevented a lot of coal, oil and gas from being burned. Those people have both blood and an ongoing climate crisis on their hands.
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.
- > Every year coal is still here, instead of nuclear, is 100 years of death. If > building powerplants (of any type) were instant, and solar were one year away, > then we should STILL replace all coal with nuclear TODAY, to minimize harm. (in > a spherical chickens in a vacuum sort of way)
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.
- > although we have setup some aws billing alerts just in case.
My experience with these has been decidedly mixed. As in, you define them and never, ever see an alert.
- > do you think lawyers work on Jira tickets?
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!
- > There are many large employers here like Apple, Google, Cisco, Microsoft, Github, Redhat, SAAS, Epic Games, etc.
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.
- > This kind of logic I would expect only from a bean-counter, and a bad one to be honest... Why would anyone pay $80k/month to solve a problem that could be solved with 0.5 FTE?
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 :)
- > When I see that many open postings at once, alarm bells go off.
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.
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...