I was looking into Tesla's patents out of curiosity a few weeks ago and saw that they have a lot of patents regarding lithium-air batteries. It looks like they have looked long and hard at them and come up with ways to address their strengths and weaknesses, even though LABs are probably years away from production.
The Tesla battery design is much safer than the Fisker battery IMO. Each individual cell is protected against excessive current (shorts), under and overvoltage and that circuit is sealed inside each of the 9000 battery cells. In addition, the battery pack is designed such that if catastrophic failure occurs that the hot gases are directed away from the vehicle and occupants.
The Fisker looks really cool but it has a lot of technical issues that are still being resolved. My father owns one. The inside is really cramped despite it being such a huge car. The Tesla model S by comparison is quite roomy, though the headroom in the back seat is lacking.
The batteries used in the Tesla don't suffer from this problem. Each individual battery has independent internal circuitry to disconnect the battery if a short is detected or if the voltage goes too high or too low. Additionally, the battery carrier is designed to direct the gases safely away from the car in the event that runaway battery failure does occur to protect the vehicle and any occupants.
My dad did that to one of his cars. After a really heavy rain he tried to cross an intersection that dipped in the middle and the engine sucked water. He had to have the engine replaced. He now drives a Fisker. The car is gorgeous but not at all reliable. It's been in the shop numerous times due to serious issues, not the least of which is a battery recall on them after a couple of them spontaneously caught fire. The software in the car has also been extremely buggy and the touch screen is so bad as to be almost unusable.
I looked at Tesla's battery design and it is a very safe design. Each of the 9000 cells has individual protection circuits to cut out in the case of shorts as well as prevent under and over voltage, plus if things do go wrong it is designed to direct the hot gases away from the car so as to not cause damage or injure someone.
ARM 64's ISA is radically different than ARM32. All of the things that make Arm "ARM" are gone, such as conditional execution, having the program counter as general purpose register and more. Not only that, the binary encoding is totally different. The binary encoding for ARM64 is a total confusing mess compared to ARM32. I wouldn't say that ARM64 was a well designed ISA.
Other processors made much cleaner transitions between 32 and 64-bit such as MIPS, Power/Power PC and Sparc. Even i386 and x86-64 are much closer than ARM32 vs ARM64.
No it won't. Having done some serious looking in to ARM64 it is almost as much of a mess as X86, and in fact in many ways is worse.
ARM64 has almost nothing in common with ARM32. All of the things that make ARM "ARM" such as conditional execution, having the instruction pointer a general purpose register, etc. are gone in ARM64. The instruction encoding is a complete mess and is totally incompatible with ARM32.
Most RISC processors are fairly clean between 32 and 64-bit instructions. For example, MIPS and PPC just add new 64-bit instructions to the instruction set. ARM is not like this. With ARM, everything down to the most fundamental level changes in 64-bit mode. There is zero compatibility between the two.
As a developer I certainly am not looking forward to ARM64. The stuff I do I periodically need to look at hex output and figure out what instructions are being executed. On MIPS and PowerPC this is trivial. This is not the case on ARM, where the instruction encoding is a complete mess, far worse than X86. It is as if the ARM64 instruction encoding was designed to be obfuscated.
I think the big ARM64 push is the fact that it's not Intel and Microsoft wants to use it to pressure Intel. There are far cleaner 64-bit processors out there including MIPS, PowerPC.
For the record, I work on bootloaders for MIPS64 processors.
I'll believe it when I see it. Many, if not most, of their products run on VxWorks, a proprietary closed-source real-time operating system. All it takes is for someone to find a way to access the t-shell and you own the box. I believe this was recently shown to be trivial to do with access to the web interface (no login needed). Once you are in the t-shell you own the box. In VxWorks the t-shell is like root on steroids. You can call any function, access at any global variables or any memory location that you choose.
VxWorks historically has not been a secure operating system, leaving security entirely up to the applications developer.
VxWorks is not like a traditional operating system where you load programs off of a filesystem and execute them, with a clear separation between the OS and applications. Instead, everything is linked together into a single binary blob. Now it's possible it has changed significantly since I last used it, but I doubt it.
In China human labor is cheap which is why they use it. In the U.S. it's expensive so we automate it. It takes longer to retool equipment to automate it but you do tend to get higher quality. For those who think robots don't have the finesse of human hands, all of those chips on the boards are placed by robots. It's very difficult to reliably do that by hand given how small the tolerances are. Today's robots can do most of what human workers do and in fact do it faster and better. The problem is that it takes a long time to set up all the tooling to do it properly and they can't change on a dime like a human worker can.
The U.S. is still a huge manufacturer. The difference between the U.S. and China is that the U.S. mostly automates things whereas China just throws bodies at it.
I can just see it, a metallic balloon drifts through a lane of traffic and the Nissan goes into panic mode and starts a big chain reaction because the radar, camera and laser scanner detect it as a threat. A real driver would just try and pop the balloon.
That is also one of my questions about how the Google self-driving cars behave in similar situations. Do they panic when a tumbleweed blows across the road?
Then the 2000s should have been a huge boom with GWB's tax cuts. Oh, wait, it wasn't. Part of the reason the economy boomed under Clinton was caused by the tax increases first by Bush Sr and Clinton. This reduced the deficit and helped make cheap credit available for the economy to boom. Most of today's deficit can be blamed on GWB's tax cuts, two wars (one by choice) and the financial collapse of 2008 due in large part to poor financial oversight and deregulation.
Trickle down has been proven not to work. You lower the taxes at the people at the top and they don't start spending more money, they horde it. I think the problem is a lot of the huge financial gains made by the financial sector often don't trickle down to everyone else in a consumer driven economy. If you give money to the people at the bottom they spend everything they have. The expanded unemployment insurance probably helped more than any other form of stimulus since it immediately was pumped right back into the economy. The more money that is made to the bottom and the middle class, the better the economy will do. Most of the time giving more money to those at the top does not result in them hiring more people or buying more stuff.
The CBO released a chart that shows the deficit in detail. More and more of it is due to GWB's tax cuts. If it were not for those we would be in much better shape today.
That is a good policy if you can do it, but in this case it was impossible. We had to use some 3rd party software which used malloc and realloc extensively. To make matters worse, for a long time we could only get obfuscated code to support the network processor we were using, meaning that it was impossible to make changes to it. We also had to make use of it because of the dynamic nature of the software. In our case it really wasn't feasible to avoid mllox. Replacing Windriver's malloc had some huge advantages. Fragmentation was horrible with the VxWorks malloc to the point where there were many tens of thousands of fragments of memory. VxWorks used a sorted linked list from smallest to largest free block. Due to the extensive dynamic reallocs, this linked list turned into a huge bottleneck.
Replacing the code with Doug Lea's malloc eliminated the fragmentation problem completely. By including the task ID and calling function's program counter in each block allocated it made it trivial to find memory leaks and keep track of how much memory and how many blocks were allocated per task or even by function.
There really was no good reason why VxWorks was chosen since there were no hard real-time requirements. The product was a mess (router and broadband remote access server) since each box had to include a Sun Ultrasparc computer running Solaris (we required big-endian) where most of the software ran. Solaris was an even worse choice. Trying to write streams drivers for Solaris was a nightmare compared to Linux drivers, especially when trying to tie into the TCP/IP stack. Not only that, Solaris was quite slow. Give me Linux any day.
The great thing about writing applications in Linux user space is that you can use tools like Valgrind to catch many of these memory leaks, uninitialized variables, etc.
With my long experience with VxWorks this doesn't surprise me. VxWorks is not the most robust RTOS. Think of it as a multi-tasking MS-DOS. The version they used has no memory protection between processes and I have found numerous areas of VxWorks to be badly implemented or downright buggy. Up through version 5.3 the malloc() implementation was absolutely horrid and suffered from severe fragmentation and performance problems. On the platform I was working with I replaced the VxWorks implementation with Doug Lea's implementation (which glibc was based off of) and our startup time dropped from an hour to 3 minutes. I was also able to easily add instrumentation so we could quickly find memory leaks or heap corruption in the field, something not possible with Wind River's implementation. After reading about the problems with the filesystem I looked at the Wind River filesystem code. It was rather ugly. They map FAT on top of flash memory (not the best choice) and the corner cases were not well handled (like a full filesystem).
Similarly, their TCP/IP stack sucked as well. If you can drop to the T-shell through a security exploit you totally own the box (i.e. Huawei's poor security record).
VxWorks is fine for simple applications, but for very complex applications it sucks. At least the 5.x series do not clean up after a task if it crashes because it does not keep track of what resources are used by a task. A task is basically just a thread of execution. All memory is a shared global pool. At the time it did have one feature that was useful that was lacking in Linux, priority inheritance mutexes. These are a requirement for proper real-time performance and I believe are now included in Linux.
I went to high school in the late 1980s and my high school was still dominated by Apple II computers. By that time I had already been writing programs in Turbo Pascal. Through my highschool years I taught myself 8086 assembly language and wrote numerous TSRs and did a lot of hacking. I never bothered with any high school computer classes since if anything they would have been limited to Logo and Basic, which I had thankfully unlearned by then. Fresh out of high school I got an summer internship working on DOS TSRs for a graphics chip manufacturer after one of my programs was brought to their attention since it caused only their graphics cards to fail horribly (rapid XOR operations or similar operations caused their cards to fail horribly in the 320x200 256 color mode).
I agree. I often see output from the compiler and am amazed. It's rare now for me to find cases where I can do better than the compiler. It used to be the case where hand-tuned assembly made a lot of sense, but that's no longer the case, especially if you give hints to the compiler about things like likely/unlikely branch conditions in your code.
I worked on a Linux 802.11n wireless driver and was able to reduce CPU usage by 10% by adding likely/unlikely wrappers in the data path comparisons and analyzed what the compiler did with that info.
You can already do this with DLNA, which is a standard. Some phones, i.e. Samsung, support this (AllShare) for displaying live video content on a large screen.
I know more about the "doom and gloom" than you apparently do, having started out in a bust cycle (Bush 1) and surving just fine through the dot com bust. I got my start during the 1989 recession.
Reputation is extremely important, it goes hand in hand with skill, talent and drive. You can have all the skill and talent in the world but getting to an actual interview without a track record can be difficult. As someone reviewing resumes, why should I bring someone without a degree when I have plenty of resumes from people with experience? If someone has a good reputation they'll go a lot father than someone that may have the best skills in the world but is otherwise an unknown. That's reality. If I'm hiring and I know candidate A is good and candidate B appears good but is an unknown, I'll go with A. I know A will do the job needed and will work with the rest of the team. I'll take a known quantity over an unknown.
There's also more involved than just raw skill and talent. I would much prefer to hire someone who works well with others than some prima donna who is the most talented person in the world who pisses everyone else off. If someone has a reputation of pissing people off calling them douchbags, I'll skip them. I much rather have a cohesive team than a bunch of primo donnas. A good cohesive team will get a lot more done without all the drama.
As far as my case, it was skill, talent, drive and luck. While the economy was better than it is now in many ways, it was still pretty bad. I got an internship coding assembly language fresh out of high school due to a VP at the company seeing my work througha fluke (a diagnostic program written in assembly that caused their graphics chip to fail miserably while competitive hardware passed). If the VP hadn't seen my work it would have been a lot harder to get my foot in the door. This was before the web. If my resume had gone the standard route through HR then it likely would never have seen the light of day.
My reputation from my work during my internship helped me get future jobs as people I knew moved around the valley.
If you ever see a series like "Connections" you would realize that luck does in fact play a major part.
In today's economy it's tough to get started. If I'm reviewing a bunch of resumes and I see one who graduated from a well-known university vs someone fairly new without a degree, the person with a university degree will be the first to get a job interview. They have already proven that they know a certain baseline of material. Also, if I have to choose between someone from a 4-year college vs someone from one of the for-profit technical schools, I'll take the college first.
I'm sorry to say this, but unless you have a really good reputation, forget it.
Now, once you have some real job experience the college degree is less important.
I was self-taught before going to college. I still learned a huge amount in college since I had access to many resources otherwise unavailable to me. I was lucky in that I was able to get an internship during college writing software, (early 1990s) but the economy was in much better shape than it is today.
I worked at GRiD in the early 1990s as an intern while in college. A short 3:35 documentary with Bill Moggridge can be found here. Another good 90 minute documentary can also be found: Pioneering the Laptop - The GRiD Compass. GRiD was a great place to work when I was there. At that time they were doing a lot of work on tablet computers and handwriting recognition.
Many of the people there came from Xerox PARC. The GRiD Compass software was well ahead of its time. It was a multi-tasking operating system with a GUI with network filesystem support. It even had a paid app store, decades before such a thing existed for mobile devices.
The GRiD Compass also incorporated an internal 1200 baud modem and supported a phone handset (with an address book application for dialing).
The times I've had to haul things I just rent a truck. It's relatively cheap and certainly a lot cheaper than owning one and paying the higher gas prices all the time. I rent a truck maybe twice a year. It seems that when I do a large portion of the fee is the price of gas to refill it.
Even Palm copied a lot of stuff. I worked for GRiD Systems (1990-1994) back when Jeff Hawkins worked there. We had a pen-based SDK with handwriting recognition. He developed the handwriting recognition algorithms which were used in the GRiDPad, which incidentally was manufactured by Samsung.
It's stupid for Apple to claim a patent on round buttons. I implemented round buttons on a tablet PC back in the early 1990s back when I worked for GRiD Systems. I wrote a configuration tool that used the pen interface (pre-touchscreen) for configuration and wrote a DOS-based GUI from scratch. I made the buttons with rounded corners using the Turbo C++ graphics library.
Search for CN6880-4NIC10E. It has a Cavium OCTEON CN6880 32-core CPU on it with dual DDR3 interfaces. It would take some work to make it run Debian (requires running the root filesystem over NFS over PCIe or 10Gbe). All of the changes to support Linux are in the process of being pushed upstream to the Linux kernel GIT repository and hopefully sometime in the future I will get enough time to start pushing my U-Boot bootloader changes upstream as well.
All of the toolchain support is in the mainline GCC and binutils and glibc, though some of it might be in GIT since we just pushed our stuff up recently. The toolchain supports all of the extended instructions including those used for encryption and hashing.
There is a SDK but the SDK is generally quite expensive. The SDK is used for writing stand-alone applications that run on bare-metal on various cores in parallel with the Linux kernel. That way Linux runs on some cores and custom networking applications run on other cores without the overhead of a general-purpose operating system. Of course Linux could just as easily run on all the cores. It's a nice 64-bit MIPS platform as long as you don't need floating point. The CPU also has built-in acceleration for encryption, hashing, compression (deflate), pattern matching (regex) and RAID calculations (XOR/RAID6).
The PCIe bus just looks like another high-speed network interface as far as the CPU is concerned, so the card can basically be a network accelerator card for things like encryption or disk I/O. There's SDK add-ons to support things like TCP acceleration, Samba, SNORT, IPSEC and more.
I have no problem saturating 10G links, but then again I'm working on multi-core CPUs with 10-32 cores optimized for networking (the 10G interfaces are built-in to the CPU). I have a PCIe NIC card on my desk with 4 10Gbe ports on it (along with a 32-core CPU).
It's also neat when you can say you're running Linux on your NIC card (it can even run Debian).
Slashdot Mirror
I was looking into Tesla's patents out of curiosity a few weeks ago and saw that they have a lot of patents regarding lithium-air batteries. It looks like they have looked long and hard at them and come up with ways to address their strengths and weaknesses, even though LABs are probably years away from production.
The Tesla battery design is much safer than the Fisker battery IMO. Each individual cell is protected against excessive current (shorts), under and overvoltage and that circuit is sealed inside each of the 9000 battery cells. In addition, the battery pack is designed such that if catastrophic failure occurs that the hot gases are directed away from the vehicle and occupants.
The Fisker looks really cool but it has a lot of technical issues that are still being resolved. My father owns one. The inside is really cramped despite it being such a huge car. The Tesla model S by comparison is quite roomy, though the headroom in the back seat is lacking.
The batteries used in the Tesla don't suffer from this problem. Each individual battery has independent internal circuitry to disconnect the battery if a short is detected or if the voltage goes too high or too low. Additionally, the battery carrier is designed to direct the gases safely away from the car in the event that runaway battery failure does occur to protect the vehicle and any occupants.
My dad did that to one of his cars. After a really heavy rain he tried to cross an intersection that dipped in the middle and the engine sucked water. He had to have the engine replaced. He now drives a Fisker. The car is gorgeous but not at all reliable. It's been in the shop numerous times due to serious issues, not the least of which is a battery recall on them after a couple of them spontaneously caught fire. The software in the car has also been extremely buggy and the touch screen is so bad as to be almost unusable.
I looked at Tesla's battery design and it is a very safe design. Each of the 9000 cells has individual protection circuits to cut out in the case of shorts as well as prevent under and over voltage, plus if things do go wrong it is designed to direct the hot gases away from the car so as to not cause damage or injure someone.
ARM 64's ISA is radically different than ARM32. All of the things that make Arm "ARM" are gone, such as conditional execution, having the program counter as general purpose register and more. Not only that, the binary encoding is totally different. The binary encoding for ARM64 is a total confusing mess compared to ARM32. I wouldn't say that ARM64 was a well designed ISA.
Other processors made much cleaner transitions between 32 and 64-bit such as MIPS, Power/Power PC and Sparc. Even i386 and x86-64 are much closer than ARM32 vs ARM64.
-Aaron
No it won't. Having done some serious looking in to ARM64 it is almost as much of a mess as X86, and in fact in many ways is worse.
ARM64 has almost nothing in common with ARM32. All of the things that make ARM "ARM" such as conditional execution, having the instruction pointer a general purpose register, etc. are gone in ARM64. The instruction encoding is a complete mess and is totally incompatible with ARM32.
Most RISC processors are fairly clean between 32 and 64-bit instructions. For example, MIPS and PPC just add new 64-bit instructions to the instruction set. ARM is not like this. With ARM, everything down to the most fundamental level changes in 64-bit mode. There is zero compatibility between the two.
As a developer I certainly am not looking forward to ARM64. The stuff I do I periodically need to look at hex output and figure out what instructions are being executed. On MIPS and PowerPC this is trivial. This is not the case on ARM, where the instruction encoding is a complete mess, far worse than X86. It is as if the ARM64 instruction encoding was designed to be obfuscated.
I think the big ARM64 push is the fact that it's not Intel and Microsoft wants to use it to pressure Intel. There are far cleaner 64-bit processors out there including MIPS, PowerPC.
For the record, I work on bootloaders for MIPS64 processors.
I'll believe it when I see it. Many, if not most, of their products run on VxWorks, a proprietary closed-source real-time operating system. All it takes is for someone to find a way to access the t-shell and you own the box. I believe this was recently shown to be trivial to do with access to the web interface (no login needed). Once you are in the t-shell you own the box. In VxWorks the t-shell is like root on steroids. You can call any function, access at any global variables or any memory location that you choose.
VxWorks historically has not been a secure operating system, leaving security entirely up to the applications developer.
VxWorks is not like a traditional operating system where you load programs off of a filesystem and execute them, with a clear separation between the OS and applications. Instead, everything is linked together into a single binary blob. Now it's possible it has changed significantly since I last used it, but I doubt it.
In China human labor is cheap which is why they use it. In the U.S. it's expensive so we automate it. It takes longer to retool equipment to automate it but you do tend to get higher quality. For those who think robots don't have the finesse of human hands, all of those chips on the boards are placed by robots. It's very difficult to reliably do that by hand given how small the tolerances are. Today's robots can do most of what human workers do and in fact do it faster and better. The problem is that it takes a long time to set up all the tooling to do it properly and they can't change on a dime like a human worker can.
The U.S. is still a huge manufacturer. The difference between the U.S. and China is that the U.S. mostly automates things whereas China just throws bodies at it.
I can just see it, a metallic balloon drifts through a lane of traffic and the Nissan goes into panic mode and starts a big chain reaction because the radar, camera and laser scanner detect it as a threat. A real driver would just try and pop the balloon.
That is also one of my questions about how the Google self-driving cars behave in similar situations. Do they panic when a tumbleweed blows across the road?
Then the 2000s should have been a huge boom with GWB's tax cuts. Oh, wait, it wasn't. Part of the reason the economy boomed under Clinton was caused by the tax increases first by Bush Sr and Clinton. This reduced the deficit and helped make cheap credit available for the economy to boom. Most of today's deficit can be blamed on GWB's tax cuts, two wars (one by choice) and the financial collapse of 2008 due in large part to poor financial oversight and deregulation.
Trickle down has been proven not to work. You lower the taxes at the people at the top and they don't start spending more money, they horde it. I think the problem is a lot of the huge financial gains made by the financial sector often don't trickle down to everyone else in a consumer driven economy. If you give money to the people at the bottom they spend everything they have. The expanded unemployment insurance probably helped more than any other form of stimulus since it immediately was pumped right back into the economy. The more money that is made to the bottom and the middle class, the better the economy will do. Most of the time giving more money to those at the top does not result in them hiring more people or buying more stuff.
The CBO released a chart that shows the deficit in detail. More and more of it is due to GWB's tax cuts. If it were not for those we would be in much better shape today.
I had a 2 week old Agility 3 suddenly fail to the point where it was not visible on the SATA bus.
That is a good policy if you can do it, but in this case it was impossible. We had to use some 3rd party software which used malloc and realloc extensively. To make matters worse, for a long time we could only get obfuscated code to support the network processor we were using, meaning that it was impossible to make changes to it. We also had to make use of it because of the dynamic nature of the software. In our case it really wasn't feasible to avoid mllox. Replacing Windriver's malloc had some huge advantages. Fragmentation was horrible with the VxWorks malloc to the point where there were many tens of thousands of fragments of memory. VxWorks used a sorted linked list from smallest to largest free block. Due to the extensive dynamic reallocs, this linked list turned into a huge bottleneck.
Replacing the code with Doug Lea's malloc eliminated the fragmentation problem completely. By including the task ID and calling function's program counter in each block allocated it made it trivial to find memory leaks and keep track of how much memory and how many blocks were allocated per task or even by function.
There really was no good reason why VxWorks was chosen since there were no hard real-time requirements. The product was a mess (router and broadband remote access server) since each box had to include a Sun Ultrasparc computer running Solaris (we required big-endian) where most of the software ran. Solaris was an even worse choice. Trying to write streams drivers for Solaris was a nightmare compared to Linux drivers, especially when trying to tie into the TCP/IP stack. Not only that, Solaris was quite slow. Give me Linux any day.
The great thing about writing applications in Linux user space is that you can use tools like Valgrind to catch many of these memory leaks, uninitialized variables, etc.
With my long experience with VxWorks this doesn't surprise me. VxWorks is not the most robust RTOS. Think of it as a multi-tasking MS-DOS. The version they used has no memory protection between processes and I have found numerous areas of VxWorks to be badly implemented or downright buggy. Up through version 5.3 the malloc() implementation was absolutely horrid and suffered from severe fragmentation and performance problems. On the platform I was working with I replaced the VxWorks implementation with Doug Lea's implementation (which glibc was based off of) and our startup time dropped from an hour to 3 minutes. I was also able to easily add instrumentation so we could quickly find memory leaks or heap corruption in the field, something not possible with Wind River's implementation. After reading about the problems with the filesystem I looked at the Wind River filesystem code. It was rather ugly. They map FAT on top of flash memory (not the best choice) and the corner cases were not well handled (like a full filesystem).
Similarly, their TCP/IP stack sucked as well. If you can drop to the T-shell through a security exploit you totally own the box (i.e. Huawei's poor security record).
VxWorks is fine for simple applications, but for very complex applications it sucks. At least the 5.x series do not clean up after a task if it crashes because it does not keep track of what resources are used by a task. A task is basically just a thread of execution. All memory is a shared global pool. At the time it did have one feature that was useful that was lacking in Linux, priority inheritance mutexes. These are a requirement for proper real-time performance and I believe are now included in Linux.
I went to high school in the late 1980s and my high school was still dominated by Apple II computers. By that time I had already been writing programs in Turbo Pascal. Through my highschool years I taught myself 8086 assembly language and wrote numerous TSRs and did a lot of hacking. I never bothered with any high school computer classes since if anything they would have been limited to Logo and Basic, which I had thankfully unlearned by then. Fresh out of high school I got an summer internship working on DOS TSRs for a graphics chip manufacturer after one of my programs was brought to their attention since it caused only their graphics cards to fail horribly (rapid XOR operations or similar operations caused their cards to fail horribly in the 320x200 256 color mode).
I agree. I often see output from the compiler and am amazed. It's rare now for me to find cases where I can do better than the compiler. It used to be the case where hand-tuned assembly made a lot of sense, but that's no longer the case, especially if you give hints to the compiler about things like likely/unlikely branch conditions in your code.
I worked on a Linux 802.11n wireless driver and was able to reduce CPU usage by 10% by adding likely/unlikely wrappers in the data path comparisons and analyzed what the compiler did with that info.
You can already do this with DLNA, which is a standard. Some phones, i.e. Samsung, support this (AllShare) for displaying live video content on a large screen.
I know more about the "doom and gloom" than you apparently do, having started out in a bust cycle (Bush 1) and surving just fine through the dot com bust. I got my start during the 1989 recession.
Reputation is extremely important, it goes hand in hand with skill, talent and drive. You can have all the skill and talent in the world but getting to an actual interview without a track record can be difficult. As someone reviewing resumes, why should I bring someone without a degree when I have plenty of resumes from people with experience? If someone has a good reputation they'll go a lot father than someone that may have the best skills in the world but is otherwise an unknown. That's reality. If I'm hiring and I know candidate A is good and candidate B appears good but is an unknown, I'll go with A. I know A will do the job needed and will work with the rest of the team. I'll take a known quantity over an unknown.
There's also more involved than just raw skill and talent. I would much prefer to hire someone who works well with others than some prima donna who is the most talented person in the world who pisses everyone else off. If someone has a reputation of pissing people off calling them douchbags, I'll skip them. I much rather have a cohesive team than a bunch of primo donnas. A good cohesive team will get a lot more done without all the drama.
As far as my case, it was skill, talent, drive and luck. While the economy was better than it is now in many ways, it was still pretty bad. I got an internship coding assembly language fresh out of high school due to a VP at the company seeing my work througha fluke (a diagnostic program written in assembly that caused their graphics chip to fail miserably while competitive hardware passed). If the VP hadn't seen my work it would have been a lot harder to get my foot in the door. This was before the web. If my resume had gone the standard route through HR then it likely would never have seen the light of day.
My reputation from my work during my internship helped me get future jobs as people I knew moved around the valley.
If you ever see a series like "Connections" you would realize that luck does in fact play a major part.
In today's economy it's tough to get started. If I'm reviewing a bunch of resumes and I see one who graduated from a well-known university vs someone fairly new without a degree, the person with a university degree will be the first to get a job interview. They have already proven that they know a certain baseline of material. Also, if I have to choose between someone from a 4-year college vs someone from one of the for-profit technical schools, I'll take the college first.
I'm sorry to say this, but unless you have a really good reputation, forget it.
Now, once you have some real job experience the college degree is less important.
I was self-taught before going to college. I still learned a huge amount in college since I had access to many resources otherwise unavailable to me. I was lucky in that I was able to get an internship during college writing software, (early 1990s) but the economy was in much better shape than it is today.
-Aaron
Sorry to follow up to my own post, but a tribute to Bill Moggridge can be found here.
I worked at GRiD in the early 1990s as an intern while in college. A short 3:35 documentary with Bill Moggridge can be found here. Another good 90 minute documentary can also be found: Pioneering the Laptop - The GRiD Compass. GRiD was a great place to work when I was there. At that time they were doing a lot of work on tablet computers and handwriting recognition.
Many of the people there came from Xerox PARC. The GRiD Compass software was well ahead of its time. It was a multi-tasking operating system with a GUI with network filesystem support. It even had a paid app store, decades before such a thing existed for mobile devices.
The GRiD Compass also incorporated an internal 1200 baud modem and supported a phone handset (with an address book application for dialing).
-Aaron
The times I've had to haul things I just rent a truck. It's relatively cheap and certainly a lot cheaper than owning one and paying the higher gas prices all the time. I rent a truck maybe twice a year. It seems that when I do a large portion of the fee is the price of gas to refill it.
-Aaron
Even Palm copied a lot of stuff. I worked for GRiD Systems (1990-1994) back when Jeff Hawkins worked there. We had a pen-based SDK with handwriting recognition. He developed the handwriting recognition algorithms which were used in the GRiDPad, which incidentally was manufactured by Samsung.
It's stupid for Apple to claim a patent on round buttons. I implemented round buttons on a tablet PC back in the early 1990s back when I worked for GRiD Systems. I wrote a configuration tool that used the pen interface (pre-touchscreen) for configuration and wrote a DOS-based GUI from scratch. I made the buttons with rounded corners using the Turbo C++ graphics library.
Search for CN6880-4NIC10E. It has a Cavium OCTEON CN6880 32-core CPU on it with dual DDR3 interfaces. It would take some work to make it run Debian (requires running the root filesystem over NFS over PCIe or 10Gbe). All of the changes to support Linux are in the process of being pushed upstream to the Linux kernel GIT repository and hopefully sometime in the future I will get enough time to start pushing my U-Boot bootloader changes upstream as well.
All of the toolchain support is in the mainline GCC and binutils and glibc, though some of it might be in GIT since we just pushed our stuff up recently. The toolchain supports all of the extended instructions including those used for encryption and hashing.
There is a SDK but the SDK is generally quite expensive. The SDK is used for writing stand-alone applications that run on bare-metal on various cores in parallel with the Linux kernel. That way Linux runs on some cores and custom networking applications run on other cores without the overhead of a general-purpose operating system. Of course Linux could just as easily run on all the cores. It's a nice 64-bit MIPS platform as long as you don't need floating point. The CPU also has built-in acceleration for encryption, hashing, compression (deflate), pattern matching (regex) and RAID calculations (XOR/RAID6).
The PCIe bus just looks like another high-speed network interface as far as the CPU is concerned, so the card can basically be a network accelerator card for things like encryption or disk I/O. There's SDK add-ons to support things like TCP acceleration, Samba, SNORT, IPSEC and more.
I have no problem saturating 10G links, but then again I'm working on multi-core CPUs with 10-32 cores optimized for networking (the 10G interfaces are built-in to the CPU). I have a PCIe NIC card on my desk with 4 10Gbe ports on it (along with a 32-core CPU).
It's also neat when you can say you're running Linux on your NIC card (it can even run Debian).