Somehow the flurry of upcoming ARM-Cortex based netbook and MID launches this summer has escaped Slashdot crowds attention http://www.engadget.com/tag/arm Intel is gonna be so dead in this segment.
"The basics don't change. You need a vehicle to deliver a probe." Yup, its commonly called "spacecraft bus" and its indeed commonly reused design for comsats but also for some planetary orbiters. ESA Mars Express and Venus Express shared a common bus and a few other pieces for instance. However there are limits on how far you can take the commonality. For inner solar system, moderately-sized solar array works as a power system, for outer solar system it doesnt. Cooling requirements change with the distance from the sun, radiation environments change etc.
The point in learning C is to learn a systems programming language. First of all, nobody in the world fully understands C++. Second, most C++ code cannot be mapped to assembly by a human. Between objects and templates and conversions you simply have no idea what the assembly code looks like.
You want to learn languages that give you a good understanding at machine, system, application, and scripting levels. A language that does multiple is not going to work well.
Yes, i agree that nobody in the world fully understands C++. But no onereally needs to, to be productive. C++ is about being productive. Most of the really arcane aspects you can leave to white tower wizards, standard library designers, implementors of various abstraction layers and so on, and just be a happy coder using their products.
As for C++ directly mapping to assembly, it does not have to. If you understand C++ well enough, if you know your compiler well enough, and know assembly sufficiently, going to C is not going to help with anything.
( full disclosure: i work as an embedded developer across a wide range of architectures, including MCUs with a few kilobytes of ROM space, ARM, MIPS, PPC and even some exotic CPUs and "operating systems". While i need C now and then due to legacy tools or established code being in C, most of the work i do is C++ or assembler )
Ive got several devices around in my room right now, ive programmed for each and every one of them. HTC Tytn II ( Kaiser ) - 400 mhz arm9, running winMobile 6 PSP - dual MIPS cores @ 300 mhz, running uITRON NintendoDS - 66mhz ARM9 A wireless router - 300mhz BroadCom MIPS, running uCLinux A couple of bare AVR devices @ 8 - 16mhz - running straight metal code
Telling anyone to learn C these days is a serious disservice. C++ with the plethora of cross-platform abstraction layers available is suitable for development of pretty much anything anywhere, and its a way more productive language, if taught right.
And for x86.. erm.. i assume you meant assembly there but i'd say learn ARMv4 instead. You have way more options as a developer in future.
All my C# code has been mostly written in notepad. I have VS but i find it "too smart" for my tastes and i never use the RAD features ( i.e. the features that generate useful code, i never found any of it useful ) I use VS for writing C++ though, mostly because of code browsing features.
I actually do care about install time. I havent touched Win7 yet, but i know that any previous ver reinstall on my sisters home box would take me roughly a day ( install, reboot, net driver, reboot, other drivers, reboot reboot reboot , service packs, reboot, updates reboot reboot.. mundane software like archivers, pdf reader, openoffice, antivirus, antispyware, etc,.. ) Its a whole day affair.
She manages to screw the box up every few months so its not actually worth trying to fix it.
With xUbuntu's i have none of that. You get a useable system right after install, an apt-get update, upgrade and install later you are all set.
I thought the call to support Wine as a platform to be a bit retarded as well. If from the very start of development you consider multiplatform, its just easier to really write and test for multiplatform from the get-go, rather than relying on an emulator.
You have entire frameworks and languages that are multiplatform (.NET , Java ) and then for C++ you have myriad of OS abstraction toolkits for all your programming needs, from basic opsys level abstraction ( Boost, POCO etc etc ) to crossplatform UI, 3D and audio tools.
There is simply no reason why for a new project you would have to target Wine as a platform, unless you still think that MFC, ATL or COM is the greatest thing since sliced bread.
Ok, for apps that are legacy codebase paying attention to Wine might make a bit more sense, but then its perhaps easier to spend that effort not rewriting parts of your application to work with Wine, but to improve Wine to support your existing app better.
Take the beagleboard board specs as a starting point, delete the stuff ( connectors, primarily ) from schematics that you dont need, add in what you need and order your low-volume board run from Olimex or somesuch. There you go. However, if you are completely new to this, starting your electronics designer career will work out cheaper with 8-bit micros like AVR series ( see Arduino project )
All the Linux distributions are "bloated" compared with what we had several years ago.
Some more than others, but at least Linux is easy enough to pare down. First, Linux is a kernel ( and its not easy to pare it down while still having it work across variety of HW ). But i assumed you meant distros, and "easy" is really relative there. Try getting stock desktop installs of any recent mainstream distros under 1 Gigs of size, and see what i mean. There are deep dependencies between packages, esp. in desktop suites, theres lots of locale data and god knows what installed by default in many distros. Yes you can always start of with already slimmed down distro, ( yes i have built "linux from scratch" myself and done several Openembedded builds for various targets too ) but then you are off the beaten path and kinda on your own. In this case someone has just done the paring down for you, but you can get software for Win that does this as well. Warranty void, of course.
Its just easier to package everything in a bigger bloated distro to satisfy most of your customers, than try to build very smart on-demand install that would cater for everyones needs when the need arises.
Not really. The recent experience i had with that was when i went and installed all the mainstream distros under VirtualBox because i was packaging my code for most of them. Some of them come with hundreds of megabytes worth of locale data for obscure languages that i will never ever use, and default to several gigs of installation size, without ever asking if i wanted office productivity suites installed on my dev boxen or not. Figuring out and uninstalling the nonnecessary cruft is nontrivial, and often impossible because of deep dependencies between packages, especially in Gnome and KDE desktop suites.
Yes, i could go with source-based distro and spend weeks tuning everything from scratch, but what does it really give me ? A few gigs of spare disk space ? A small percentage faster load times ? Its not really worth the effort. The truth is, 98% of the "customers" dont care about the bloat per se, so from the software packagers point of view its just easier to live with it.
Kits are one thing, BOM cost is a different thing entirely. Just check the chip prices on DigiKey or Arrow. Bare OMAP35x will run you $35 at 100-quantities, the one with graphics accelerator will be $52. Whats neat about SoCs is you only have to apply power, and the thing already boots from internal flash, no other hardware needed. Add external Flash/Ram chip and you got yourself a full-fledged running system.
Why go with X86 if you want low BOM cost ? Any ARM/MIPS/PowerPC SoC with decent Mhz will do it better for lower bill of materials. Try TI OMAP35xx line for instance, one with Cortex ARM and PowerVR graphics all in one chip. Works out way cheaper than anything x86-based. Getting a Beagleboard is a good way to start. And now with Canonical throwing official support for ARM-based Ubuntu, you have got your opsys covered as well.
... maybe they dont have over 4 gigs because the most common opsys wont support it ? On my dev box i'd happily install an additional 40 gigs of memory for all the virtual machines i would like to keep open.
nothing has prevented private companies from investing in space research/travel in the past 4-5 decades.
Actually, there are documented cases of government obstructionism throughout the past decades. NASA used to launch commercial satellites on Shuttle. How can you field a commercial space launch company in an environment where you have to compete with government for scarce payloads available ? Beal Aerospace was basically forced out of the market, read their parting statement on the very webpage. AAS program was basically used to get a couple companies that were pursuing their own markets tied up with fulfilling NASA requirements, then they morphed it into something else and killed the program entirely. There are lots more examples, if you go and read the history books that arent written by "authorities"
Slashdot Mirror
Somehow the flurry of upcoming ARM-Cortex based netbook and MID launches this summer has escaped Slashdot crowds attention
http://www.engadget.com/tag/arm
Intel is gonna be so dead in this segment.
Some planes are definitely greener than some trains. See solar-flight.com, http://en.wikipedia.org/wiki/NASA_Pathfinder , http://en.wikipedia.org/wiki/QinetiQ_Zephyr
"The basics don't change. You need a vehicle to deliver a probe."
Yup, its commonly called "spacecraft bus" and its indeed commonly reused design for comsats but also for some planetary orbiters. ESA Mars Express and Venus Express shared a common bus and a few other pieces for instance.
However there are limits on how far you can take the commonality. For inner solar system, moderately-sized solar array works as a power system, for outer solar system it doesnt. Cooling requirements change with the distance from the sun, radiation environments change etc.
You dont travel much, do you ? In some parts of the world, a dollar will feed a family for a few days.
looks like it might be starting to migrate into netbooks.
Look up the recent announcement of ARM and Canonical throwing their weight behind a fully supported ARM Ubuntu version for MID-like devices.
They were supposedly launching something in march or so.
I Approve.
The point in learning C is to learn a systems programming language. First of all, nobody in the world fully understands C++. Second, most C++ code cannot be mapped to assembly by a human. Between objects and templates and conversions you simply have no idea what the assembly code looks like.
You want to learn languages that give you a good understanding at machine, system, application, and scripting levels. A language that does multiple is not going to work well.
Yes, i agree that nobody in the world fully understands C++. But no onereally needs to, to be productive. C++ is about being productive. Most of the really arcane aspects you can leave to white tower wizards, standard library designers, implementors of various abstraction layers and so on, and just be a happy coder using their products.
As for C++ directly mapping to assembly, it does not have to. If you understand C++ well enough, if you know your compiler well enough, and know assembly sufficiently, going to C is not going to help with anything.
( full disclosure: i work as an embedded developer across a wide range of architectures, including MCUs with a few kilobytes of ROM space, ARM, MIPS, PPC and even some exotic CPUs and "operating systems". While i need C now and then due to legacy tools or established code being in C, most of the work i do is C++ or assembler )
Ive got several devices around in my room right now, ive programmed for each and every one of them.
HTC Tytn II ( Kaiser ) - 400 mhz arm9, running winMobile 6
PSP - dual MIPS cores @ 300 mhz, running uITRON
NintendoDS - 66mhz ARM9
A wireless router - 300mhz BroadCom MIPS, running uCLinux
A couple of bare AVR devices @ 8 - 16mhz - running straight metal code
What were you trying to say, again ?
Telling anyone to learn C these days is a serious disservice. C++ with the plethora of cross-platform abstraction layers available is suitable for development of pretty much anything anywhere, and its a way more productive language, if taught right.
And for x86 .. erm .. i assume you meant assembly there but i'd say learn ARMv4 instead. You have way more options as a developer in future.
All my C# code has been mostly written in notepad. I have VS but i find it "too smart" for my tastes and i never use the RAD features ( i.e. the features that generate useful code, i never found any of it useful )
I use VS for writing C++ though, mostly because of code browsing features.
I actually do care about install time. I havent touched Win7 yet, but i know that any previous ver reinstall on my sisters home box would take me roughly a day ( install, reboot, net driver, reboot, other drivers, reboot reboot reboot , service packs, reboot, updates reboot reboot .. mundane software like archivers, pdf reader, openoffice, antivirus, antispyware, etc, .. )
Its a whole day affair.
She manages to screw the box up every few months so its not actually worth trying to fix it.
With xUbuntu's i have none of that. You get a useable system right after install, an apt-get update, upgrade and install later you are all set.
I thought the call to support Wine as a platform to be a bit retarded as well. If from the very start of development you consider multiplatform, its just easier to really write and test for multiplatform from the get-go, rather than relying on an emulator.
You have entire frameworks and languages that are multiplatform ( .NET , Java ) and then for C++ you have myriad of OS abstraction toolkits for all your programming needs, from basic opsys level abstraction ( Boost, POCO etc etc ) to crossplatform UI, 3D and audio tools.
There is simply no reason why for a new project you would have to target Wine as a platform, unless you still think that MFC, ATL or COM is the greatest thing since sliced bread.
Ok, for apps that are legacy codebase paying attention to Wine might make a bit more sense, but then its perhaps easier to spend that effort not rewriting parts of your application to work with Wine, but to improve Wine to support your existing app better.
Quick, someone resubmit that patent for buttocks- and toes-controlled interfaces, before Nintendo starts getting any funny ideas.
Indeed
http://www.notjustatheory.com/
Emphasis on the word "just"
"Evolution is not just a theory, it's triumphantly a theory!"
6) does not work anywhere but x86 CPUs which are going out of fashion fast :)
Take the beagleboard board specs as a starting point, delete the stuff ( connectors, primarily ) from schematics that you dont need, add in what you need and order your low-volume board run from Olimex or somesuch. There you go.
However, if you are completely new to this, starting your electronics designer career will work out cheaper with 8-bit micros like AVR series ( see Arduino project )
All the Linux distributions are "bloated" compared with what we had several years ago.
Some more than others, but at least Linux is easy enough to pare down.
First, Linux is a kernel ( and its not easy to pare it down while still having it work across variety of HW ).
But i assumed you meant distros, and "easy" is really relative there. Try getting stock desktop installs of any recent mainstream distros under 1 Gigs of size, and see what i mean. There are deep dependencies between packages, esp. in desktop suites, theres lots of locale data and god knows what installed by default in many distros.
Yes you can always start of with already slimmed down distro, ( yes i have built "linux from scratch" myself and done several Openembedded builds for various targets too ) but then you are off the beaten path and kinda on your own. In this case someone has just done the paring down for you, but you can get software for Win that does this as well. Warranty void, of course.
Its just easier to package everything in a bigger bloated distro to satisfy most of your customers, than try to build very smart on-demand install that would cater for everyones needs when the need arises.
Not really. The recent experience i had with that was when i went and installed all the mainstream distros under VirtualBox because i was packaging my code for most of them.
Some of them come with hundreds of megabytes worth of locale data for obscure languages that i will never ever use, and default to several gigs of installation size, without ever asking if i wanted office productivity suites installed on my dev boxen or not.
Figuring out and uninstalling the nonnecessary cruft is nontrivial, and often impossible because of deep dependencies between packages, especially in Gnome and KDE desktop suites.
Yes, i could go with source-based distro and spend weeks tuning everything from scratch, but what does it really give me ? A few gigs of spare disk space ? A small percentage faster load times ? Its not really worth the effort. The truth is, 98% of the "customers" dont care about the bloat per se, so from the software packagers point of view its just easier to live with it.
Kits are one thing, BOM cost is a different thing entirely. Just check the chip prices on DigiKey or Arrow. Bare OMAP35x will run you $35 at 100-quantities, the one with graphics accelerator will be $52.
Whats neat about SoCs is you only have to apply power, and the thing already boots from internal flash, no other hardware needed. Add external Flash/Ram chip and you got yourself a full-fledged running system.
Well windows runs on ARM as well .. at least in my HTC it does.
Why go with X86 if you want low BOM cost ? Any ARM/MIPS/PowerPC SoC with decent Mhz will do it better for lower bill of materials. Try TI OMAP35xx line for instance, one with Cortex ARM and PowerVR graphics all in one chip. Works out way cheaper than anything x86-based. Getting a Beagleboard is a good way to start.
And now with Canonical throwing official support for ARM-based Ubuntu, you have got your opsys covered as well.
... maybe they dont have over 4 gigs because the most common opsys wont support it ?
On my dev box i'd happily install an additional 40 gigs of memory for all the virtual machines i would like to keep open.
Ok, so why not include the full comparison here ?
nothing has prevented private companies from investing in space research/travel in the past 4-5 decades.
Actually, there are documented cases of government obstructionism throughout the past decades. NASA used to launch commercial satellites on Shuttle. How can you field a commercial space launch company in an environment where you have to compete with government for scarce payloads available ?
Beal Aerospace was basically forced out of the market, read their parting statement on the very webpage.
AAS program was basically used to get a couple companies that were pursuing their own markets tied up with fulfilling NASA requirements, then they morphed it into something else and killed the program entirely.
There are lots more examples, if you go and read the history books that arent written by "authorities"
this could have been cool to watch. poof, nothing.
Actually no. TFA says Win2K and WinXP, so at best they will get ZoneAlarm ringing or something.