> sit white-knuckled until I die in a food riot.
This is nonsense, food production on a per-capita basis is increasing and population is leveling off.
1,597 karma · joined April 30, 2018
This is nonsense, food production on a per-capita basis is increasing and population is leveling off.
This does not seem likely, the bar for a region being "unable to support humans" is very high. People already live in cities that need to support themselves with food from elsewhere, and worldwide calorie production per capita is increasing.
The fact that their detection of driver attention is worse is only one factor, the cars should be evaluated on overall accident rates relative to human drivers or other self-driving systems.
Human-driver cars consume parking spaces at the destination, self-driving cars don't have this limitation. They park themselves away from high-traffic areas or they could ferry other people around.
There are fields where physical limits were already reached, for example rocket engines specific impulse has barely improved since the 60s because of fundamental chemistry, but this is not the case for tunnels.
Provided enough funding it should be possible to dig faster, and cheaper per km.
Self-driving cars would enable self-driving taxis which would be superior to both private vehicles and public transport.
Imagine if there was no need to park and you could summon a vehicle of the appropriate size at will.
Flying cars and jet packs are limited by physics (specifically energy density) and progress in this area is almost non-existent. We barely got batteries to be vaguely competitive with internal combustion.
Self-driving cars are limited by software and hardware accelerators and this field is making real progress.
Cars are extremely useful and are not going anywhere. They have problems like carbon emissions and being extremely dangerous but those will have to be solved while preserving the fundamental utility of a cars: They are individual vehicles that can go nearly anywhere and carry considerable cargo.
Maybe if TCL had a single standard OO library in the late 90s it would have been more successful? But I still think that languages with native OO constructs are much better that a shell-like string-oriented interpreter.
It might also help to export the local TERM value remotely because it's not otherwise passed through a serial port.
The shell-like "everything is a string" is seductive at first but in practice you spend way too much time messing up your quoting. It's similar to how sometimes people suggest dropping yaml/json for a "simple ini file": it quickly breaks down and you end up with a custom ill-defined mechanism for nesting values.
TCL can handle more than just string variables: you have arrays, dicts and a bazillion libraries implementing object orientation. The result is that manipulating structured data is still more awkward than in any other modern language, except perhaps shell scripting.
Unless you're interfacing with a legacy or third-party system please don't use it. If you think you need expect please just use pexpect.
That assumes you're running a new separate PHP processes for each request and an application built this way is unlikely to scale terribly well.
Are there even any notable commercial projects that use autotools?
Autoconf solves problems that existed in the 90s unix market which are just not very interesting or relevant today. For a few decades now "portable" has meant linux, windows and mac.
A lot of effort is spent on generating shell scripts for the lowest common denominator and this is both useless (nobody cares about 90s unix, everybody can install bash) and insufficient (bourne shell is not native on windows).
Perhaps energy would be better spend on migrating everybody towards newer build systems or just plain makefiles. A lot of projects have migrated already, does anyone have statistics about what percentage of a distro like Debian needs autotools?
Yes, GM deserves much more credit for the EV revolution than Tesla.
France uses nuclear power, what makes you think that this is somehow difficult to scale? Electrical energy is very fungible.
Shifting production to developing countries is mostly due to labor costs.
> Counter to this is the persistent myth that we can just increase capacity to meet demand.
This is not a myth, increasing capacity causes issues but those issues are solvable.
Is this something that yocto itself helps with or just something accomplished by a thousand people hacking at .bb scripts? Last I checked features like the sstate cache came with big caveats.
Dockerfile layer caching seems much more effective at shrinking build times.
The boundary between a binary tarball and the rest of the system is very poorly defined.
If you make everything a string then the interpretation of "no" as boolean true or false is left to each tool, and there are even tools which have different interpretations of "yes/no" for each field.