I disagree. The blobs are the root problem (at least with ARM chips). Without acceleration, ARM systems are unusable. ARM partitions the system into compute units and optimizes for lots of units cooperating through a shared memory. This is in contrast to Intel which is optimized for centralized processing. This fundamental is why ARM systems use 1/10th the power. Got a little video about it: http://www.youtube.com/watch?v=y1WDrhL-vUI
This is really awesome. People are welcome to take a look Linaro's Android builds, which are aimed at the development boards that most of the SoC manufactures are creating. The builds are easy to try. Insert an SD card into your computer, run one command and bingo! There even easy to build from source. See http://www.linaro.org/engineering/getting-started/low-cost-development-boards for the complete list of boards.
Yeah. We're working on it. Because of the way we do kernels (always tracking the latest) it becomes hard to get both Graphics and MM working in these builds. See our current plan for this monthly milestone at: https://launchpad.net/linaro-android/+milestone/11.12.
By using a series of topic branches including an "Android" tracking branch that contains just those patches needed for core functionality Linaro is able to rebase on most kernel versions, 3.1, 3.2..etc. We keep a Linus HEAD and a last -rc version around, calling Linus HEAD "tracking" builds and -rc "staging" builds. We also have all of the enablement for each board split out into topic branches. These can then get octopus merged or stgit'd into a single tree. For Pandaboard this git has all of this broken out: http://git.linaro.org/gitweb?p=people/andygreen/kernel-tilt.git;a=summary.
Your company is within its rights to disable your access. It owns the underlying resources and everything you've produced so far. From the post, it sounds like your slightly incredulous that your company would do this to you, get over it. You gave 4 weeks so spend it documenting and talking with everyone in the company to make sure they have as smooth a transition as possible. When you move on, show good faith by providing a way for them to contact you. If your new job doesn't work out, what you do over the next 4 weeks may be a deciding factor if you want to try and come back.
I know how you feel and so I went looking for greener pastures, found them and returned completely reinvigorated. It changed my way of thinking, looking from the outside in.
You're in a really good place, if your ready to make a move anyway, start taking risks at work. Do projects you feel need to be done, shake things up. What's the worse that'll happen they'll get rid of you - for taking initiative.
The only way to get out of the doldrums is to pick a direction and move. The two directions listed here - move on and return or shake things up and leave forever are only two. What ever you do don't forget to be a decent person, if if you're a risk taker you will be rewarded.
"...this is Chewbacca. Chewbacca is a Wookiee from the planet Kashyyyk. But Chewbacca lives on the planet Endor. Now think about it; that does not make sense!"
"Why would a Wookiee, an eight-foot tall Wookiee, want to live on Endor, with a bunch of two-foot tall Ewoks? That does not make sense!"
"If Chewbacca lives on Endor, you must acquit! The defense rests."
I am an embedded system engineer. I have a Bachelors in Electrical and Computer Engineering and a Masters in Electrical Engineering. I spent my last years in school in the infinitely useful embedded systems program at the University of Colorado, taking among other classes, Real-Time Embedded Systems http://ece.colorado.edu/~ecen5623/ under the insightful guidance of Dr. Sam Siewert. I learned what an embedded systems engineer was from him.
As I continue to develop and meet other embedded system engineers I notice that many embedded system engineers have similar "round about" trajectories into the discipline. A common refrain is, "my company needed this little micro-controller programmed to do... and I volunteered." What I'm getting at is embedded systems engineers come from a diverse background and seemed to eventually gravitate into doing the profession full time. The really good ones keep honing and developing their CS skills.
Fabio Somenzi at the University of Colorado contributes to an open source tool to perform model checking called VIS (Verification Interacting with Synthesis) available at: http://vlsi.colorado.edu/~vis/. I recommend anyone interested in this to check it out. It can perform model checking on Verilog modules directly.
I preferred Joel to Mike and I liked the really obscure stuff, but I know that the franchise owners really wanted to push the format into the mainstream, which they did pretty well. It's kind of like Linux 2.2 vs. 2.6. Version 2.2 was the last Linux that you could really hack on without sorting through piles of code, it feels more homegrown. I think it's the same here, Joel made every show look like it came out of a garage, when they switched to Mike, production budgets went up and it lost some of its "youtubeness".
What's really great about this topic is that it comes up every year about this time. CS or IT? I'd like to give a 3rd option: Applied Math. In my opinion all the really cool things in engineering and all the really good engineers in the computer disciplines have solid Applied Math skills; either from formal studies or self-study.
As a course of study I would encourage you to start out as a Math major and take Math and Programming courses. If you hit a "math limit" continue taking programming courses and begin taking IT courses. If you then hit a "programming limit" finish your studies in IT. Throughout your studies make sure you secure jobs doing IT or Programming, this should sharpen your skills further and help you zero in on a final degree path.
Sounds like a very cool start-up.
If nothing else this little article has lead me to some interesting reading.
I've done some architecture research myself. I invented a Cog Computer. It was really just a thought experiment that turned into a paper and a simulator but it was novel. In essence, the cog computer contains "cogs" which are abstractly while(1) loops where the programmer is not allowed to modify the PC value (no traditional conditionals, loops, etc...). Each cog communicates through ports to other cogs, has its own memory and program store. The whole architecture aims for complete determinism with synchronous behavior. It accomplishes this by having each cog's PC run in lock step. This way data can be produced for ports before it is needed...completely alleviating the need for any cog (task) to block. The WWII enigma machine was implemented using the cog simulator.
I really can't say whether Cell was created as a result of the UMD work. I do think that the programming paradigm of micro tasks has now been found in 2 separate places that I know of and that each architecture has a main controller: the Cell's Power Processing Element and the XMT's Master Thread Control Unit and Global Register File and discrete offload engines: Synergistic Processor Elements (SPEs) and the XMT's Processing Clusters. What I find very novel here is that the Maryland guys have explicitly shot for ease of programming - leading to implicit offload engine allocation guided by an explicit task primitive. The Cell on the other hand uses a more complicated DMA model in lieu of the higher level "taskSpawn" that is made into a taskSpawn via an API. So here we're just trading bandwidth for ease of use it seems.
I'm looking at some of the PMU and Cell programs right now....
Go into Plumbing. The work is steady, fulfilling and pays pretty well. You'll be outside, get paid for the hours you work and have great job security...everyone has to flush you know.
Slashdot Mirror
No they don't. We have enabled builds but we also have "open only builds": https://android-build.linaro.org/builds/~linaro-android/panda-ics-gcc46-kwg-upstream-open/ [linaro.org] That is a 100% open Panda Android build based on the upstream Linux kernel. No proprietary libs at all. Or this one: https://android-build.linaro.org/builds/~linaro-android/imx6-ics-gcc47-freescalelt-stable-open/ [linaro.org] That's a 100% open iMX6 build against GCC 4.7 that has no proprietary components. So not only is it possible, its being done.
We already have it at Linaro: Look at this build from Linaro: https://android-build.linaro.org/builds/~linaro-android/panda-ics-gcc46-kwg-upstream-open/ That is a 100% open Panda Android build based on the upstream Linux kernel. No proprietary libs at all. Or this one: https://android-build.linaro.org/builds/~linaro-android/imx6-ics-gcc47-freescalelt-stable-open/ That's a 100% open iMX6 build against GCC 4.7 that has no proprietary components. So not only is it possible, its being done.
I disagree. The blobs are the root problem (at least with ARM chips). Without acceleration, ARM systems are unusable. ARM partitions the system into compute units and optimizes for lots of units cooperating through a shared memory. This is in contrast to Intel which is optimized for centralized processing. This fundamental is why ARM systems use 1/10th the power. Got a little video about it: http://www.youtube.com/watch?v=y1WDrhL-vUI
This is really awesome. People are welcome to take a look Linaro's Android builds, which are aimed at the development boards that most of the SoC manufactures are creating. The builds are easy to try. Insert an SD card into your computer, run one command and bingo! There even easy to build from source. See http://www.linaro.org/engineering/getting-started/low-cost-development-boards for the complete list of boards.
We've got:
AOSP clone (Panda):
AOSP with 4.6 (Panda)
Snowball
iMX6
iMX53
Origen
Check out the Lilliput, http://store.mp3car.com/Lilliput_869GL_80NP_C_T_8_Touch_Screen_LCD_Monito_p/MON-110.htm. We'll have support for this out of the box.
Yeah. We're working on it. Because of the way we do kernels (always tracking the latest) it becomes hard to get both Graphics and MM working in these builds. See our current plan for this monthly milestone at: https://launchpad.net/linaro-android/+milestone/11.12.
Yup, ZP for Zach Pfeffer. Linaro Android Platform lead. :) Checkout our work at:
https://launchpad.net/linaro-android/+milestone/11.09
https://launchpad.net/linaro-android/+milestone/11.10
https://launchpad.net/linaro-android/+milestone/11.11 ...and our team at:
https://wiki.linaro.org/MeetTheTeam and https://wiki.linaro.org/Platform/Android
feel free to talk to us on freenode in the #linaro-android channel!
By using a series of topic branches including an "Android" tracking branch that contains just those patches needed for core functionality Linaro is able to rebase on most kernel versions, 3.1, 3.2..etc. We keep a Linus HEAD and a last -rc version around, calling Linus HEAD "tracking" builds and -rc "staging" builds. We also have all of the enablement for each board split out into topic branches. These can then get octopus merged or stgit'd into a single tree. For Pandaboard this git has all of this broken out: http://git.linaro.org/gitweb?p=people/andygreen/kernel-tilt.git;a=summary.
...was it, Liquid Hot Magma?
Your company is within its rights to disable your access. It owns the underlying resources and everything you've produced so far. From the post, it sounds like your slightly incredulous that your company would do this to you, get over it. You gave 4 weeks so spend it documenting and talking with everyone in the company to make sure they have as smooth a transition as possible. When you move on, show good faith by providing a way for them to contact you. If your new job doesn't work out, what you do over the next 4 weeks may be a deciding factor if you want to try and come back.
I know how you feel and so I went looking for greener pastures, found them and returned completely reinvigorated. It changed my way of thinking, looking from the outside in.
You're in a really good place, if your ready to make a move anyway, start taking risks at work. Do projects you feel need to be done, shake things up. What's the worse that'll happen they'll get rid of you - for taking initiative.
The only way to get out of the doldrums is to pick a direction and move. The two directions listed here - move on and return or shake things up and leave forever are only two. What ever you do don't forget to be a decent person, if if you're a risk taker you will be rewarded.
For a third option...consider Plumbing.
"...this is Chewbacca. Chewbacca is a Wookiee from the planet Kashyyyk. But Chewbacca lives on the planet Endor. Now think about it; that does not make sense!"
"Why would a Wookiee, an eight-foot tall Wookiee, want to live on Endor, with a bunch of two-foot tall Ewoks? That does not make sense!"
"If Chewbacca lives on Endor, you must acquit! The defense rests."
From: http://en.wikipedia.org/wiki/Chewbacca_defense
I am an embedded system engineer. I have a Bachelors in Electrical and Computer Engineering and a Masters in Electrical Engineering. I spent my last years in school in the infinitely useful embedded systems program at the University of Colorado, taking among other classes, Real-Time Embedded Systems http://ece.colorado.edu/~ecen5623/ under the insightful guidance of Dr. Sam Siewert. I learned what an embedded systems engineer was from him. As I continue to develop and meet other embedded system engineers I notice that many embedded system engineers have similar "round about" trajectories into the discipline. A common refrain is, "my company needed this little micro-controller programmed to do ... and I volunteered." What I'm getting at is embedded systems engineers come from a diverse background and seemed to eventually gravitate into doing the profession full time. The really good ones keep honing and developing their CS skills.
Fabio Somenzi at the University of Colorado contributes to an open source tool to perform model checking called VIS (Verification Interacting with Synthesis) available at: http://vlsi.colorado.edu/~vis/. I recommend anyone interested in this to check it out. It can perform model checking on Verilog modules directly.
I preferred Joel to Mike and I liked the really obscure stuff, but I know that the franchise owners really wanted to push the format into the mainstream, which they did pretty well. It's kind of like Linux 2.2 vs. 2.6. Version 2.2 was the last Linux that you could really hack on without sorting through piles of code, it feels more homegrown. I think it's the same here, Joel made every show look like it came out of a garage, when they switched to Mike, production budgets went up and it lost some of its "youtubeness".
I'm so ashamed.
What's really great about this topic is that it comes up every year about this time. CS or IT? I'd like to give a 3rd option: Applied Math. In my opinion all the really cool things in engineering and all the really good engineers in the computer disciplines have solid Applied Math skills; either from formal studies or self-study. As a course of study I would encourage you to start out as a Math major and take Math and Programming courses. If you hit a "math limit" continue taking programming courses and begin taking IT courses. If you then hit a "programming limit" finish your studies in IT. Throughout your studies make sure you secure jobs doing IT or Programming, this should sharpen your skills further and help you zero in on a final degree path.
Sounds like a very cool start-up. If nothing else this little article has lead me to some interesting reading. I've done some architecture research myself. I invented a Cog Computer. It was really just a thought experiment that turned into a paper and a simulator but it was novel. In essence, the cog computer contains "cogs" which are abstractly while(1) loops where the programmer is not allowed to modify the PC value (no traditional conditionals, loops, etc...). Each cog communicates through ports to other cogs, has its own memory and program store. The whole architecture aims for complete determinism with synchronous behavior. It accomplishes this by having each cog's PC run in lock step. This way data can be produced for ports before it is needed...completely alleviating the need for any cog (task) to block. The WWII enigma machine was implemented using the cog simulator.
I really can't say whether Cell was created as a result of the UMD work. I do think that the programming paradigm of micro tasks has now been found in 2 separate places that I know of and that each architecture has a main controller: the Cell's Power Processing Element and the XMT's Master Thread Control Unit and Global Register File and discrete offload engines: Synergistic Processor Elements (SPEs) and the XMT's Processing Clusters. What I find very novel here is that the Maryland guys have explicitly shot for ease of programming - leading to implicit offload engine allocation guided by an explicit task primitive. The Cell on the other hand uses a more complicated DMA model in lieu of the higher level "taskSpawn" that is made into a taskSpawn via an API. So here we're just trading bandwidth for ease of use it seems. I'm looking at some of the PMU and Cell programs right now....
Its very interesting reading the paper linked to the link http://www.umiacs.umd.edu/users/vishkin/XMT/spaa07 paper.pdf. It reminds me of Mercury Computing Programming Toolkit for Cell Processor Programming. They too have a spawn and join method of concurrent programming see: http://www.mc.com/uploadedImages/MCF-FOE-model.jpg at http://www.mc.com/microsites/cell/ProductDetails.a spx?id=2824. Notice the worker/manager similarity to the spawn/join semantic. It would appear that this chip is fundamentally the same, but provides implicit engine allocation.
Very interesting....
Go into Plumbing. The work is steady, fulfilling and pays pretty well. You'll be outside, get paid for the hours you work and have great job security...everyone has to flush you know.
My favorite bug is the ability to circumvent the type system in C.