I forgot to mention, that all Dell would need to do is open up some of their specs, and they would likely have somebody port Android to their device for free.
I would definitely agree that Dell could stand to make a huge benefit from adopting Android as its smartphone platform.
Why?
First of all, designing a rich-context platform such as Apple's iPhone software or Android is very tricky and, more importantly, very costly. If Dell defaults to Windows Mobile they will surely fail - it just plain sucks.
Secondly, the Android Market will likely leave the iPhone App Store in its dust due to the availability of free and open source apps, as well as paid apps. I'm sure Microsoft will offer an app store, but I already believe its too late to be successful. The options are limited. Another argument for the Android Market is, that the more developers there are working on such apps, the more popular the platform - and we have obviously seen what happens when free and open source is applied to the desktop / notebook market (i.e. the most aggressively growing OS in history).
Dell should join the OHA, in my opinion, if they want to enter the mobile market.
TomTom is a much smaller company than Microsoft. It isn't likely that they would launch a patent strike against Microsoft..., a company with a much bigger portfolio and more cash.
I wonder if the above comment could be counted as reasonable legal evidence arguing that the US Patent System is corrupt (conventional "wisdom").
In spite of the irony, I wouldn't be surprised if someone already holds a patented business process on judging a patent lawsuit based on who has more money and more expensive lawyers. Throw in bribes and there you have a quasi-functional, feedback-business-control system!
Though I believe that software and business process patents should only exist in Neverland, I still hope that TomTom would win the case if they already had a patent on the "device" in question, regardless of whether they are a company with more or less capital. I assume that the invention was non-obvious at the time the patent and lawsuits were filed, of course, which may not be the case today.
That is definitely not the case with the FAT filesystem.
Has MicroSoft done anything innovative since MS Office?
If you foresee needing to periodically update the firmware to along with a library or app, then I would say a definitive YES - use the 2.6 kernel (assuming your device is supported).
It might also be the case that the board you would like to use is not supported in the 2.4 kernel if it's new enough - kernel developers usually don't want to waste time backporting their code if they can avoid it.
Which introduces the most important issue - backporting is a PITA!! To make a long story short, if you need to track a library or app, such as an embedded JRE, or a hardware interface that requires a kernel module inserted, playing catchup and needing to backport at the same time is an awful game of one-step-forward two-steps-back. Avoid it at all costs. Backporting is not always guaranteed to work!
The 2.4 kernel has a slightly faster boot time, while the 2.6 kernel has so many improvements that it's hard to shy away from. Do yourself a favour and go with a stable 2.6 kernel.
Hide mutexes and locks at (nearly) all costs. If you have a queue class, for example, that has a locking push() function, and someone needs to lock for a series of pushes, don't expose the lock to let them lock things for the series of pushes, but provide a push function that takes a list of items instead. Keep thinking of ways to hide your locking strategies. If your class is deadlock-free then you can be reasonably sure (I've always said "reasonably" but I've never seen it not work either) that you'll never see a deadlock in real life either. Race conditions are a different story, however.
I believe that following strict OO guidelines is even more important when dealing with concurrency than when dealing with general ideas in software... and let's face it, it's extremely important even when not dealing with concurrency:)
I would have to agree that it's best to hide your locking strategies. However, one can easily get lost in mutex-hell by over-doing it and assigning too many mutexes to a single object. Consider how the OO paradigm provides data encapsulation, and apply it to parallel programming. In many cases, all that you would want is a single, per-object lock (very much like the java paradigm). You can actually hide your checks for race conditions inside of your object itself.
Also, keep in mind that polling wastes CPU cycles. Having a well-thought-out 'protocol' between objects will assist you in using notify() and wait() methods efficiently. This was part of the reason for the creation of CORBA, COM and the like.
For your average programmer, the problem of parallel computing has really only started to appear very recently because of the mass-production of multi-core chips. However, electronics and computer engineers have been playing this game for a while. With that in mind, it's often useful to visual object-oriented-code as the behavioral description of a functional block inside of an FPGA or other reprogrammable circuit. That way, you can think of wires (or buffers) as variables, and events being 'rising edges' (look into SystemC). You can even go so far as to have a global event queue. Personally, I like to do parallel, object-oriented programming using typical state machine structures.
Auto manufacturers would probably be just as happy with hybrids going mainstream as they were with fossil-fueled vehicles. Why ? Because they make a heck of a lot of money selling replacement parts.
Hybrids have very little differences in maintenance costs, and are potentially more expensive to maintain, when compared to fossil-fueled vehicles.
On the other hand, a fully electric vehicle requires relatively 10 % of the maintenance cost, and that equates to rotating the tires and checking the brakes. In the (very rare) case that the AC motor in an electric vehicle needs to be replaced the cost-per-visit peaks and then goes right back down.
Now when you say that the economy is the basis for (common-commuters) not switching to electric vehicles, that's just stupid - there are many, many jobs to be gained, trades to learn, dollars to be made, etc, with the adoption of electric vehicles for the commoner. Don't forget that there will still be a need for heavy-trucks and other work vehicles to run on fossil-fuels.
If you really want to flame someone, flame the pre-baby-boomer urban planners that decided to turn North America into a white-picket-fenced suburban wasteland. If that hadn't happened then 90% of people wouldn't even need to drive a car, let alone take public transportation.
In many older cities (I live in Montreal), riding a bicycle is still incredibly faster than driving a car.
[shameless plug]
Incidentally, the ZENN is now fully legal to drive in most of Canada - it's launch date was just this weekend and it sells brand new for 16900 CAD. I believe that there is also a gov't tax credit upon purchase, not to mention the drastically reduced annual maintenance. I'm mostly looking forward to the CityZENN. Canadians - It's not too late to change your vote to Green!!
[\shameless plug]
As far as the WRT54G[L] goes, the default linksys firmware as well as the default ddwrt firmware (as far as I can remember) both have an unreasonably low maximum number of file descriptors allowed at once.
For P2P transfers, for example, which use hundreds of file descriptors at once, a limit of, say, 50 maximum file descriptors would make the embedded linux kernel freeze.
The solution was to simply up that number to something more reasonable, like 500.
After I did that, I never had a problem again with my Linksys WRT54GL.
I think both the Samsung and Super Talent SDDs are over-priced. For those that are in the market today for a solid-state-drive (mainly laptop owners), they will likely care the most about 2 things - power consumption, and weight, and any SDD will outperform a magnetic disk in those categories.
I would recommend 32 GB 2.5" SATA SDD from Transcend at 1/3 of the cost of the 64 GB Samsung model.
Aside from that, and especially if gigabytes are not the highest priority, there are also excellent, and much cheaper solutions for those who are willing to take the time to play around, such as this CF / IDE adapter from Addonics.
Last, but not least, if it isn't already obvious, solid state disks only have a limited lifespan, and it's usually much shorter than the lifespan quoted by the manufacturer, unless they came up with a new, super-advanced wear-leveling algorithm. Never estimate the value of making periodic backups to a more reliable permanent storage facility!
Slashdot Mirror
I forgot to mention, that all Dell would need to do is open up some of their specs, and they would likely have somebody port Android to their device for free.
I would definitely agree that Dell could stand to make a huge benefit from adopting Android as its smartphone platform.
Why?
First of all, designing a rich-context platform such as Apple's iPhone software or Android is very tricky and, more importantly, very costly. If Dell defaults to Windows Mobile they will surely fail - it just plain sucks.
Secondly, the Android Market will likely leave the iPhone App Store in its dust due to the availability of free and open source apps, as well as paid apps. I'm sure Microsoft will offer an app store, but I already believe its too late to be successful. The options are limited. Another argument for the Android Market is, that the more developers there are working on such apps, the more popular the platform - and we have obviously seen what happens when free and open source is applied to the desktop / notebook market (i.e. the most aggressively growing OS in history).
Dell should join the OHA, in my opinion, if they want to enter the mobile market.
TomTom is a much smaller company than Microsoft. It isn't likely that they would launch a patent strike against Microsoft..., a company with a much bigger portfolio and more cash.
I wonder if the above comment could be counted as reasonable legal evidence arguing that the US Patent System is corrupt (conventional "wisdom").
In spite of the irony, I wouldn't be surprised if someone already holds a patented business process on judging a patent lawsuit based on who has more money and more expensive lawyers. Throw in bribes and there you have a quasi-functional, feedback-business-control system!
Though I believe that software and business process patents should only exist in Neverland, I still hope that TomTom would win the case if they already had a patent on the "device" in question, regardless of whether they are a company with more or less capital. I assume that the invention was non-obvious at the time the patent and lawsuits were filed, of course, which may not be the case today.
That is definitely not the case with the FAT filesystem.
Has MicroSoft done anything innovative since MS Office?
If you foresee needing to periodically update the firmware to along with a library or app, then I would say a definitive YES - use the 2.6 kernel (assuming your device is supported).
It might also be the case that the board you would like to use is not supported in the 2.4 kernel if it's new enough - kernel developers usually don't want to waste time backporting their code if they can avoid it.
Which introduces the most important issue - backporting is a PITA!! To make a long story short, if you need to track a library or app, such as an embedded JRE, or a hardware interface that requires a kernel module inserted, playing catchup and needing to backport at the same time is an awful game of one-step-forward two-steps-back. Avoid it at all costs. Backporting is not always guaranteed to work!
The 2.4 kernel has a slightly faster boot time, while the 2.6 kernel has so many improvements that it's hard to shy away from. Do yourself a favour and go with a stable 2.6 kernel.
I believe that following strict OO guidelines is even more important when dealing with concurrency than when dealing with general ideas in software... and let's face it, it's extremely important even when not dealing with concurrency :)
I would have to agree that it's best to hide your locking strategies. However, one can easily get lost in mutex-hell by over-doing it and assigning too many mutexes to a single object. Consider how the OO paradigm provides data encapsulation, and apply it to parallel programming. In many cases, all that you would want is a single, per-object lock (very much like the java paradigm). You can actually hide your checks for race conditions inside of your object itself.
Also, keep in mind that polling wastes CPU cycles. Having a well-thought-out 'protocol' between objects will assist you in using notify() and wait() methods efficiently. This was part of the reason for the creation of CORBA, COM and the like.
For your average programmer, the problem of parallel computing has really only started to appear very recently because of the mass-production of multi-core chips. However, electronics and computer engineers have been playing this game for a while. With that in mind, it's often useful to visual object-oriented-code as the behavioral description of a functional block inside of an FPGA or other reprogrammable circuit. That way, you can think of wires (or buffers) as variables, and events being 'rising edges' (look into SystemC). You can even go so far as to have a global event queue. Personally, I like to do parallel, object-oriented programming using typical state machine structures.
Auto manufacturers would probably be just as happy with hybrids going mainstream as they were with fossil-fueled vehicles. Why ? Because they make a heck of a lot of money selling replacement parts.
Hybrids have very little differences in maintenance costs, and are potentially more expensive to maintain, when compared to fossil-fueled vehicles.
On the other hand, a fully electric vehicle requires relatively 10 % of the maintenance cost, and that equates to rotating the tires and checking the brakes. In the (very rare) case that the AC motor in an electric vehicle needs to be replaced the cost-per-visit peaks and then goes right back down.
Now when you say that the economy is the basis for (common-commuters) not switching to electric vehicles, that's just stupid - there are many, many jobs to be gained, trades to learn, dollars to be made, etc, with the adoption of electric vehicles for the commoner. Don't forget that there will still be a need for heavy-trucks and other work vehicles to run on fossil-fuels.
If you really want to flame someone, flame the pre-baby-boomer urban planners that decided to turn North America into a white-picket-fenced suburban wasteland. If that hadn't happened then 90% of people wouldn't even need to drive a car, let alone take public transportation.
In many older cities (I live in Montreal), riding a bicycle is still incredibly faster than driving a car.
[shameless plug]
Incidentally, the ZENN is now fully legal to drive in most of Canada - it's launch date was just this weekend and it sells brand new for 16900 CAD. I believe that there is also a gov't tax credit upon purchase, not to mention the drastically reduced annual maintenance. I'm mostly looking forward to the CityZENN. Canadians - It's not too late to change your vote to Green!! [\shameless plug]
As far as the WRT54G[L] goes, the default linksys firmware as well as the default ddwrt firmware (as far as I can remember) both have an unreasonably low maximum number of file descriptors allowed at once. For P2P transfers, for example, which use hundreds of file descriptors at once, a limit of, say, 50 maximum file descriptors would make the embedded linux kernel freeze. The solution was to simply up that number to something more reasonable, like 500. After I did that, I never had a problem again with my Linksys WRT54GL.
It also has about 1/5th the user base of XP, no?
I think both the Samsung and Super Talent SDDs are over-priced. For those that are in the market today for a solid-state-drive (mainly laptop owners), they will likely care the most about 2 things - power consumption, and weight, and any SDD will outperform a magnetic disk in those categories. I would recommend 32 GB 2.5" SATA SDD from Transcend at 1/3 of the cost of the 64 GB Samsung model. Aside from that, and especially if gigabytes are not the highest priority, there are also excellent, and much cheaper solutions for those who are willing to take the time to play around, such as this CF / IDE adapter from Addonics. Last, but not least, if it isn't already obvious, solid state disks only have a limited lifespan, and it's usually much shorter than the lifespan quoted by the manufacturer, unless they came up with a new, super-advanced wear-leveling algorithm. Never estimate the value of making periodic backups to a more reliable permanent storage facility!