There are plenty of inexpensive 32-bit embedded processors out there and even 64-bit ones, many with built-in Ethernet and I/O support that require few external components. Many also run Linux quite well.
There are numerous PowerQuicc (Power PC variants), MIPS, ARM and other processors out there which will work just fine. Many even have things like hardware encryption support and support multiple cores or threads.
For things like POS systems there's generally little reason to be stuck with 8-bit processors any more since 32-bit ones are now fairly inexpensive. For $30 you can get a nice embedded processor that supports Ethernet, serial, PCI-E, generic I/O and more without requiring a separate bridge chip.
The problem is that the ebook readers don't like page formatted documents because they need to resize them to fit their screens and the font size selected. PDFs are crappy for this. I believe Amazon accepts other formats like doc and will convert them. If your book requires specific page formatting then it doesn't lend itself to most ebook readers.
I have switched to Chrome on my netbook rather than use Firefox. Although I miss some of the Firefox add-ons like ad-block, autopager, etc. I find Chrome much more efficient in terms of screen real-estate and to be faster. I wish other applications would take the approach to allow smaller widgets to better use screen real-estate.
Actually, my mistake about series/parallel. Though from my experience with my Prius is that it will often switch to parallel mode when driving in the city as long as there's not much acceleration, the speed is kept below 42 MPH, the engine is warm and the battery is well charged. When it switches in and out of this mode with city driving the efficiency goes way up compared to pure parallel mode. It tends to do this less often in cold weather and when the engine is cold, though, for emissions reasons. The most efficient range for most ICEs is to run around 40% output. By doing this it will tend to use the extra power not needed for forward motion to charge the battery from my experience. When the battery reaches a certain point it will tend to switch to series mode again.
At higher speeds and on the freeway, however, it opts for parallel mode since the savings is less.
I believe the 2010 model will use series mode at higher speeds than the earlier models. The 42MPH limit is because Toyota limits the speed of MG1.
You have the series and parallel confused. A series car typically has the electric motor inline with the engine to provide boost. This is how the original Honda Insight and hybrid Civic work. A parallel hybrid like Toyota's Prius and the Ford Escape can run on any combination of electric and gasoline. It uses a planetary gear assembly with the gasoline engine driving the planets. The sun gear goes to a generator/alternator (that can also be a motor) and the outer ring goes to the wheels and another electric motor. The CVT is basically just how it shunts power between the two motors. Mechanically it's fairly simple. If the gasoline engine dies it can use the electric motors to power itself. If an electric motor dies the car won't move.
I don't really worry about earthquakes until they start getting above 5, and even then it's no biggie around here. We have those every few years around here and there's rarely much damage since most of the buildings are designed to withstand far greater earthquakes. A 3.6 is nothing around here, and most of us have already experienced a number of quakes larger than that. California has done a lot to retrofit and upgrade older buildings and infrastructure especially after the Northridge and Loma Prieta earthquakes. Where other areas of the world consider a 5.6 to be major we consider it fairly common and no big deal.
One thing to keep in mind is that the cost of batteries will drop significantly as they mature and their life will be extended further as new technologies make it to market.
There is already one successful car manufacturing plant in Silicon Valley. The NUMMI plant is a joint venture between Toyota and GM though I think it is now mostly Toyota. There is talk of Toyota starting to manufacture the Prius at this plant.
It's also a great location if you need people experienced with electronics and software, plus all of the designers are also local. Labour is not the biggest cost in manufacturing a car and even then I'm not sure that labour would be that much more than elsewhere in the country.
I know the city of San Jose as well as the state have been offering all sorts of incentives to build their manufacturing plant there.
There are many successful companies in California. Also, the largest percentage of their customers will be from California just by the state's population, and Silicon Valley is full of geeks who will embrace the technology and buy their cars.
I know a couple of people who work at Tesla. Their goal is to bring the prices down. Right now the most expensive part is the batteries, and the price of batteries is dropping. They can't just use laptop batteries since the batteries must meet specific requirements for reliability and performance. Their manufacturing cost is also fairly high, especially for the roadster. The costs will go down for the new car since they can apply what they learned from the roadster to the manufacturing and design of the new car plus they will have their own manufacturing plant, but their cost will still be fairly high. The price dropping from $100K to $60K is fairly significant. I imagine their price will continue to drop as they mature and get more experience and when the cost of the batteries drops.
If you're going to spend a lot of money on a car you generally expect it to have all the cool gizmos and options, hence the luxury model. Costs will continue to go down as they improve their design and manufacturing and as the cost for batteries decreases. They also have a lot of NRE to recover. They're basically making a brand new car from the ground up with significant changes from the roadster.
I can't imagine that all the luxury features and options add a significant amount to the cost of the car, probably no more than 25% of the cost of the car.
I have the Verizon network extender because inside my house gets very poor cell phone reception, likely due to the metal roof and chicken wire in the stucco walls. It actually works quite well. It's main drawbacks are that it requires a GPS antenna to be hooked up and it does not handle EVDO.
It gives priority to the phone numbers I specify and only supports other phones when there is no other signal. It can support up to 3 simultaneous phone calls and reserves a fourth for 911. So far it has been working beautifully. My phone doesn't go dead in a matter of hours and I'm no longer missing or dropping calls.
The $250 was rather steep (they provided a $50 refund due to the poor coverage in my home), but at least now I have reliable cell coverage inside my house.
The article is fairly clear on why the latency is better with OSS vs ALSA. ALSA does audio mixing in user space before passing the mixed audio to the kernel. OSS, on the other hand, does everything in kernel space including audio mixing and even resampling. Since the audio is only processed in the kernel the latency can be much lower. With ALSA audio must be buffered in user space for mixing then buffered again in the kernel for the hardware. OSS eliminates this problem by doing it all inside the kernel.
ALSA only supports kernel-based audio mixing if the sound card supports it which most on-board sound cards do not. OSS also takes advantage of hardware audio mixing when the hardware supports it but also performs software mixing in the kernel when not supported.
Mixing between multiple applications in user space can add quite a bit of latency.
As for better audio quality, I have had issues with stuttering and other problems with ALSA under high load conditions, in part due to the user space processing. Also, as the article states, OSS uses more accurate algorithms for audio mixing than ALSA does (and you can select quality vs CPU in OSS).
I agree. I think it has more to do with some kernel developers who refuse to consider OSS after OSS3.
The OSS kernel interface is simple and the audio mixing is performed in the kernel (if needed) where it should be. All an app needs to do is open/dev/dsp and perform a few ioctl calls and they're ready to go. They don't need to care whether some other application is also playing audio or not.
It's much cleaner than ALSA, which is a mess IMO. I've had a lot of problems with ALSA until I finally dumped it for OSS4 which solved the constant clicking, stuttering and lack of audio mixing. ALSA would often need to be restarted and it finally got to the point after a kernel upgrade where ALSA just plain refused to work at all.
With OSS I can basically choose the format of the audio, the sample rate and the volume and just set it and go. If the hardware doesn't support multi-stream mixing and volume then OSS does it in software. Similarly, if the hardware doesn't support the sample rate (i.e. 44100) then OSS will resample it to match the hardware, thus abstracting the hardware from the software, which is the way it should be.
Over the years I had a lot of prolbems with ALSA, the biggest being the lack of sound mixing with the sound card on my motherboard. To get around it, I went out and bought a different sound card that supported hardware mixing. I still had problems where ALSA would just break periodically and require restarting it. Then at one point it just plain broke and nothing would fix it.
I had enough and installed OSS. What a difference. Latency is better and it just works. There is no excuse to not providing consistent audio mixing. I should have switched to OSS in the beginning rather than buy an expensive sound card because ALSA couldn't do software mixing.
A sound API should provide sufficient abstraction so that basic operations do not depend on the underlying hardware. Mixing, sample rate conversion (when needed) and per-application volume settings fall under basic operation as far as I'm concerned.
My mail server (Postfix) actually takes advantage of this. I have it configured to tarpit known spam sources (from RBL) and hold the connections open without sending a response.
Basically to generate 30KWH of power requires about 41HP. In this case, the power would come from the car pressing down on the plate, but the car must then use additional power to climb off of the plate. Cars are far less efficient at generating power than a dedicated power plant (ICE is at best around 24% efficient not counting losses due to the drive train, a power plant is typically over 40% efficient).
Given that Wind River supports a wide variety of embedded chips from many vendors other than Intel I wonder what sort of impact this will have, especially since Wind River also supports VxWorks which is used on many embedded devices.
The last two companies I worked at had a policy where everything would be thrown out on Sunday unless it's something frozen in the freezer or something sealed like a can of soda.
I remember using it for things like that as well. I also remember my father got an EPROM programmer that was hard wired to use the same port as his graphics card and it was hard coded into the DOS program. A bit of work with a soldering iron changed the port but I had to go in via debug and patch the program to use the new port. I also used it back in the day to dump BIOS or to write to specific I/O ports and memory locations to experiment with different things.
Back in the DOS 2.1 days when I got my first computer I didn't have any manuals. I quickly found debug, though, and saw all the strings in command.com. A bit later I actually used it for things like disassembling the boot sector and even writing some tiny programs via machine code since Microsoft's assembler and linker costs a fortune at the time and I was in junior high and beginning high school. I even used it to crack a number of programs via the disassembler command. There was also an improved version of debug I managed to get a hold of called symdeb.
When I got the Borland (RIP) Turbo Assembler and their debugger I stopped using it.
I haven't touched it in many years, especially since I moved away from Windows in the early 1990s, migrating first to OS/2 and later to Linux.
I have fond memories of writing code in the 1980s using Turbo Pascal 3.0. The entire compiler and editor fit in 48K and the run-time library was only 12K. Granted it was stuck creating.com files with a 64K limit but it's amazing what could be done at the time with so little memory. Hell, just sed on my Linux box is 56K, and that doesn't include the libc shared run-time library. I remember an add-on patch that also added an integrated debugger as well.
I then moved on to Turbo C and later releases of Turbo Pascal which were still speed demons compared to the alternatives out there, and TASM ran circles around MASM with far fewer bugs.
I continued to use Borland C++ for several years while I worked as a summer intern in the early 1990s for writing DOS TSR applications for a laptop manufacturer. I had switched a number of their assembly projects from MASM to TASM as well since it was a lot better. TASM would catch a lot more errors and would report much more meaningful information than MASM, plus TASM was also a lot faster.
I remember when they came out with the Windows versions how Borland ran into trouble with Microsoft because when Borland wanted to support MFC Microsoft said they had to drop their OWL library, which was in many ways superior to MFC in order to license MFC.
Mountain View is not that wet, getting on average around 15 inches of rain per year. While I can't find Mountain View, Sunnyvale isn't that far away.
Most of the weeds and grass grow during the winter and spring then the grass dries out and turns brown during the summer and fall, since it rarely rains between June and October.
They used to bring in goats from time to time to mow the grass in a park next to the last place I worked, which was fairly successful, especially since the goats could easily reach many places too small for the mower to get to or with a lot of rocks.
XFS has a number of features that ext3 is missing. For example, one can easily defragment a mounted XFS filesystem. It's also much more resistant to fragmentation due to the late allocation strategy. xfsdump allows one to easily back up the filesystem and all of the metadata, including incremental backup support. I've used this to replicate an xfs filesystem via netcat when migrating to a new server.
A mounted XFS volume can also be increased on the fly.
XFS is able to scale to much larger partition sizes than ext2/3 (which maxes out at around 8TB with 4K blocks). fsck runs much faster as well. I go and take a coffee break when ext3 decides its time to run its periodic fsck run. ext3 also supports a maximum file size of 2TB and has a limit of around 32K subdirectories per directory. XFS does not have these limitations.
In addition to this, the iCar will not have a hood that opens and the battery compartment will be sealed in a polished titanium compartment. There will be no wheels since they take away from the sleek look. You will shake the car to start it. There will be a hidden reset button behind the rear bumper for those times when the software crashes and needs to reboot. In the case that something breaks you just tow it to the nearest Apple store, though the lack of wheels makes this quite difficult. People will flock to buy these cars, even when it turns out that they can't go anywhere except on AT&T's road network. After a year AT&T will replace Road Network (tm) with Road Network 2 which is not backwards compatible, requiring owners of iCar 1.0 to buy an iCar 2.0 which will finally offer GPS iLost technology and the ability to go over 25MPh. The drawback will be that in the new 3G speed mode you can only travel 3 blocks before needing to recharge.
Slashdot Mirror
There are plenty of inexpensive 32-bit embedded processors out there and even 64-bit ones, many with built-in Ethernet and I/O support that require few external components. Many also run Linux quite well.
There are numerous PowerQuicc (Power PC variants), MIPS, ARM and other processors out there which will work just fine. Many even have things like hardware encryption support and support multiple cores or threads.
For things like POS systems there's generally little reason to be stuck with 8-bit processors any more since 32-bit ones are now fairly inexpensive. For $30 you can get a nice embedded processor that supports Ethernet, serial, PCI-E, generic I/O and more without requiring a separate bridge chip.
-Aaron
The problem is that the ebook readers don't like page formatted documents because they need to resize them to fit their screens and the font size selected. PDFs are crappy for this. I believe Amazon accepts other formats like doc and will convert them. If your book requires specific page formatting then it doesn't lend itself to most ebook readers.
I have switched to Chrome on my netbook rather than use Firefox. Although I miss some of the Firefox add-ons like ad-block, autopager, etc. I find Chrome much more efficient in terms of screen real-estate and to be faster. I wish other applications would take the approach to allow smaller widgets to better use screen real-estate.
Actually, my mistake about series/parallel. Though from my experience with my Prius is that it will often switch to parallel mode when driving in the city as long as there's not much acceleration, the speed is kept below 42 MPH, the engine is warm and the battery is well charged. When it switches in and out of this mode with city driving the efficiency goes way up compared to pure parallel mode. It tends to do this less often in cold weather and when the engine is cold, though, for emissions reasons. The most efficient range for most ICEs is to run around 40% output. By doing this it will tend to use the extra power not needed for forward motion to charge the battery from my experience. When the battery reaches a certain point it will tend to switch to series mode again.
At higher speeds and on the freeway, however, it opts for parallel mode since the savings is less.
I believe the 2010 model will use series mode at higher speeds than the earlier models. The 42MPH limit is because Toyota limits the speed of MG1.
You have the series and parallel confused. A series car typically has the electric motor inline with the engine to provide boost. This is how the original Honda Insight and hybrid Civic work. A parallel hybrid like Toyota's Prius and the Ford Escape can run on any combination of electric and gasoline. It uses a planetary gear assembly with the gasoline engine driving the planets. The sun gear goes to a generator/alternator (that can also be a motor) and the outer ring goes to the wheels and another electric motor. The CVT is basically just how it shunts power between the two motors. Mechanically it's fairly simple. If the gasoline engine dies it can use the electric motors to power itself. If an electric motor dies the car won't move.
http://en.wikipedia.org/wiki/Hybrid_Synergy_Drive
I don't really worry about earthquakes until they start getting above 5, and even then it's no biggie around here. We have those every few years around here and there's rarely much damage since most of the buildings are designed to withstand far greater earthquakes. A 3.6 is nothing around here, and most of us have already experienced a number of quakes larger than that. California has done a lot to retrofit and upgrade older buildings and infrastructure especially after the Northridge and Loma Prieta earthquakes. Where other areas of the world consider a 5.6 to be major we consider it fairly common and no big deal.
One thing to keep in mind is that the cost of batteries will drop significantly as they mature and their life will be extended further as new technologies make it to market.
There is already one successful car manufacturing plant in Silicon Valley. The NUMMI plant is a joint venture between Toyota and GM though I think it is now mostly Toyota. There is talk of Toyota starting to manufacture the Prius at this plant.
It's also a great location if you need people experienced with electronics and software, plus all of the designers are also local. Labour is not the biggest cost in manufacturing a car and even then I'm not sure that labour would be that much more than elsewhere in the country.
I know the city of San Jose as well as the state have been offering all sorts of incentives to build their manufacturing plant there.
There are many successful companies in California. Also, the largest percentage of their customers will be from California just by the state's population, and Silicon Valley is full of geeks who will embrace the technology and buy their cars.
I know a couple of people who work at Tesla. Their goal is to bring the prices down. Right now the most expensive part is the batteries, and the price of batteries is dropping. They can't just use laptop batteries since the batteries must meet specific requirements for reliability and performance. Their manufacturing cost is also fairly high, especially for the roadster. The costs will go down for the new car since they can apply what they learned from the roadster to the manufacturing and design of the new car plus they will have their own manufacturing plant, but their cost will still be fairly high. The price dropping from $100K to $60K is fairly significant. I imagine their price will continue to drop as they mature and get more experience and when the cost of the batteries drops.
If you're going to spend a lot of money on a car you generally expect it to have all the cool gizmos and options, hence the luxury model. Costs will continue to go down as they improve their design and manufacturing and as the cost for batteries decreases. They also have a lot of NRE to recover. They're basically making a brand new car from the ground up with significant changes from the roadster.
I can't imagine that all the luxury features and options add a significant amount to the cost of the car, probably no more than 25% of the cost of the car.
I have the Verizon network extender because inside my house gets very poor cell phone reception, likely due to the metal roof and chicken wire in the stucco walls. It actually works quite well. It's main drawbacks are that it requires a GPS antenna to be hooked up and it does not handle EVDO.
It gives priority to the phone numbers I specify and only supports other phones when there is no other signal. It can support up to 3 simultaneous phone calls and reserves a fourth for 911. So far it has been working beautifully. My phone doesn't go dead in a matter of hours and I'm no longer missing or dropping calls.
The $250 was rather steep (they provided a $50 refund due to the poor coverage in my home), but at least now I have reliable cell coverage inside my house.
The article is fairly clear on why the latency is better with OSS vs ALSA. ALSA does audio mixing in user space before passing the mixed audio to the kernel. OSS, on the other hand, does everything in kernel space including audio mixing and even resampling. Since the audio is only processed in the kernel the latency can be much lower. With ALSA audio must be buffered in user space for mixing then buffered again in the kernel for the hardware. OSS eliminates this problem by doing it all inside the kernel.
ALSA only supports kernel-based audio mixing if the sound card supports it which most on-board sound cards do not. OSS also takes advantage of hardware audio mixing when the hardware supports it but also performs software mixing in the kernel when not supported.
Mixing between multiple applications in user space can add quite a bit of latency.
As for better audio quality, I have had issues with stuttering and other problems with ALSA under high load conditions, in part due to the user space processing. Also, as the article states, OSS uses more accurate algorithms for audio mixing than ALSA does (and you can select quality vs CPU in OSS).
I agree. I think it has more to do with some kernel developers who refuse to consider OSS after OSS3.
The OSS kernel interface is simple and the audio mixing is performed in the kernel (if needed) where it should be. All an app needs to do is open /dev/dsp and perform a few ioctl calls and they're ready to go. They don't need to care whether some other application is also playing audio or not.
It's much cleaner than ALSA, which is a mess IMO. I've had a lot of problems with ALSA until I finally dumped it for OSS4 which solved the constant clicking, stuttering and lack of audio mixing. ALSA would often need to be restarted and it finally got to the point after a kernel upgrade where ALSA just plain refused to work at all.
With OSS I can basically choose the format of the audio, the sample rate and the volume and just set it and go. If the hardware doesn't support multi-stream mixing and volume then OSS does it in software. Similarly, if the hardware doesn't support the sample rate (i.e. 44100) then OSS will resample it to match the hardware, thus abstracting the hardware from the software, which is the way it should be.
Over the years I had a lot of prolbems with ALSA, the biggest being the lack of sound mixing with the sound card on my motherboard. To get around it, I went out and bought a different sound card that supported hardware mixing. I still had problems where ALSA would just break periodically and require restarting it. Then at one point it just plain broke and nothing would fix it.
I had enough and installed OSS. What a difference. Latency is better and it just works. There is no excuse to not providing consistent audio mixing. I should have switched to OSS in the beginning rather than buy an expensive sound card because ALSA couldn't do software mixing.
A sound API should provide sufficient abstraction so that basic operations do not depend on the underlying hardware. Mixing, sample rate conversion (when needed) and per-application volume settings fall under basic operation as far as I'm concerned.
My mail server (Postfix) actually takes advantage of this. I have it configured to tarpit known spam sources (from RBL) and hold the connections open without sending a response.
Basically to generate 30KWH of power requires about 41HP. In this case, the power would come from the car pressing down on the plate, but the car must then use additional power to climb off of the plate. Cars are far less efficient at generating power than a dedicated power plant (ICE is at best around 24% efficient not counting losses due to the drive train, a power plant is typically over 40% efficient).
Given that Wind River supports a wide variety of embedded chips from many vendors other than Intel I wonder what sort of impact this will have, especially since Wind River also supports VxWorks which is used on many embedded devices.
The last two companies I worked at had a policy where everything would be thrown out on Sunday unless it's something frozen in the freezer or something sealed like a can of soda.
The policy seems to work quite well.
I urge people who do a lot of photography to print this out and keep it with them. It is a page that details the rights of photographers.
It can be found at http://www.krages.com/phoright.htm.
I remember using it for things like that as well. I also remember my father got an EPROM programmer that was hard wired to use the same port as his graphics card and it was hard coded into the DOS program. A bit of work with a soldering iron changed the port but I had to go in via debug and patch the program to use the new port. I also used it back in the day to dump BIOS or to write to specific I/O ports and memory locations to experiment with different things.
Back in the DOS 2.1 days when I got my first computer I didn't have any manuals. I quickly found debug, though, and saw all the strings in command.com. A bit later I actually used it for things like disassembling the boot sector and even writing some tiny programs via machine code since Microsoft's assembler and linker costs a fortune at the time and I was in junior high and beginning high school. I even used it to crack a number of programs via the disassembler command. There was also an improved version of debug I managed to get a hold of called symdeb.
When I got the Borland (RIP) Turbo Assembler and their debugger I stopped using it.
I haven't touched it in many years, especially since I moved away from Windows in the early 1990s, migrating first to OS/2 and later to Linux.
I have fond memories of writing code in the 1980s using Turbo Pascal 3.0. The entire compiler and editor fit in 48K and the run-time library was only 12K. Granted it was stuck creating .com files with a 64K limit but it's amazing what could be done at the time with so little memory. Hell, just sed on my Linux box is 56K, and that doesn't include the libc shared run-time library. I remember an add-on patch that also added an integrated debugger as well.
I then moved on to Turbo C and later releases of Turbo Pascal which were still speed demons compared to the alternatives out there, and TASM ran circles around MASM with far fewer bugs.
I continued to use Borland C++ for several years while I worked as a summer intern in the early 1990s for writing DOS TSR applications for a laptop manufacturer. I had switched a number of their assembly projects from MASM to TASM as well since it was a lot better. TASM would catch a lot more errors and would report much more meaningful information than MASM, plus TASM was also a lot faster.
I remember when they came out with the Windows versions how Borland ran into trouble with Microsoft because when Borland wanted to support MFC Microsoft said they had to drop their OWL library, which was in many ways superior to MFC in order to license MFC.
Mountain View is not that wet, getting on average around 15 inches of rain per year. While I can't find Mountain View, Sunnyvale isn't that far away.
Most of the weeds and grass grow during the winter and spring then the grass dries out and turns brown during the summer and fall, since it rarely rains between June and October.
They used to bring in goats from time to time to mow the grass in a park next to the last place I worked, which was fairly successful, especially since the goats could easily reach many places too small for the mower to get to or with a lot of rocks.
I have a T61 and it has an integrated camera. I don't know if it's available without one though.
XFS has a number of features that ext3 is missing. For example, one can easily defragment a mounted XFS filesystem. It's also much more resistant to fragmentation due to the late allocation strategy. xfsdump allows one to easily back up the filesystem and all of the metadata, including incremental backup support. I've used this to replicate an xfs filesystem via netcat when migrating to a new server.
A mounted XFS volume can also be increased on the fly.
XFS is able to scale to much larger partition sizes than ext2/3 (which maxes out at around 8TB with 4K blocks). fsck runs much faster as well. I go and take a coffee break when ext3 decides its time to run its periodic fsck run. ext3 also supports a maximum file size of 2TB and has a limit of around 32K subdirectories per directory. XFS does not have these limitations.
In addition to this, the iCar will not have a hood that opens and the battery compartment will be sealed in a polished titanium compartment. There will be no wheels since they take away from the sleek look. You will shake the car to start it. There will be a hidden reset button behind the rear bumper for those times when the software crashes and needs to reboot. In the case that something breaks you just tow it to the nearest Apple store, though the lack of wheels makes this quite difficult. People will flock to buy these cars, even when it turns out that they can't go anywhere except on AT&T's road network. After a year AT&T will replace Road Network (tm) with Road Network 2 which is not backwards compatible, requiring owners of iCar 1.0 to buy an iCar 2.0 which will finally offer GPS iLost technology and the ability to go over 25MPh. The drawback will be that in the new 3G speed mode you can only travel 3 blocks before needing to recharge.