1,248 karma · joined April 21, 2010
(let ((p (read-from-network))) (lambda () (eval p))
ie. basically, the server program is an interpreter that loads the actual program when it's booted.
From this, you can see that the whole discussion comes from cheating. The actual source code, is not only the source of the interpreter, but the source the administrator will load into the interpreter when he boots the server. This source should also be "contaminated" by the AGPL. One may also consider that already the GPL has the provision that you should provide all the files required to build the program (makefiles, configurations, etc). But this could also cover the sources of the interpreters or compilers and tools needed to build the software, if the sources of the software depends on some specific features from the tools. Ie. basically, any software that cannot be built from a simple command (but requires days of work to install "dependencies", "compilers" and "tools"), doesn't fulfill the GPL (or the AGPL)! Software should be packaged with their gcc version (with C now evolving at such a fast pace!) And don't give us the sources of gcc for the sources of your software, don't cheat!
And the first question is whether such moral considerations should be included into what is essentially tools or mechanisms, ie. we're not talking about GAI here.
So basically, Tesla's autopilot works by "dumb" machine learning where the artificial neural networks are built to recognize images from the cameras, and determine driving commands from them. This learning is based on a big quantity if examples, recorded from existing Tesla cars, driven manually or automatically.
The important point is the big number of examples needed to learn a classification of the situation and derive a driving command.
Already, self driving cars have less accidents than human drivers.
So let me ask: WHEN will we have a big enough number of morally questionable situation examples, before we can teach to those artificial neural network what choice to make (and clearly, this will be human programmers who will make the choice, by labeling the situations and indicating what choice must be made)?
This will never occur.
All those examples are theoretical. The rare cases where a human driver can find himself in such a situation where he can turn left to kill a kid or turn right to kill a old man, are situations in which a self-driving car would never find itself in, because it would have reacted differently before the situation occurs.
In practice, since there will be no learning, there will be a random bias, a determination that will be done considering other criteria, and over a thousand of years of self driving, when such a case where a moral choice could have been done, the choice will just happen to be random, and can very well be actually the right choice. But it should not matter.
The problem with the watermelons (green outside, red inside), is that they're a runaway psyops from the cold war time KGB. It's basically a headless chicken that keeps running in the courtyard.
More interesting would be the reason why nuclear power has not been more developed BEFORE renewables could be considered. And the reason is:
1- civil nuclear power has been developed using uranium instead of thorium since this produces plutonium as by-product, which is useful to build nuclear weapon.
2- we want to prevent nuclear weapon proliferation, therefore we have to prevent proliferation of uranium-based civil nuclear power.
The solution is to start to develop thorium-based civil nuclear power. This doesn't lead to military-use or ecologically problematic by-products, so it can be used everywhere on the planet.
All this, with virtually zero system administration overhead, and nice non-programming tools for the occasional need.
So to the professional software developper might prefer to use it.
I use emacs on mac, and x11 with xterms open to various linux boxes; basically the same as when on linux. But with nicer fonts, nicer mail UA, much less administration. Granted, linux is still better by a few percent on the development tasks, but macOS compensates on the other tasks, and by its versatility. Anyways, we keep linux boxes and VMs.
2- there's no point in considering commits as programs if it's not easy to modify them. It is not easy with git. Nobody can remember the commands (we have to google for each git action beyond git checkout git commit git push), and the procedures are overly complex. Notably compared to writing programs, if you want to consider a git commit history as programs.
So happy new year!
But they never existed in the first place!
The programmer population doubles every 5 years (approximately).
So even discounting the age pyramid (dead people, or career changes), there are only 0.20% of 60-64 year-olds, vs. 50% of 20-24 year-olds.
0.20% 60…64-yo, 0.39% 55…59-yo, 0.78% 50…54-yo, 1.56% 45…49-yo, 3.12% 40…44-yo, 6.25% 35…39-yo, 12.50% 30…34-yo, 25.00% 25…29-yo, 50.00% 20…24-yo.
That adds up to 6.05% of 40-64-yo vs. 93.75% of 20-39-yo. There never was enough programmers to make old programmers.
Of course, we cannot stay on this exponential growth long, so the question will have to be revised in 20 years; then we'll see what happens of all those young Amazonians :-)