It's pretty great. I have a NAS that acts as a DLNA streaming server too for additional media that I want to play from the local source and pair it with AllCast.
You can stream video from mostly any source, even from videos embedded in web pages.
In the small-ish world of open-source & embedded graphics, toolkits, and SW / HW rendering implementors, there are few who have been at it as long and have such a breadth / depth of experience in so many areas as yourself.
As someone who has done a fair bit of searching for resources on the theory and practical design of such systems, I must say, that there are few books out there that concisely describe the "how" and "why" in a design-patterns kind of way tie in with immediately relevant topics (e.g. fbdev, widget & drawing libs, scene-graphs). Naturally, implementors often pick up the talent and ensure that trade secret is kept that way, but you are at a bit of an advantage I think, no?
You've been at E for a *long* time and you've done an insane amount of work making SW rendering almost as efficient as HW rendering - I'm sure there is no shortage of material.
Have you ever thought about writing a book - sharing some of your expertise with the world in a less formal language? Not something that's all-encompassing by any means but maybe with references for further reading. What about a techno-biography of E?
Last year it was great seeing your presentation and getting a chance to bounce some ideas off you at FOSDEM.
The 2013 schedule is still open - are you planning to go again this year and / or give a talk?
The OpenSSL libraries in Android are in the/system partition, and hence, can be patched via OTA update. So yes, they are provided by the OS. And unless the API has changed for OpenSSL (likely not), all Android apps require no modification to be considered secure after said OTA update.
Rather than attempting to discourage Android app developers, the linked article really should just be putting pressure on Google, OHA members, and carriers to release OTA updates that include a patch to OpenSSL.
Also, I bet there will be a big handful of mechanics who get a nice 10A buzz when they remove the panels without properly discharging the capacitors first.
My first question would be about the power that board is consuming ddr3 support (800+ MT/s). Keep in mind that transistors sink the most amount of current (i.e. consume power) when they are in the process of switching from '0' to '1' and vice versa. So if The bus speed has just increased by at least a factor of 4, then power consumption might have increased proportionally. A think a performance-per-watt graph comparing the Exynos chip and a dual core atom is in order (ahem.... tom's... cough... hardware... sniff).
My next question would be, "where are the Mali GPU drivers?" A free as in speech implementation of all patent unencumbered interfaces of this GPU would be brilliant. Can't wait to talk to the Linaro devs;-)
It's often ___immeasureably__ useful to get some (any) kind of console output when porting Linux to an existing device running e.g. windows mobile 5 or 6. Take a look at HaRET. Porting is often harder than most would imagine, as some manufacturers actively use hardware obfuscation methods to prevent hacktivists from getting console access.
Try to imagine how long it would take to use LEDs or haptic feedback to iteratively check all conditions required to bring up Linux on a board without a serial port. The first thing you would probably do is try to use a hardware subsystem that was known to work and fashion a serial port out of it. This is the same concept but graphical.
Seriously - if a company no longer supports a product that still has a fairly large market, a lot of (particularly north-american) people will just throw the product in the garbage. Look at the billions of __WORKING__ cellular phones that end up in landfills. If users were given the freedom to improve the firmware on these aging products and make them relevent and useful again, we could give those devices away for free to people in the world who need them, or resell them.
It's better than waiting 1 million years for something to decompose in a landfill.
Just to clarify: I have signed NDAs and can verify that there are at least two soc's (specifics intentionally omitted) with integrated applications and baseband processors with all of the aforementioned capabilities.
That is, not unless 1) you plan on manufacturing units in the 10s of thousands, 2) you sign an NDA and have some background checks done, or 3) happen to 'find' the docs on certain russian / chinese websites.
Most people have absolutely no idea that an entirely proprietary RTOS runs the baseband processor of their mobile phones, and that this RTOS has direct hardware access to all of the peripheral IO devices and sensors (GPS, microphone, data modem, etc). In many cases, the RTOS firmware is encrypted. In almost all cases it is more or less impossible for "the average consumer" to reprogram the baseband processor.
It does not matter whether you run an unlocked Android phone with whoever knows how many Cyanogen mods. I highly doubt that Cyanogen has deciphered, disassembled, reprogrammed, reassembled, and reencrypted any baseband firmware images at all.
All baseband firmware is proprietary as regulated by most governments. Well... except for OsmoconBB:)
This is essentially the same thing as wiretapping, which has been a legally regulated capability for telco's for decades. Keep in mind, that wiretapping also 'transmitted' location information, but since the location information was known a priori by the sender and receiver (of the tap), then it could be omitted from the communication channel (zero information gain).
When internet usage boomed, governments also regulated that ISPs must have the capability to 'tap' your internet connection (also from home), which is why ISPs are now regulated to log everything that users do for several months.
Cellular wiretapping is essentially a combination of voice, location, and data monitoring. The location information is encoded by which cell towers acknowledge your IMEI (and GPS receiver coordinates). Nothing has changed in the least about who has control over the infrastructure (except here). Users of Free Software on communication devices can at least have SOME control over the backdoors - i.e. who can turn on your GPS receiver remotely or force a firmware upgrade over the air. Unfortunately, most of the important software that has anything to do with communication is still proprietary, and locked (encrypted?) in the baseband processor stack on most mobile phones and wireless communication devices. For older GSM mobile phones, some users have the option to swap out the baseband processor stack and run OsmoconBB.
Until cellular voice / data / location information can be sufficiently anonymised there is really little difference about which technology Big Brother uses to monitor you. Keep in mind that you (the sender / receiver) can often be tied back to a specific IMEI number or MAC address (and even communication pattern).
The average consumer would already know this if they spoke about "4G" with anyone from the academic community. It isn't here yet.
Re:It's a bit more complex than this article...
on
Pocket Wars and Cores
·
· Score: 1
And the reason why x86 is so power hungry? It's because it's on big bits of silicon. And why's it on big bits of silicon? Because it support hyper-threading, out-of-order executon, has hardware virtualisation extensions, has extensive branch prediction, and tonnes of on chip cache.
And then there is of course the lack of 1.3 GHz memory bus speed. Yeah... that might also be a biggie, although ARM might win due to interconnect distance alone if a licensee ever decided to get in the high-speed memory game. Package-on-package, baby.
Slashdot Mirror
It's pretty great. I have a NAS that acts as a DLNA streaming server too for additional media that I want to play from the local source and pair it with AllCast. You can stream video from mostly any source, even from videos embedded in web pages.
In the small-ish world of open-source & embedded graphics, toolkits, and SW / HW rendering implementors, there are few who have been at it as long and have such a breadth / depth of experience in so many areas as yourself.
As someone who has done a fair bit of searching for resources on the theory and practical design of such systems, I must say, that there are few books out there that concisely describe the "how" and "why" in a design-patterns kind of way tie in with immediately relevant topics (e.g. fbdev, widget & drawing libs, scene-graphs). Naturally, implementors often pick up the talent and ensure that trade secret is kept that way, but you are at a bit of an advantage I think, no?
You've been at E for a *long* time and you've done an insane amount of work making SW rendering almost as efficient as HW rendering - I'm sure there is no shortage of material.
Have you ever thought about writing a book - sharing some of your expertise with the world in a less formal language? Not something that's all-encompassing by any means but maybe with references for further reading. What about a techno-biography of E?
Last year it was great seeing your presentation and getting a chance to bounce some ideas off you at FOSDEM. The 2013 schedule is still open - are you planning to go again this year and / or give a talk?
The OpenSSL libraries in Android are in the /system partition, and hence, can be patched via OTA update. So yes, they are provided by the OS. And unless the API has changed for OpenSSL (likely not), all Android apps require no modification to be considered secure after said OTA update.
Rather than attempting to discourage Android app developers, the linked article really should just be putting pressure on Google, OHA members, and carriers to release OTA updates that include a patch to OpenSSL.
In Canada, restaurants pay people to take this away, and they give it to people who will use it for biofuel :P
yea, totally.
Also, I bet there will be a big handful of mechanics who get a nice 10A buzz when they remove the panels without properly discharging the capacitors first.
My first question would be about the power that board is consuming ddr3 support (800+ MT/s). Keep in mind that transistors sink the most amount of current (i.e. consume power) when they are in the process of switching from '0' to '1' and vice versa. So if The bus speed has just increased by at least a factor of 4, then power consumption might have increased proportionally. A think a performance-per-watt graph comparing the Exynos chip and a dual core atom is in order (ahem.... tom's ... cough... hardware... sniff).
My next question would be, "where are the Mali GPU drivers?" A free as in speech implementation of all patent unencumbered interfaces of this GPU would be brilliant. Can't wait to talk to the Linaro devs ;-)
Doubleplusungood
Some of the legacy projects I've worked on would have a hard time supporting 64bit x86, never mind an architecture that changes the endienness.
ARM EABI := little endian, x86 := little endian ... problem solved.
It's often ___immeasureably__ useful to get some (any) kind of console output when porting Linux to an existing device running e.g. windows mobile 5 or 6. Take a look at HaRET. Porting is often harder than most would imagine, as some manufacturers actively use hardware obfuscation methods to prevent hacktivists from getting console access.
Try to imagine how long it would take to use LEDs or haptic feedback to iteratively check all conditions required to bring up Linux on a board without a serial port. The first thing you would probably do is try to use a hardware subsystem that was known to work and fashion a serial port out of it. This is the same concept but graphical.
Great work!
yeah!
Seriously - if a company no longer supports a product that still has a fairly large market, a lot of (particularly north-american) people will just throw the product in the garbage. Look at the billions of __WORKING__ cellular phones that end up in landfills. If users were given the freedom to improve the firmware on these aging products and make them relevent and useful again, we could give those devices away for free to people in the world who need them, or resell them.
It's better than waiting 1 million years for something to decompose in a landfill.
unfortunately, their browser did not work on Linux :(
that's exactly what I thought.
plus 1 ... decibel !
wtf?? ... i think i pissed my pants while reading this.
Is your data safe? What about your family?
Actually, my wife and son will probably perish, but at least I'll know that my email and bookmarks will be redundantly backed up by Google.
Just to clarify: I have signed NDAs and can verify that there are at least two soc's (specifics intentionally omitted) with integrated applications and baseband processors with all of the aforementioned capabilities.
For regulatory documents, try a search on FCC regulations for radio-interference generating devices. For processors with an integrated baseband radio, you can't (normally) find documentation.
That is, not unless 1) you plan on manufacturing units in the 10s of thousands, 2) you sign an NDA and have some background checks done, or 3) happen to 'find' the docs on certain russian / chinese websites.
What about the radio firmware?
Exactly.
Most people have absolutely no idea that an entirely proprietary RTOS runs the baseband processor of their mobile phones, and that this RTOS has direct hardware access to all of the peripheral IO devices and sensors (GPS, microphone, data modem, etc). In many cases, the RTOS firmware is encrypted. In almost all cases it is more or less impossible for "the average consumer" to reprogram the baseband processor.
It does not matter whether you run an unlocked Android phone with whoever knows how many Cyanogen mods. I highly doubt that Cyanogen has deciphered, disassembled, reprogrammed, reassembled, and reencrypted any baseband firmware images at all.
All baseband firmware is proprietary as regulated by most governments. Well... except for OsmoconBB :)
This is essentially the same thing as wiretapping, which has been a legally regulated capability for telco's for decades. Keep in mind, that wiretapping also 'transmitted' location information, but since the location information was known a priori by the sender and receiver (of the tap), then it could be omitted from the communication channel (zero information gain).
When internet usage boomed, governments also regulated that ISPs must have the capability to 'tap' your internet connection (also from home), which is why ISPs are now regulated to log everything that users do for several months.
Cellular wiretapping is essentially a combination of voice, location, and data monitoring. The location information is encoded by which cell towers acknowledge your IMEI (and GPS receiver coordinates). Nothing has changed in the least about who has control over the infrastructure (except here). Users of Free Software on communication devices can at least have SOME control over the backdoors - i.e. who can turn on your GPS receiver remotely or force a firmware upgrade over the air. Unfortunately, most of the important software that has anything to do with communication is still proprietary, and locked (encrypted?) in the baseband processor stack on most mobile phones and wireless communication devices. For older GSM mobile phones, some users have the option to swap out the baseband processor stack and run OsmoconBB.
Until cellular voice / data / location information can be sufficiently anonymised there is really little difference about which technology Big Brother uses to monitor you. Keep in mind that you (the sender / receiver) can often be tied back to a specific IMEI number or MAC address (and even communication pattern).
ifconfig hwaddr 00:11:22:33:44:55 <=> iwconfig hwaddr 00:11:22:33:44:55 <=> imconfig imei AA-BBBBBB-CCCCCC-D ?
Let's hear it for redundancy!
The average consumer would already know this if they spoke about "4G" with anyone from the academic community. It isn't here yet.
And the reason why x86 is so power hungry? It's because it's on big bits of silicon. And why's it on big bits of silicon? Because it support hyper-threading, out-of-order executon, has hardware virtualisation extensions, has extensive branch prediction, and tonnes of on chip cache.
And then there is of course the lack of 1.3 GHz memory bus speed. Yeah... that might also be a biggie, although ARM might win due to interconnect distance alone if a licensee ever decided to get in the high-speed memory game. Package-on-package, baby.
"Itanium relies on the compiler to optimize code at run-time."
I definitely would NOT buy an Itanium unless they change the compiler to optimize code at compile-time.
I'm cloud bursting. Keeps me in shape.