I was getting so much LinkedIn related junk that I stopped using LinkedIn and sent all email from them, or purporting to be from them to trash. If LinkedIn isn't putting in the effort to find their attackers, why should I use them?
That's a nice job. Of course, the only original part is the case. Coneniently, there's someone who sells a board with buttons designed to fit in a GameBoy case and bring out the buttons for emulation purposes.
If you 3D printed a new case, you would't need a Game Boy at all. I wonder if there's a decal set for that.
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.
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.