You're not the first one with that idea. Germany had quite big state funding for electricity produced by private PV installation. There was a bonus when farmers put PV on otherwise unused barns (don't ask me why). Farmers have built several new barns on turntables just to cover the sun-facing roof with PV. The subsidy was so big - and not adjusted to the quickly dropping price of PV panels - that building a barn-on-turntable was profitable.
I see those barns when going from Hamburg to the Hurricane Festival at Scheeßel.

Additionally, 10€ coins are not just brought into circulation. You have to buy them for 15-20€ each. They're official currency with 10€ value.
And I just learned that there are also 100€ coins. They're made of pure gold and were sold for material price (up to 700€) + 50€. Would you spend one for the 100€ face value?

Not true. 10 Euro "commemorative coins" exist, but they are rare and typically go straight from the mint to collectors. I've never seen one in regular use. The highest value coin actually used is 2 Euros.
Likewise, before the Euro, Germany had 10 DM coins (worth ~5 Euros). In 15 years, i've seen a single one in regular use, where a cashier thought it was a 5 DM coin and gave it to me as change.

I was looking for something free and tried Lightworks. I had a free-hand 720p recording from a Nikon D3100 and wanted to de-shake it, do some noise reduction (temporal, recoring was quite low-light at night), cut it in a few places and store it properly compressed. Nothing special, typical household stuff.
Lightworks free couldn't read the camera's video files (MPEG4/H.264 in MOV containier), had no image stabilization and couldn't export H.264. I also could not find proper noise reduction or a way to use available IS/NR plug-ins from e.g. virtualdub. Also I still don't get the LightworksUI and controls completely.
I ended up using vdubmod to import the camera's video files, doing IS+NR, writing uncompressed video that Lightworks could read. Then do the cutting in Lightworks, again writing uncompressed video, and doing the final H.264 encode with MediaCoder. Performance was disappointing due to huge files sizes.

This is for custom-ROM Android phones and maybe some embedded ARM platforms.
To build a custom ROM (e.g. CyanogenMod) with a newer Android version than what is available from the vendor,
you need a matching driver for the GPU.
The latest official firmware for my phone (Huawei G330) is Android 4.0.4. It contains the QCom GPU driver build for
Android 4.0. To make a CyanogenMod ROM for Android 4.4, you would need a QCom GPU driver for for SoC for
Android 4.4, which is not available as QCom only delevops/delivers those to smartphone vendors under NDA.

Actually, there is an Android 4.4 CyanogenMod ROM. It uses a QCom driver from 4.2 firmware for a different
phone (Sony?) with similar SoC, which was made running on Android 4.4 through quite some kernel hacking.
Due to SoC differences, there are some downsides: performance (some GPU accelleration had to be disabled -> slower, more battery drain),
bugs (gray boxes when zooming in on images in browser) and stability (instant reboot when playing video in Facebook app).

There is no better driver for Android 4.4 available. When freedreno is good enough in terms of features and performance,
I think some developers would be glad to use it and get rid of all the pain to make wrong-version QCom drivers work.

I wonder what the developers behind this inofficial CM builds have to do to get some working QCom driver for Android L (5.0).

I can't see that they're optimizing latency on single placket level. Just the regular link aggregation and failover stuff.

I do understand. Most people say it's not possible with current protocols, and they're right. But on VPN layer, it can be done.
On your PC, the VPN service appears as a network device (vNIC). Somewhere in the VPN software, there's one point where all
network packets sent over the vNIC are serialized into into bytestream to be encrypted (but you don't need that here) and sent
over a TCP connection to the VPN server.
At this point, you have to extend the VPN software to connect to the same server twice, using different routes. (Not sure how to do that,
maybe one can change the default gateway in-between.)
On the receiver side, you need to identify that both connections belong to the same tunnel. As your sender sends the same bytestream
over both links, you can receive on both connections and track the stream position (number of bytes received) of both. With that you can
easily identify which late/duplicate data to drop and what to forward as a combined stream to the output vNIC.

As this is a VPN, on IP level, the game seems to directly talk to the game server on a single link.

Mind that you need to send everything over both links, therefore your combined bandwith is the minimum of both individual ones.
Mind also that with this simple scheme, that when one stream was delayed by a latency spike, it has to keep up to the other one
(send all outstanding data) before it again can mitigate latency spikes on the other link. If this turns out to be a problem, one could
add some signalling from receiver to sender like "on connection B, you don't need to send bytes X ot Y anymore, I have already received it
via connection A".

Note: You never mentioned it, but you need the same handling on the link back (game server to you).

When you're connected via two providers, you have two different public IP adresses.
You want to send each data packet over both links to some server on the internet, which would relay the first incoming copy of each packet to the game server (or another host). Likewise, the game server sends its data to the intermediate server which would need to send each packet to both your public IPs.
On IP level, this is nearly impossible to do, because target and source IPs would need to be rewritten and the intermediate server would need to be told on a different way what the game/other server's IP is.
But on VPN level, I think this can be done. Start with an open source VPN software and when you're good, maybe 3-6 months of software development will do.

On my Hyundai i20, the car's displayed fuel consumption differs from the actual fuel consumption (fuel needed for complete fill-up divided by driven distance from odometer) by -10% to +15%. On average (weighted by distance), the actual fuel consumption is 5% higher than displayed.

Nowadays, a quadcore CPU + GPU with LCD controller + LTE/CDMA/HSPA/EDGE/GSM modem + a/b/g/n/ac-Wifi + Bluetooth + GPS/Glonass/Galileo + FM radio + camera controller + Dual-SIM and SD card interface is a 3-chip solution (e.g. MT9565 platform). Mind those chips plus RAM and Flash should be placed directly together, not via contacts to pluggable modules.

Except for the one master, all slave devices on the Ethercat bus need special Ethercat controllers.
You cannot hook up regular Ethernet controllers there, and hooking up a modern
car media player/navigation/controls embedded PC with Ethernet won't work.
I think that's one of the goals when moving to Ethernet.

Try better LED bulbs. I have a few "Philips Master LEDspot HV DimTone" and they can be perfectly dimmed from 50W equivalent to darker than a candle. They even have 2 LED colors built-in so that they can simulate incandescents, going from warm white to orange when dimmed.

For those who have never heard about troy ounces: that's around 3200US$/kg (2500€/kg) for Ruthenium resp. ten times that for Iridium.

You could also build a camera out of a medical X-ray sensor, with pixel size around 150 micron. Sensors are typically 43x43cm (17x17 inch) wide, which might be a problem.

While I have no need for a 20inch 4K tablet, I'm very interested in an affordable monitor based on that panel. Even more if they made it a bit larger, say 24".