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 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.
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".
When you go to the grocery store [..] I'll bet calculating cost/gram or cost/liter is as much of a challenge in Metric countries as cost/ounce is in the US.
Sorry to interrupt you here, but at least in Germany, shops must state the price per kg or liter on the price tag.
A modern AJAX enabled website can spin a 90s computer for a least a little while CPU-wise before loading.
A few years ago, eBay had some flash animation on it's start page showing off a few items with rotation and scaling. It caused constant 70% CPU load on my 1.8GHz Athlon64!
That's because Germans are still reluctant to embrace that Credit Card thingie and without that you have to carry cash to a shop.
Germans (actually all Europeans) don't need credit cards because with EC/Maestro cards, they already have something better: free card and transactions for customers, and just 0.3% transaction fee for merchants. Payment is online with PIN against your bank account. AmEx and others don't offer free cards (here) and seem to take 3-5% transaction fee.
Apple iPod: Just copying audio files to the device doesn't work, special software has to be used, which also updates the index. File and directory names are lost, replaced by has values.
Philips GoGear: You can copy audio files on/off it with any file manager. Directory and file names are preserved. When file system content has been changed, on detach, the device updates the index itself. So you can add/remove tracks with any file manager and the device still can use an index database.
I wonder how they came up with US$ 1.90 retail for 500ml in Germany. That's fair for 2 premium or 3 average 500ml units, but not for one. For that price, there is quite some selection of sixpacks at discounters.
Is it the speed or the address space, or what, that you're calling limited?
On the 2600, the CPU has to generate the video signal, each frame (@60/50Hz), all the time. The playfield makes up around 50% of the analog video signal's beam time. Therefore, even if you use all tricks to have the CPU available for game logic on left, right, top & bottom border, you still have less than 50% of the CPU time available.
If you want to use the hardware sprites (movable overlays), you have around 30% CPU time (=0.36MHz) left for game logic.
Slashdot Mirror
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".
When you go to the grocery store [..] I'll bet calculating cost/gram or cost/liter is as much of a challenge in Metric countries as cost/ounce is in the US.
Sorry to interrupt you here, but at least in Germany, shops must state the price per kg or liter on the price tag.
milk: 1 liter is the standard size with sometimes 0.5 liters also being available
cream: 200 grams standard size, some are 150g
A modern AJAX enabled website can spin a 90s computer for a least a little while CPU-wise before loading.
A few years ago, eBay had some flash animation on it's start page showing off a few items with rotation and scaling.
It caused constant 70% CPU load on my 1.8GHz Athlon64!
i++ or ++i or i = i + 1 doesn't generate an atomic operation. You need some intrinsic like Increment(&i) to get that.
That's because Germans are still reluctant to embrace that Credit Card thingie and without that you have to carry cash to a shop.
Germans (actually all Europeans) don't need credit cards because with EC/Maestro cards, they already have something better: free card and transactions for customers, and just 0.3% transaction fee for merchants. Payment is online with PIN against your bank account. AmEx and others don't offer free cards (here) and seem to take 3-5% transaction fee.
Other vendors can do better.
Apple iPod: Just copying audio files to the device doesn't work, special software has to be used, which also updates the index. File and directory names are lost, replaced by has values.
Philips GoGear: You can copy audio files on/off it with any file manager. Directory and file names are preserved. When file system content has been changed, on detach, the device updates the index itself. So you can add/remove tracks with any file manager and the device still can use an index database.
I hope the US gets to adopt SI units before hitting 4.3L/100km in 2025.
I wonder how they came up with US$ 1.90 retail for 500ml in Germany. That's fair for 2 premium or 3 average 500ml units, but not for one. For that price, there is quite some selection of sixpacks at discounters.
And 130km/h (81 mph) is the recommended speed for highways, meaning if conditions are good, you should go at least 81mph.
Is it the speed or the address space, or what, that you're calling limited?
On the 2600, the CPU has to generate the video signal, each frame (@60/50Hz), all the time.
The playfield makes up around 50% of the analog video signal's beam time. Therefore, even if you use
all tricks to have the CPU available for game logic on left, right, top & bottom border, you still have less
than 50% of the CPU time available.
If you want to use the hardware sprites (movable overlays), you have
around 30% CPU time (=0.36MHz) left for game logic.
http://www.alienbill.com/2600/101/02breach.html