iDrive, which is supposed to be a remote backup service, has a similar problem. They used to be a honest remote backup service, with client-side encryption. (They didn't protect the client password very well on the client machine, but at least the server didn't have it.) File contents were encrypted, but filenames were not, so you could look at logs and the directory tree on line. Then they came out with a "new version" of the service, one that is "web based" and offers "sharing".
For "sharing" to work, of course, they need to know your encryption key. They suggest using the "default encryption key". Even if you're not "sharing", when you want to recover a copy of a file, you're prompted to enter your encryption key onto a web page. The web page immediately sends the encryption key to the server as plain text, as can be seen from a browser log.
Asked about this, they first denied the problem, then, when presented with a browser log, refused to answer further questions.
They try real hard to get their hands on your encryption key. After you log into their web site, a huge pop-up demands your encryption key. Without it, some of the menu items at the top of the page still work, and with some difficulty, you can actually find logs of what you backed up. You can't browse your directory tree, though.
It's possible to use the service securely (maybe), but you have to run only the application for recovery, and never use the web-based service. They don't tell you that.
This isn't a free service. I pay them $150 a year.
The author has a point. At one time, there were development tools, which cost money, were relatively static, and which were expected to work correctly. Then there were applications, which relied on the development tools.
We now have a huge proliferation of tools, many of them open source, poorly integrated with each other, and most badly maintained. Worse, because everything has a client side and a server side, there are usually two independent tool chains involved.
Web programming is far too complex for how little most web sites do. (And the code quality is awful. Open a browser console and watch the errors scroll by.)
As an actual product available right now, there's this 250 watt inverter. from Enphase, intended to work with one solar panel. That's 54 cubic inches, or 12W/cubic inch. Google wants 50W/cubic inch, so Google is asking for 4x the power density.
This one happens to be configured for 48VDC input, but that's not hard to change. It exceeds the efficiency limit set by Google.
Enphase sells those little inverters for a one-inverter-per-solar-panel system, where power is combined on the AC side. The inverter, at 171 mm x 173 mm x 30 mm, is a lot smaller than the panel it sits behind. Making it smaller won't have any effect on system size.
One big difference: Enphase offers a 25 year warranty on that unit. Google only wants to run for 100 hours. They'll probably get something that will pass their tests but wouldn't last a year in a real solar installation.
The US has "Christian ISPs", with server side porno filtering. They're very small. And very retro. One has terms that say they reserve the right to disconnect your dial-up connection after 10 minutes of inactivity.
This is a general problem with devices that are "paired". How do you securely establish the initial connection, when neither side knows anything about the other?
The secure solutions involve some shared secret between the two devices. This requires a secure transmission path between the devices, such as typing in a generated key (like a WPA2 key) or physically carrying a crypto key carrier to each device (this is how serious cryptosystems work).
Semi-secure systems involve things like creating a short period of temporary vulnerability (as with Bluetooth pairing). There's a scheme for sharing between cellphones where you bump the phones together, and they both sense the deceleration at close to the same time.
Apple's reputation management service is reacting faster now. It used to take them an hour to mod criticism down. Now it only takes 15 minutes. Who are they using?
Consider trying QNX, the message-passing real time OS, for this. This is a message passing problem, and Linux doesn't do message passing well. QNX has a scheduler optimized for message passing. You should be able to handle the UDP front end and fan-out without any problems. You can give the front-end process a higher priority than the other processes, which should let you get all the UDP packets into the fan-out program without losing any. That's what real-time OSs are for.
So each Python process should be single-thread. Have as many as you need, set up to get work via MsgReceive and reply by MsgReply. Don't set them up as "resource managers".
Python under QNX is being used by the robotics community, where real-time matters for some things, but not others.
QNX - great technology, marketing operation from hell.
That level of control probably belongs at the cluster management level. We need to do less in the OS, not more. For big data centers, images are loaded into virtual machines, network switches are configured to create a software defined network, connections are made between storage servers and compute nodes, and then the job runs. None of this is managed at the single-machine OS level.
With some VM system like Xen managing the hardware on each machine, the client OS can be minimal. It doesn't need drivers, users, accounts, file systems, etc. If you're running in an Amazon AWS instance, at least 90% of Linux is just dead weight. Job management runs on some other machine that's managing the server farm.
Because the US savings rate is so low (most people are spending almost all they earn), advertising does not increase demand. It just moves it around a bit. All advertising does is increase prices. There are many products, from movies to medications, where the advertising cost exceeds the cost of production. Let's put the brakes on advertising.
That jet-powered locomotive was neverintended as a useful means of propulsion. It was just to test track-train dynamics at higher speed. Not much was done with the info, since Amtrak wasn't into high speed rail.
The next big advances in high speed rail were Japan's Tokaido line and San Francisco's BART, both around 1970. The original Tokaido trains had conventional wheel arrangements, and required a very good and very high maintenance roadbed. The SF BART system had the first trains with an active suspension, with each car body supported on a triangle of three air bags controlled by electronic controls. This allowed a higher body height at higher speed, allowing more wheel travel and a softer suspension. Also, all wheels were powered, as is normal in transit operations.
The French TGV brought both of those ideas together - high speed plus active suspension with more suspension travel, with all wheels powered. This allowed high speed trains without excessive track wear. (That's a big problem with high speed rail. A French test in 1955 reached 331 km/h, but damaged the track seriously in only one run. There were serious doubts for years whether steel wheel on steel rail could ever go that fast in routine operation.)
As with cars, there's been more than enough power to go fast for decades. Wheel and suspension issues are what limit speed.
What "software renaissance"? The writer means the appcrap boom - millions of small bad programs, with a few good ones. Many, maybe most, "apps" could just as well be web pages.
The appcrap boom seems to be winding down. Developers realize that writing a quickie app has roughly the success percentage of starting a garage band. That's a good thing.
It's a great time to code, if you have a problem to solve. The tools are cheap if not free, the online resources are substantial, and there's vast amounts of cheap computing power available on every platform from wrist to data center. If you don't have a problem to solve, coding is sort of pointless.
Heating, ventilating, and air conditioning. The job sucks, but it's steady. Automation of ductwork installation and repair is a long way off. Unlike construction, there's maintenance work; someone always needs their A/C fixed.
A "web based password manager" has one job - keeping the passwords secure. That's all it does. If anyone easily finds a vulnerability in that, the service is a failure.
Come on.
The article is a joke.
" A chess facilitator brain implant would be wired between perception and cognition. You would just look at the board and know if it is checkmate." Did the original poster not realize this?
It gets this property from its fine surface structure, which is a forest of tubes. Incoming light has to be reflected many times before it gets back out, so a black material is effectively made even less reflective. It's the optical-scale version of the pointed absorbers used in anechoic chambers.
It probably is not going to retain its blackness when exposed to water, dirt, or wear. Superhydrophobic coatings such as Never Wet have the same problem - they work because they're composed of tiny points, so droplets of liquid don't have a surface they can grab. But after some wear, the effect stops working. (See any of the many "NeverWet fails" videos on YouTube.)
This is likely to be great for protected environments, such as inside optical systems. It should be useful for optical sensors in space, too. But it's probably an inherently fragile surface. That limits its uses. (The "stronger than steel" probably refers to the individual carbon nanotubes, not the bulk material.)
This s a problem with a lot of surface chemistry stuff touted as "nanomaterials". They have interesting surface properties, but the surfaces are fragile, because they're some very thin surface layer with an unusual structure. If you protect that structure with some coating, you lose the effect.
Here's the promotional video from Rafael, the system's maker.
If the Iron Dome launchers are in a position to hit incoming rockets when they're still in boost phase, they're clearly effective. When they hit, the ascending rocket's flare disappears. Israel has Iron Dome launchers both forward postioned near Gaza, for boost phase defense, and near cities, for terminal defense. For terminal defense, it's harder to tell if they worked. The incoming rockets are just falling at that point, and success requires blowing up their warhead, not their rocket engine.
Videos show the missile's warhead exploding. That's triggered by a proximity fuse. There's a spray of shrapnel from the warhead; it doesn't have to be a direct hit. Whether that sets off the incoming rocket's warhead isn't visible from the videos of terminal defense.The Patriot missiles used in the Gulf war were able to hit incoming Scud missiles, but often didn't detonate the warhead.
It wouldn't have done what he envisioned, but it could well have proven to be the worlds' first VLF radio station.
Marconi already had VLF working, sort of, before Wardenclyffe was built. Marconi's R&D approach was to transmit across short distances, test and improve the hardware, then try longer distances. Over a few years, he slowly worked up from across the room to across the ocean. Less grandiose than Tesla, but more successful.
Tesla is said to have assisted in the construction of the 1913 Telefunken VLF station on Long Island, but the IRE Journal article doesn't mention him. Telefunken built a VLF antenna much the way one would be built today - a simple guyed tower resting on an insulator base, with wires spreading outward to a circle of poles. They only used 35KW, instead of Tesla's 200KW. The station communicated with a similar station in Germany.
Tesla did great work with AC generators and motors. Most common AC motors today still use approaches he invented. That's his legacy.
Wardenclyffe, though, is a monument to failure. From his patents, you can read how he thought it would work. He thought the ionosphere was a conductive layer. The Wardenclyffe tower was supposed to punch power through the atmosphere to that conductive layer, so that signals and maybe power could be received elsewhere.
The ionosphere does not work that way. Tesla's tower would have done nothing useful, although with 200KW at 20KHz going in, it probably could have lit up fluorescent lamps and gas tubes for some distance around. Since the location is now surrounded by a housing subdivision, rebuilding the tower and powering it up would annoy the neighbors.
Slashdot Mirror
iDrive, which is supposed to be a remote backup service, has a similar problem. They used to be a honest remote backup service, with client-side encryption. (They didn't protect the client password very well on the client machine, but at least the server didn't have it.) File contents were encrypted, but filenames were not, so you could look at logs and the directory tree on line. Then they came out with a "new version" of the service, one that is "web based" and offers "sharing".
For "sharing" to work, of course, they need to know your encryption key. They suggest using the "default encryption key". Even if you're not "sharing", when you want to recover a copy of a file, you're prompted to enter your encryption key onto a web page. The web page immediately sends the encryption key to the server as plain text, as can be seen from a browser log. Asked about this, they first denied the problem, then, when presented with a browser log, refused to answer further questions.
They try real hard to get their hands on your encryption key. After you log into their web site, a huge pop-up demands your encryption key. Without it, some of the menu items at the top of the page still work, and with some difficulty, you can actually find logs of what you backed up. You can't browse your directory tree, though.
It's possible to use the service securely (maybe), but you have to run only the application for recovery, and never use the web-based service. They don't tell you that.
This isn't a free service. I pay them $150 a year.
The author has a point. At one time, there were development tools, which cost money, were relatively static, and which were expected to work correctly. Then there were applications, which relied on the development tools.
We now have a huge proliferation of tools, many of them open source, poorly integrated with each other, and most badly maintained. Worse, because everything has a client side and a server side, there are usually two independent tool chains involved.
Web programming is far too complex for how little most web sites do. (And the code quality is awful. Open a browser console and watch the errors scroll by.)
As an actual product available right now, there's this 250 watt inverter. from Enphase, intended to work with one solar panel. That's 54 cubic inches, or 12W/cubic inch. Google wants 50W/cubic inch, so Google is asking for 4x the power density. This one happens to be configured for 48VDC input, but that's not hard to change. It exceeds the efficiency limit set by Google.
Enphase sells those little inverters for a one-inverter-per-solar-panel system, where power is combined on the AC side. The inverter, at 171 mm x 173 mm x 30 mm, is a lot smaller than the panel it sits behind. Making it smaller won't have any effect on system size.
One big difference: Enphase offers a 25 year warranty on that unit. Google only wants to run for 100 hours. They'll probably get something that will pass their tests but wouldn't last a year in a real solar installation.
The US has "Christian ISPs", with server side porno filtering. They're very small. And very retro. One has terms that say they reserve the right to disconnect your dial-up connection after 10 minutes of inactivity.
This is a general problem with devices that are "paired". How do you securely establish the initial connection, when neither side knows anything about the other?
The secure solutions involve some shared secret between the two devices. This requires a secure transmission path between the devices, such as typing in a generated key (like a WPA2 key) or physically carrying a crypto key carrier to each device (this is how serious cryptosystems work).
Semi-secure systems involve things like creating a short period of temporary vulnerability (as with Bluetooth pairing). There's a scheme for sharing between cellphones where you bump the phones together, and they both sense the deceleration at close to the same time.
Apple's reputation management service is reacting faster now. It used to take them an hour to mod criticism down. Now it only takes 15 minutes. Who are they using?
This may be the backdoor known as DROPOUTJEEP, which was described in some Snowden-leaked documents last year.
Looks like Apple sold out, put in a backdoor, and then lied about it.
Consider trying QNX, the message-passing real time OS, for this. This is a message passing problem, and Linux doesn't do message passing well. QNX has a scheduler optimized for message passing. You should be able to handle the UDP front end and fan-out without any problems. You can give the front-end process a higher priority than the other processes, which should let you get all the UDP packets into the fan-out program without losing any. That's what real-time OSs are for.
Trying to do anything high-performance with CPython's threads is hopeless. Watch this presentation on performance issues with Python's Global Interpreter Lock, Python has an internal scheduler, and it behaves very badly under load.
So each Python process should be single-thread. Have as many as you need, set up to get work via MsgReceive and reply by MsgReply. Don't set them up as "resource managers".
Python under QNX is being used by the robotics community, where real-time matters for some things, but not others.
QNX - great technology, marketing operation from hell.
That level of control probably belongs at the cluster management level. We need to do less in the OS, not more. For big data centers, images are loaded into virtual machines, network switches are configured to create a software defined network, connections are made between storage servers and compute nodes, and then the job runs. None of this is managed at the single-machine OS level.
With some VM system like Xen managing the hardware on each machine, the client OS can be minimal. It doesn't need drivers, users, accounts, file systems, etc. If you're running in an Amazon AWS instance, at least 90% of Linux is just dead weight. Job management runs on some other machine that's managing the server farm.
There is a serious bipartisian proposal in Congress to reduce the tax deduction for advertising. Call your Congressional representative and tell them you support the elimination of tax deductions for advertising.
Because the US savings rate is so low (most people are spending almost all they earn), advertising does not increase demand. It just moves it around a bit. All advertising does is increase prices. There are many products, from movies to medications, where the advertising cost exceeds the cost of production. Let's put the brakes on advertising.
It's not just about Wikipedia. Mr. Barry's press agent claims he is also suing the National Post (Canada) for publishing a critical article, "The world according to Yank: Montrealer with checkered past gets Nobel nod, or does he?"
That jet-powered locomotive was neverintended as a useful means of propulsion. It was just to test track-train dynamics at higher speed. Not much was done with the info, since Amtrak wasn't into high speed rail.
The next big advances in high speed rail were Japan's Tokaido line and San Francisco's BART, both around 1970. The original Tokaido trains had conventional wheel arrangements, and required a very good and very high maintenance roadbed. The SF BART system had the first trains with an active suspension, with each car body supported on a triangle of three air bags controlled by electronic controls. This allowed a higher body height at higher speed, allowing more wheel travel and a softer suspension. Also, all wheels were powered, as is normal in transit operations.
The French TGV brought both of those ideas together - high speed plus active suspension with more suspension travel, with all wheels powered. This allowed high speed trains without excessive track wear. (That's a big problem with high speed rail. A French test in 1955 reached 331 km/h, but damaged the track seriously in only one run. There were serious doubts for years whether steel wheel on steel rail could ever go that fast in routine operation.)
As with cars, there's been more than enough power to go fast for decades. Wheel and suspension issues are what limit speed.
You want, of course, to block all email from pseudonyms.
What "software renaissance"? The writer means the appcrap boom - millions of small bad programs, with a few good ones. Many, maybe most, "apps" could just as well be web pages.
The appcrap boom seems to be winding down. Developers realize that writing a quickie app has roughly the success percentage of starting a garage band. That's a good thing.
It's a great time to code, if you have a problem to solve. The tools are cheap if not free, the online resources are substantial, and there's vast amounts of cheap computing power available on every platform from wrist to data center. If you don't have a problem to solve, coding is sort of pointless.
Heating, ventilating, and air conditioning. The job sucks, but it's steady. Automation of ductwork installation and repair is a long way off. Unlike construction, there's maintenance work; someone always needs their A/C fixed.
A "web based password manager" has one job - keeping the passwords secure. That's all it does. If anyone easily finds a vulnerability in that, the service is a failure.
MakerBot has never before sold through a retail outlet that takes returns. A lot of those machines will come back.
Come on. The article is a joke. " A chess facilitator brain implant would be wired between perception and cognition. You would just look at the board and know if it is checkmate." Did the original poster not realize this?
I didn't research so forgive my ignorance
It gets this property from its fine surface structure, which is a forest of tubes. Incoming light has to be reflected many times before it gets back out, so a black material is effectively made even less reflective. It's the optical-scale version of the pointed absorbers used in anechoic chambers.
It probably is not going to retain its blackness when exposed to water, dirt, or wear. Superhydrophobic coatings such as Never Wet have the same problem - they work because they're composed of tiny points, so droplets of liquid don't have a surface they can grab. But after some wear, the effect stops working. (See any of the many "NeverWet fails" videos on YouTube.)
This is likely to be great for protected environments, such as inside optical systems. It should be useful for optical sensors in space, too. But it's probably an inherently fragile surface. That limits its uses. (The "stronger than steel" probably refers to the individual carbon nanotubes, not the bulk material.)
This s a problem with a lot of surface chemistry stuff touted as "nanomaterials". They have interesting surface properties, but the surfaces are fragile, because they're some very thin surface layer with an unusual structure. If you protect that structure with some coating, you lose the effect.
This is going to be useful for the insides of optical systems, lens hoods, and such. Other than that, probably not that significant.
Remind me again why Windows has the capability to "inject" a new DLL into a running process from outside the process.
Here's the promotional video from Rafael, the system's maker. If the Iron Dome launchers are in a position to hit incoming rockets when they're still in boost phase, they're clearly effective. When they hit, the ascending rocket's flare disappears. Israel has Iron Dome launchers both forward postioned near Gaza, for boost phase defense, and near cities, for terminal defense. For terminal defense, it's harder to tell if they worked. The incoming rockets are just falling at that point, and success requires blowing up their warhead, not their rocket engine.
Videos show the missile's warhead exploding. That's triggered by a proximity fuse. There's a spray of shrapnel from the warhead; it doesn't have to be a direct hit. Whether that sets off the incoming rocket's warhead isn't visible from the videos of terminal defense.The Patriot missiles used in the Gulf war were able to hit incoming Scud missiles, but often didn't detonate the warhead.
Nadella used to run Bing. Did anything change there while he was in charge?
It wouldn't have done what he envisioned, but it could well have proven to be the worlds' first VLF radio station.
Marconi already had VLF working, sort of, before Wardenclyffe was built. Marconi's R&D approach was to transmit across short distances, test and improve the hardware, then try longer distances. Over a few years, he slowly worked up from across the room to across the ocean. Less grandiose than Tesla, but more successful.
Tesla is said to have assisted in the construction of the 1913 Telefunken VLF station on Long Island, but the IRE Journal article doesn't mention him. Telefunken built a VLF antenna much the way one would be built today - a simple guyed tower resting on an insulator base, with wires spreading outward to a circle of poles. They only used 35KW, instead of Tesla's 200KW. The station communicated with a similar station in Germany.
The Tesla Museum already exists.
Tesla did great work with AC generators and motors. Most common AC motors today still use approaches he invented. That's his legacy.
Wardenclyffe, though, is a monument to failure. From his patents, you can read how he thought it would work. He thought the ionosphere was a conductive layer. The Wardenclyffe tower was supposed to punch power through the atmosphere to that conductive layer, so that signals and maybe power could be received elsewhere.
The ionosphere does not work that way. Tesla's tower would have done nothing useful, although with 200KW at 20KHz going in, it probably could have lit up fluorescent lamps and gas tubes for some distance around. Since the location is now surrounded by a housing subdivision, rebuilding the tower and powering it up would annoy the neighbors.