Hacker Newsnew | past | comments | ask | show | jobs | submit | cure's commentslogin

> If solar was viable, it would not require forcing tax payers to fund these businesses.

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...


So then removing the subsidies shouldn't be an issue?


It's not just subsidies, it's also permitting and any other roadblocks they can manage. This isn't just economic or political, it's a weird personal crusade.


If it was only the subsidies, but it's not.

https://www.reuters.com/legal/litigation/us-orders-orsted-ha...


It shouldn’t. Trump is using environmental regulation to block projects. It’s crazy seeing the GOP embrace San Francisco’s last decade of policy.


"'I never thought leopards would eat MY face,' sobs woman who voted for the Leopards Eating People's Faces Party."


There seem to be a few camera manufacturers listed under "Supporters" on the introduction page, namely Goodcam and RunCam.


It'd be really nice if any of the $15 cams on Amazon were supported.


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.



> 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.


So the problem is with lack of documentation and unstable UI, not with the lack of discoverablility per se.

Identifying the problem is often the first step in fixing it.


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...


Can't do it in the modern day with any front-end "technology" -- I remember finding after converting a FE build to Docker that it would die every time with a strange error. Turns out the Docker VM couldn't (maybe still can't?) make use of virtual memory on the dev machine, and there weren't 10GB of real RAM to spare. Let that sink in for a moment how building a frontend web app takes 10GB of RAM. (No this wasn't my code, or choice of dependencies). I hate the js ecosystem.


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.


1300 lbs tongue weight.

Which is a big fucking trailer at 10% tongue weight.


No, he's not towing 1,300 pounds, he's towing something that reduces carried cargo capacity by 1,300 pounds. (The impact is, IIRC, typically a bit over 10% of loaded trailer weight.)


> 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.


Until you hit the obscure rules around v2+ go modules.


I have been coding in Go for years, even professionally sometimes, and I have never had to use "v2" in any of my code. granted my stuff is not popular, but its really just a way for popular repos to handle big changes. Once I got past v1.9.9, I just changed to v1.10.0.


SemVer dictates a new major version on every breaking change, but it seems this concept is alien to many go developers and they just release breaking changes in patch releases, at the detriment of the ecosystem.


my biggest project has 13 stars, so I think I can do what I want with it.


Fair


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: