And I have a friend who services GSM control towers. He drives far beyond Tesla limits every day and I don't think his employer would be happy for him taking recharge breaks during billable time - or him being happy about these breaks being unpaid.
You are not everyone. Yes, many cars used by casual drivers will be replaced by electric. But all? All VEHICLES? Any projects for electric cargo ships out there please? Drop that kool-aid.
...or a blue-collar worker driving heavy machinery. For most of that stuff electric power simply doesn't have nearly enough energy density. And a lot of work is done far from the cities - come on, tell me how is the excavator supposed to dig 500 miles of a trench for a new fibre across the Rocky Mountains, with nearest recharging stations 30 miles away on the average?
That's why besides the marina and boats you'll have cargo ships still running on mazut because the only electric alternative to that is nuclear reactors, that's why farming machinery will run on diesel because you need 12h of continuous runtime and you just can't take hourly recharging breaks every hour, that's why all 4x4s will retain gasoline engines because you won't be able to recharge them on a weekly trip into the mountains, that's why half the trains will keep running on fossil fuel, because electrification of all low-priority lines would be simply too expensive... You're getting so many exceptions to the rule the rule itself becomes a minority.
Yeah, common passenger cars in major part will switch to self-driving electric, and city transport will likely become in major part hybrid. But imagining all semi-trucks will switch to electric engines in 8 years is a pipe dream, and the "All vehicles" is total bullshit if you include ships and airplanes.
You're right! Electric semi-trucks will cruise across the country, electric excavators will dig foundations for new buildings and electric tractors will plow the fields. Electric tankers will haul $25/barrel oil across the sea and electric airlines will fill the sky. All in 8 years! And anyone who claims otherwise is a filthy Trump supporter!
Considering the abnormal rhythm occurs way less than 3% of the time, if the monitoring app displays just a static image of "Ok" at all times, accuracy even higher than 97% is achieved.
I'd like to see specific examples of what was considered compatible code, what was "best practices" and what failed.
Because the moment I saw "Advanced AI grading" I was sure this doesn't really rate quality of code, but conformance to whatever contrived rules the authors thought of. Brace placement, variable naming convention, tabs vs spaces, choice in distribution of problem segments between classes, and all kinds of "flavor" decisions that don't affect quality of code, but will be picked out as "pattern mismatch".
One of our devices comes with control port open; you can enter commands and they will be executed according to your privileges. Besides "login" very few commands should work for the default user... except external software interacting with the device still doesn't support logging in, so the default privileges are set to maximum. You can still log in... to lower your privileges.
It's just about the assumption "constrained by cost" - construction of the hardware is completely attainable. R&D costs are still something nebulous "out there", but that's a single-time expense. Once we have the model, AI will not be fundamentally constrained by cost. Creating copies, or expanding existing instances will be a moderate expense. LHC was about 4.6bln euro, and building a copy of it would still cost some 3bln or so, and it would be hardly useful; you can't double the energies simply by building a second one. But whatever the cost of the first general AI, each consecutive copy will be below $1mln - cost is not the choke point of expanding it indefinitely, and each expansion increases its capacity. The singularity CAN happen.
...as soon as we have the model. It's a breakthrough that's "in 5 years from now for the past 50 years or so", but the critical mass in form of hardware cost and density is there, waiting for the "spark" - cost of indefinite expansion is no longer prohibitive.
If I'm off by 4 orders of magnitude, that's still just a $1bln project and occupies a small campus instead of a room.
And while I likely underestimated the number of cells needed to simulate human neuron *ACCURATELY*, I don't think I missed the target by much, to simulate it *SUFFICIENTLY*. A lot of neuron activity is a side-effect, detrimental to the process, or insignificant, or affecting it in ways that are *different* from trivially achievable through technological means, but not *superior*.
In other words, that's not a hardware that would run a "virtual human." It's a hardware that could run a virtual a sapient being of intelligence comparable to human levels though.
Compare:
You find a contraption: shooting a gimballed paintball gun loaded with white and black balls, at a big white sheet, and reading the result with a camera, interpreting the sheet as the board for Conway's Game of Life, and driving the gun's gimbal.
You try to simulate it.
You can try to simulate the process how the balls fly, how they splatter, how the readout works, and processes the locations for rules of gimbal output.
Or you can write your own Conway's Game of Life implementation in software.
It won't model the first accurately, as the splatters often skip grid lines and paint neighboring cells where they shouldn't, and the contraption has an advanced but flawed error correction facility... but it will create the equivalent automaton that works faster and "cleaner", without the overhead. Its results won't be exactly the same - but it will be the same *class* of results.
So, a million. Add another order of magnitude for boards, racks and all that overhead.
That's 10 million times the volume of human brain. 1260cc for average human male, 1m^3 is 1mln cc, 12,000 m^3, 60x100x2m room. Not excessively big for a data center.
At one time I estimated cost hardware cost of implementation of human brain in FPGA.
I don't remember the exact numbers I used, but that was pretty straightforward, how many FPGA cells to get one neuron, how many neurons in brain, cells in a chip, cost and size of the chip, cost and size of a board, cost and size of a rack, cost and size of the server room and infrastructure.
The cost came in range of $100k, and a very modest computational center, something of order of 100m^2. And the result would be capable of running about 1000x as fast as human brain, simply due to better clock speeds. And have a significantly higher interconnections number too.
Cost of developing the "generic" platform - creating that computational center project, projecting the boards and the infrastructure would be about second that much, mostly off-the-shelf solutions.
The one thing missing was decoding the human brain structure and transferring it into the electronic model, neuron by neuron, axon by axon. We're not there yet. But it's far from impossible. Morally questionable, difficult, fault-prone, and you'd still need to implement "I/O" for this - counterparts of ears, eyes, etc - but it's far from impossible.
Writing code is a creative process. Obviously creator's attitudes infuse the creations.
Comparison to handwriting is a poor one, if somewhat evocative. It's more like writer's style.
Some creators adopt YAGNI philosophy, writing code that is simple, easy to understand, but doesn't suggest any expansion paths, and can turn to spaghetti if the expansions are managed. Some reinvent every wheel, writing every function themselves, others take the "golden hammer" to the extreme and create a dependency hell, trying to create a small centralized core that does everything using library functions. Some create rigid user interface following optimal use cases (actual or mistakenly imagined), others take customizability to the extreme, making the interface unusable mess until you take half an hour to configure it and remove all the crap you don't need. Some make programs that do only what says on the box and nothing more, others create APIs or operating systems disguised as applications.
Systemd started as a very simple, neat idea:
- create an alternative for initV that parallelizes startup of services; - to speed up startup more, not to delay startup of services waiting until other services initialized, provide socket management, creating sockets "customer" programs would wait for, then bind them to their standard "providers" once they started up. - do away with rigid sequence, instead manage startup as a set of dependencies to reach a certain state.
The idea was very sound and nice. Except it didn't end there.
- Some services needed these sockets actually working and not just present. So let's replace the provider and create own replacement as a part of systemd! And screw well established strategy, we're rewriting it our way! Here, take the binary log files! - Some services didn't really work with the "dependency tree" strategy, since ancient times written as sequences of operations. These couldn't be easily parallelized. So screw your firewall, have ours! - Some services used alternate communication methods that sockets. Kill them off, replace with systemd functions! - Some of them would centralize startup of other services as needed. But that's our job! Die, inetd with your easy config!
And even if each "motion" by itself had a valid justification, the replacements offered by systemd are sub-par. Primarily because systemd developers don't believe in simple, straightforward, easy configurations. It's their attitude rubbing off.
A decent system does offer a lot of flexibility, with all kinds of obscure options, but it primarily offers sensible defaults for every obscure option, so you can get your basic work done in 2-3 lines, and if that's not sufficient, you will find what more can and needs to be done, never forcing you to state the obvious. Systemd though doesn't. You need to alliterate every little thing you want it to do, because the defaults just aren't there. And with some of its demands being quite obscure, it's often hard to find *what* the defaults should be. "Why should we make it easy if we can make it hard? If nobody ever has to write all these little details, they'll never know we had to work to implement handling them!"
You think C is late-night? Add the keyword 'assembly'. It only drops off after midnight, leaves the rest in the dirt in the evening hours and falls way behind the curve during the day.
India has a very high income disparity - and enormous population. Taken as average it appears very poor, but if you just look at the sheer number of people with considerable disposable income, you'll spot a market comparable in size to Western Europe.
Spain is a pretty rich country, about on par with France.
But if you're an arrogant millenial idiot, you think "Spain = latin america" and "India = only poor, dirty people."
And asking "why" is absolutely unnecessary for writing risk assessment software. Correlation is not causation, but correlation is sufficient to assess the risk.
Slashdot Mirror
Reading comments like yours, I'm tempted to invest in kool-aid stocks. You alone must be drinking enough to raise their quarterly reports.
And I have a friend who services GSM control towers. He drives far beyond Tesla limits every day and I don't think his employer would be happy for him taking recharge breaks during billable time - or him being happy about these breaks being unpaid.
You are not everyone. Yes, many cars used by casual drivers will be replaced by electric. But all? All VEHICLES? Any projects for electric cargo ships out there please? Drop that kool-aid.
And 95% of the world lives in the US.
Yeah, I totally see Cuba, Mongolia or Pakistan replacing all their fossil fuel vehicles with electric in 8 years.
...or a blue-collar worker driving heavy machinery. For most of that stuff electric power simply doesn't have nearly enough energy density. And a lot of work is done far from the cities - come on, tell me how is the excavator supposed to dig 500 miles of a trench for a new fibre across the Rocky Mountains, with nearest recharging stations 30 miles away on the average?
You forgot to post the Kickstarter links.
That's why besides the marina and boats you'll have cargo ships still running on mazut because the only electric alternative to that is nuclear reactors, that's why farming machinery will run on diesel because you need 12h of continuous runtime and you just can't take hourly recharging breaks every hour, that's why all 4x4s will retain gasoline engines because you won't be able to recharge them on a weekly trip into the mountains, that's why half the trains will keep running on fossil fuel, because electrification of all low-priority lines would be simply too expensive... You're getting so many exceptions to the rule the rule itself becomes a minority.
Yeah, common passenger cars in major part will switch to self-driving electric, and city transport will likely become in major part hybrid. But imagining all semi-trucks will switch to electric engines in 8 years is a pipe dream, and the "All vehicles" is total bullshit if you include ships and airplanes.
You're right! Electric semi-trucks will cruise across the country, electric excavators will dig foundations for new buildings and electric tractors will plow the fields. Electric tankers will haul $25/barrel oil across the sea and electric airlines will fill the sky. All in 8 years! And anyone who claims otherwise is a filthy Trump supporter!
Considering the abnormal rhythm occurs way less than 3% of the time, if the monitoring app displays just a static image of "Ok" at all times, accuracy even higher than 97% is achieved.
I'd like to see specific examples of what was considered compatible code, what was "best practices" and what failed.
Because the moment I saw "Advanced AI grading" I was sure this doesn't really rate quality of code, but conformance to whatever contrived rules the authors thought of. Brace placement, variable naming convention, tabs vs spaces, choice in distribution of problem segments between classes, and all kinds of "flavor" decisions that don't affect quality of code, but will be picked out as "pattern mismatch".
R-eLish
DoWhatIMean.
One of our devices comes with control port open; you can enter commands and they will be executed according to your privileges. Besides "login" very few commands should work for the default user... except external software interacting with the device still doesn't support logging in, so the default privileges are set to maximum. You can still log in... to lower your privileges.
That's the big question.
It's just about the assumption "constrained by cost" - construction of the hardware is completely attainable. R&D costs are still something nebulous "out there", but that's a single-time expense. Once we have the model, AI will not be fundamentally constrained by cost. Creating copies, or expanding existing instances will be a moderate expense. LHC was about 4.6bln euro, and building a copy of it would still cost some 3bln or so, and it would be hardly useful; you can't double the energies simply by building a second one. But whatever the cost of the first general AI, each consecutive copy will be below $1mln - cost is not the choke point of expanding it indefinitely, and each expansion increases its capacity. The singularity CAN happen.
If I'm off by 4 orders of magnitude, that's still just a $1bln project and occupies a small campus instead of a room.
And while I likely underestimated the number of cells needed to simulate human neuron *ACCURATELY*, I don't think I missed the target by much, to simulate it *SUFFICIENTLY*. A lot of neuron activity is a side-effect, detrimental to the process, or insignificant, or affecting it in ways that are *different* from trivially achievable through technological means, but not *superior*.
In other words, that's not a hardware that would run a "virtual human." It's a hardware that could run a virtual a sapient being of intelligence comparable to human levels though.
Compare:
You find a contraption: shooting a gimballed paintball gun loaded with white and black balls, at a big white sheet, and reading the result with a camera, interpreting the sheet as the board for Conway's Game of Life, and driving the gun's gimbal.
You try to simulate it.
You can try to simulate the process how the balls fly, how they splatter, how the readout works, and processes the locations for rules of gimbal output.
Or you can write your own Conway's Game of Life implementation in software.
It won't model the first accurately, as the splatters often skip grid lines and paint neighboring cells where they shouldn't, and the contraption has an advanced but flawed error correction facility... but it will create the equivalent automaton that works faster and "cleaner", without the overhead. Its results won't be exactly the same - but it will be the same *class* of results.
fund it and program it.
So, a million. Add another order of magnitude for boards, racks and all that overhead.
That's 10 million times the volume of human brain. 1260cc for average human male, 1m^3 is 1mln cc, 12,000 m^3, 60x100x2m room. Not excessively big for a data center.
At one time I estimated cost hardware cost of implementation of human brain in FPGA.
I don't remember the exact numbers I used, but that was pretty straightforward, how many FPGA cells to get one neuron, how many neurons in brain, cells in a chip, cost and size of the chip, cost and size of a board, cost and size of a rack, cost and size of the server room and infrastructure.
The cost came in range of $100k, and a very modest computational center, something of order of 100m^2. And the result would be capable of running about 1000x as fast as human brain, simply due to better clock speeds. And have a significantly higher interconnections number too.
Cost of developing the "generic" platform - creating that computational center project, projecting the boards and the infrastructure would be about second that much, mostly off-the-shelf solutions.
The one thing missing was decoding the human brain structure and transferring it into the electronic model, neuron by neuron, axon by axon. We're not there yet. But it's far from impossible. Morally questionable, difficult, fault-prone, and you'd still need to implement "I/O" for this - counterparts of ears, eyes, etc - but it's far from impossible.
No, children below age of 1 are not eligible for elderly welfare benefits.
Jut claim NSA did it and you've been forbidden to elaborate.
Writing code is a creative process. Obviously creator's attitudes infuse the creations.
Comparison to handwriting is a poor one, if somewhat evocative. It's more like writer's style.
Some creators adopt YAGNI philosophy, writing code that is simple, easy to understand, but doesn't suggest any expansion paths, and can turn to spaghetti if the expansions are managed. Some reinvent every wheel, writing every function themselves, others take the "golden hammer" to the extreme and create a dependency hell, trying to create a small centralized core that does everything using library functions. Some create rigid user interface following optimal use cases (actual or mistakenly imagined), others take customizability to the extreme, making the interface unusable mess until you take half an hour to configure it and remove all the crap you don't need. Some make programs that do only what says on the box and nothing more, others create APIs or operating systems disguised as applications.
Systemd started as a very simple, neat idea:
- create an alternative for initV that parallelizes startup of services;
- to speed up startup more, not to delay startup of services waiting until other services initialized, provide socket management, creating sockets "customer" programs would wait for, then bind them to their standard "providers" once they started up.
- do away with rigid sequence, instead manage startup as a set of dependencies to reach a certain state.
The idea was very sound and nice. Except it didn't end there.
- Some services needed these sockets actually working and not just present. So let's replace the provider and create own replacement as a part of systemd! And screw well established strategy, we're rewriting it our way! Here, take the binary log files!
- Some services didn't really work with the "dependency tree" strategy, since ancient times written as sequences of operations. These couldn't be easily parallelized. So screw your firewall, have ours!
- Some services used alternate communication methods that sockets. Kill them off, replace with systemd functions!
- Some of them would centralize startup of other services as needed. But that's our job! Die, inetd with your easy config!
And even if each "motion" by itself had a valid justification, the replacements offered by systemd are sub-par. Primarily because systemd developers don't believe in simple, straightforward, easy configurations. It's their attitude rubbing off.
A decent system does offer a lot of flexibility, with all kinds of obscure options, but it primarily offers sensible defaults for every obscure option, so you can get your basic work done in 2-3 lines, and if that's not sufficient, you will find what more can and needs to be done, never forcing you to state the obvious. Systemd though doesn't. You need to alliterate every little thing you want it to do, because the defaults just aren't there. And with some of its demands being quite obscure, it's often hard to find *what* the defaults should be. "Why should we make it easy if we can make it hard? If nobody ever has to write all these little details, they'll never know we had to work to implement handling them!"
> Interestingly enough I found myself coding
there, no need to elaborate more, you are a nerd :)
You think C is late-night?
Add the keyword 'assembly'. It only drops off after midnight, leaves the rest in the dirt in the evening hours and falls way behind the curve during the day.
The right thing is to have competent people perform the hiring, hire a couple competent admins, and treat them well.
They don't go rogue "for teh lulz".
India has a very high income disparity - and enormous population. Taken as average it appears very poor, but if you just look at the sheer number of people with considerable disposable income, you'll spot a market comparable in size to Western Europe.
Spain is a pretty rich country, about on par with France.
But if you're an arrogant millenial idiot, you think "Spain = latin america" and "India = only poor, dirty people."
Asking "why" is dangerous nowadays.
And asking "why" is absolutely unnecessary for writing risk assessment software. Correlation is not causation, but correlation is sufficient to assess the risk.