virgo_eye

It is true that the design of ICE vehicles is not arbitrary, but depends on weight/power/size/speed tradeoffs. However, there's no reason that these tradeoffs should be the same for EVs.

Drivers in city traffic can't go fast, but they like to accelerate quickly. This means a big engine, which means a big car, which means more weight so the engine has to be even bigger to keep the car accelerating 0-30 quickly.

For EVs, the relationship between battery weight and acceleration isn't the same. A new tradeoff is now between batteries which store power for a lot of driving, versus batteries which release a lot of power quickly, to accelerate sharply. There's no reason there shouldn't be a new sweet spot of very light weird-looking cars which are only driven around cities, need to be charged a lot (but who cares if not making long journeys) but have good 'driving performance'.

Network load here refers to bandwidth on the internet, not power consumption on the electricity grid, I believe.

No, essentially 100% of energy used for computation will turn into 'waste' heat.

If you calculate 1000 digits of pi, those digits will not embody any energy.

If the solution is to store config in a format with comments and strip them off before handing to JSON, what should that format be? Shouldn't it be formalized? Couldn't JWCC be that format?

You can't pay your utility bill with Apple stock, or buy groceries with crude oil ETFs. You have to convert them into money first. Does this mean that they are not a store of value?

Do you think that people doing research at large technical organizations structure their code in the same way as academics? No, although there's always a portion which is active and unstable, they create packages, define interfaces, abstract out pieces which can be reused reliably and depended on. Similarly for other types of researchers in fields where the code is considered an important product. Eg. if you are doing research in compiler design, you're likely to want to create a compiler which can be used by other people. So you make a stable thing with tests, automated builds and so on. And you delimit and instrument the experimental parts.

The real reason is the incentives. Not just are there no incentives to produce good quality code, there are incentives which make people focus on other outputs. Publish or perish means that people put up with technical debt just to get to the next result for the next paper, then do it again and again.

It's clear that your approach is a possible approach:

1. 'only use good libraries' 2. 'it's not your job as a developer to make sure your application can be installed' 3. 'if your users want to use pip... they should be able to fix those issues'

However, this isn't a solution to the problem that led to the existence of language ecosystems. It is a refusal to acknowledge the problem.

I mean the whole argument here is that distro packaging is not needed, that there's a better way of doing it.

Why are you comparing distro package managers to the Play store or the Chrome extension store? You should be comparing them to npm, pypi, etc. That's clearly the context of this discussion. No one is saying that the Chrome extension store does a better job than package managers. The language ecosystems do an amazingly better job.

The distro model did not work, which is why the other model took over.

I used to try to religiously follow the recommendation only to install Python packages which had been repackaged by Debian. Fine, but it meant that you couldn't use any even slightly obscure package, nor one that was younger than some timelag, which ranged from a few months to a couple of years.

Inevitably, you want to pip install something. Then the repercussions of mixing Debian packages and pip packages are a whole new set of problems. And you can't get anyone to look at your problem, even if it's a common issue which the Debian packager could fix or workaround, because 'pip is not supported, you should install this via `apt install python-foo`'.

The best solution is and was to only use pip packages, along with some form of isolation from the wider system, whether virtual environments, containers or what. Python now has extremely good native tools to work this way, and so do most modern languages. I only work like this now, and so, it appears, do all the maintainers of my dependencies and my transitive dependencies. Development cycles are much faster, and it all just works.