i've mentioned this before, and it's worth mentioning again: the p2p-dns project's goals appear to be to create a separate ".p2p" top-level domain rather than to provide a complete distributed DNS replacement. that's just simply not ambitious or useful enough. we need a replacement where you put in the alternative DNS into your system and it takes over and goes seamlessly from there. you then rely on "crowd-sourcing" from the intelligent people just like cloudmark do distributed spam filtering to check that the submitted DNS alternative zone files are actually correct.
well, it depends on what kind of impression you want to give. the setup that i had at ISS was a swivel chair that had a split keyboard, with a mouse track-pad on one half. even as a touch-typist, it took about 2 weeks to get used to, for two reasons:
1) the split keyboard when mounted on the arms of the chair turns out to be just outside of peripheral vision. it was a real surprise to learn that i was relying on peripheral vision to get 150wpm typing speed.
2) the split spacebar (one on each half) had me going "rattle rattle rattle THUMP rattle THUMP" for about a week as i missed the (shortened) spacebar with left thumb. after a while, again, i got used to it.
now, the really utterly cool thing about having a "Command Console" Chair was that, with the 4 metre cable, i could put my feet up on the desk, staring at a black linux 80x60 console screen using alt-f1 to alt-f6 to select different applications. people stopping by could hear that i was definitely "working", because of the distinct sound of 150wpm typing speed.
however this may not necessarily be the kind of impression that you wish to give at work: laid-back cool but way fast working, i dunno. it's definitely better than the pizza-consuming caffeine-crazed internet junkie stereotype, though.
wait... hang on... it's ok for the U.S. govt to *actually* have warrantless wiretapping, but it's not ok to have china *maybe* doing warrantless wiretapping? huh. how about Huawei provide the full schematics and full source code of the LTE Cell-Towers under license, and the parts be manufactured in... oh wait, the cheapest place to have the parts manufactured is: China.
the cost of shipping parts from supplies to factories, and cost of assembly, as well as retooling factory costs, costs or printing up of boxes, is taken into account in the "FOB" price. that's out of the *factory*: that's what "FOB" means.
so that leaves shipping of units to stores (in bulk, by sea, with a 2-3 month delivery time, this shouldn't be more than $4). the hardware development NREs should not be more than $250,000 (as a one-off cost): if you spend more than that on designing case-work, you're doing something seriously wrong.
that just leaves the Operating System development costs, which i really don't think should be more than 10 man-years, especially as the ippad software's "fundamentals" are from MacOSX anyway. 10 man-years... average programmer $50k.... that's $500k NREs in software development. ok, call it 100 man-years, that's $USD 5 million.... that's a *one-off* cost, then you can ramp down or deploy those programmers elsewhere. how many ipads sold? that $5 million gets amortised pretty quickly...
warehouses _surely_ don't cost that much to rent.... you see where this is leading?
what many people don't realise is that the apple ippad's FOB price, out of Shenzen (FOB - "Free on Board" as in "your responsibility once it's on the ship"), is $USD 150. that's in direct contrast to that article which back-calculated a completely arbitrary set of prices for components, which came up with a number "$300". it's wrong. here's the major components: battery: $15. ARM processor: $20. NAND Flash RAM: $10. DDR memory: $15. screen: $25. capacitive panel: $25. that's $110, right there. add on about another $15 (which is very generous), you come to $125. add on a build cost, add on a profit margin, you see how you get to $150 and not *more* than $150.
this same cost of components applies equally to all the other tablets out there. so why in god's name are these manufacturers trying to sell these devices at a 300% markup? i don't understand.
um, i know it's being said quite a lot, already, but it's worth repeating: java's pretty much dead on the desktop. people are even replacing Flash applications with HTML5, as it's reaching high market share and maturity, especially now that IE9 has actually better (read "stricter") HTML5 compliance than the Free Software equivalents. how in god's name is oracle expecting to break into that?
the other thing that's worth emphasising is that when you have alternative language bindings to HTML5, you get the best of both worlds. so... why doesn't oracle put its money behind getting java bindings (or, better "generic" bindings like DCOM and XPCOM) on top of HTML5 browser engines? with Trident (the engine behind MSHTML aka IE) that's a done deal already: Trident (MSHTML.DLL and MSXML.DLL) already *has* DCOM bindings so it's a matter of about 2-3 weeks to get something like that up-and-running. XPCOM (XulRunner) is a little trickier: you'd have to find or create java bindings to XPCOM (they don't exist afaik) and the hardest (technically speaking) is webkit (used in android, safari, ipphon etc.)
then you have literally the best of both worlds. HTML5 as the "front-end", and whatever-language-you-choose to control and direct it. btw this is exactly what's been done for the pyjamas project (http://pyjs.org) except using python not java.
ok - i may just be a very strange individual, then, because reverse-engineering, whilst time-consuming, is something that i can do pretty easily. and, just that one "eyeball" ok two i have binocular vision, it really didn't take long to "crack" NT Domains Security Logins - about 30 days - and immediately it was obvious that there was a serious problem (40-bit bottleneck). then, i had to tackle NTLMSSP later on: again, about 40 days, and again, immediately detected a serious problem or two.
the gnuradio guys: they're not that many people who bother to reverse-engineer APCO P25. yet the moment they did, they found serious flaws in the algorithms, which have been QUOTES SECURE QUOTES for what... over a decade? what bothers me about this is that it's only when people actually try do you find out that actually it's pretty easy to find security flaws.
so the real problem with the whole "security through obscurity" approach is that you *don't* know who's attacked the algorithm.
there's a very interesting exercise which you should try. take a number, say 1000, and invert it. then subtract from one. so, you get 0.999 in this case. now assume that that's the probability that something is "secure through obscurity". now multiply that 1,000 times (1,000 people) - it drops pretty rapidly, huh? now increase that number to 1,000,000. so you do pow(0.999999, 1000000) - what do you notice? it's roughly the same number, isn't it? actually the number is 1 / 2.718281828 which you should recognise, immediately. now, what's interesting is if you either increase the number of people by even a small margin, or you decrease the probability by even a small margin: that "security" drops like a stone.
basically what this means is that if you rely on security through obscurity, it only takes *one* person - out of however many millions the system is exposed to - to "crack" the system, and you're screwed. and, because the intentions of that person are equally unknown, to rely on security through obscurity is just very very dumb.
that's funny, because only a few hours ago there was an article posted on slashdot saying how good "security through obscurity" is, with the author of the paper saying that ignorance of the hardware and software is a "good defense". now someone else is saying that the pace of research into hardware is accelerated, and as a Reverse-Engineer and Security Researcher and an intelligent person whom that "security through obscurity" paper clearly sees as a threat, i feel warm and fuzzy now.
there is a common misconception that it's necessary to have a large ultra-expensive highly-polluting rare-earth-metal battery pack. you don't. the conditions for not needing a $25,000 battery pack (worth stealing) are as follows:
* the vehicle weight must be under 550kg (400kg EU Category L7E is perfect) * low-rolling resistance tyres are essential * you must be happy with a top speed of 60mph and a top cruising speed of about 55mph * the frontal area of the vehicle must be no more than 1.5 sqm * the drag coefficient must be 0.30 or less * the full drivetrain efficiency must be no less than 80%
under these circumstances, which are perfectly reasonable for most peoples "commuting" needs, you can get away with putting in an off-the-shelf 240/120V AC 5kW or 6kW Diesel Generator and a "Fast Charger" with about 50 Amp output, and that is enough to keep the batteries continuously "topped up" or in fact just to directly drive the Electric Vehicle.
if you try to go BEYOND these circumstances (even putting in a 700kg vehicle) then you get into trouble, because the "Range Extender" now has to be an 8-10kW Diesel Generator, which now weighs 250kg not 100kg, doesn't pull the same level of fuel economy as a 5-6kW Generator (which work out at about 1 Litre per hour), and the exercise is a complete waste. so you have to stick to those conditions, and the maths works out very very well. almost... "too well", to the point where it's hard to believe the MPG figures.
which if you look back about a week, you'll find a link to a LibreOffice spreadsheet where you can play and plug in your own "vehicle" line and confirm the maths i did, above.
the point is: *if* you do this sort of thing, then yes, large battery packs become irrelevant: you can treat that $500 lead-acid battery pack as a disposable (recyclable) item, and yes, you could even consider running the diesel generator to plug back into the National Grid. personally i think that'd be a bit of a waste of perfectly good Diesel, i'd say, but you could do it.
marvell == 1:) sorry, i keep forgetting about marvell because of their NDA policy. when they quit with that shit, i'll be able to count their CPUs, because i will have seen the f*****g data sheets! i knew they had at least one, though.
this is why China's ICT have added the 200 most-common x86 instructions as "emulated" but hardware-accelerated emulation to their upcoming Godson / Loongson 2G MIPS CPU. throw-away statistic about the 2G: even the single-core 1ghz 65nm version of the 2G has such a powerful Vector Processing Unit that it can do 1920x1080 MPEG decode at 100fps. and they plan to put 16 of these on one die! they're insane!:)
oh _good_! very very good to hear. keep in touch, ok? btw, the EOMA/PCMCIA spec, we're *not* going for PCMCIA electrical interoperability: it's re-use of the 68-pins, much like the Conditional Access Modules for satellite TV.
actually if you look up that video showing a web browser of an ARM system vs an Intel Atom, it's only towards the end of the video that they show the specs. 1.6ghz Intel Atom, vs Dual-Core FIVE HUNDRED mhz Cortex A9. the performance was about the same.
this is in part due to the x86 instruction set. it's "compact" i.e. it takes up less memory. that was fine and dandy and necessary 30 years ago, but now, memory is not the bottleneck. so x86 @ 1.6ghz is roughly equivalent to ARM @ 800mhz. yes there is the issue that ARM goes for higher latency (less power) whereas Intel goes for lower latency (more power), wider buses etc.
but the NuSmart 2816 has two versions - one is a 32-bit-wide bus, the other is 64-bit-wide... same width as the memory bus for the Intel Atom (64-bit). i think you'll find, therefore, that the 2ghz NuSmart pisses all over some fairly decent x86 systems. we'll just have to see, though:)
ok - it's too early to tell, yet, for the Zynq. you kinda get a feel for what these CPU manufacturers do. they go out and buy off-the-shelf "blobs" from fabless companies, slap together a few datasheets and see if anyone's interested: Xilinx is no exception here:) so, nobody expressed an interest in what they called the 7010, but plenty of people were interested in the 7030.
so anyway - i'm meeting with a xilinx rep next month, to get across that having this available in a beagle-board-like form-factor would be uhn... good!
second point is: do read what i wrote about "PCs" - there really isn't any point in sticking to the legacy PC form-factor, there really isn't. do you recall those IBM Mainframes where the engineer used to ask people to leave the room when they were being serviced? it was because this full-height cabinet had *one* PCB in it, right at the back, in the corner. to put an ARM-based motherboard into a standard desktop PC case would be something similar, but with about 100 to 1,000 times the cubic volume of the desktop PC case entirely wasted.
imagine having a Zynq-7030 as a desktop PC in a PCMCIA-sized unit, and on the end of the 68-pin connector there was an Arduino-compatible 2in x 2.5in Leafpad "Maple"-like Embedded Controller as well (STM32F). would that absolutely rock, or would that absolutely rock? oh wait - this is what's possible as outlined by the EOMA/PCMCIA initiative, here: http://elinux.org/Embedded_Open_Modular_Architecture/PCMCIA/MiniEngineeringBoard
yes - and it gets _particularly_ interesting if there is a free software toolchain for Xilinx FPGAs. oh wait - there is one! http://www.milkymist.org/fpgatools/
the trimslice is $200, is non-upgradeable and does not have an SATA-II interface (whereas the raspberrypi is $25 - a discrepancy of 85%+ in price, for no good reason). the genesi products use an iMX515 which has a hard limit of 512mb RAM, and the laptop only has a maximum LCD resolution of 1024x600, which is completely unusable. every single product out there right now has these hard compromises that make them completely dissatisfactory for at least one market. this is why i'm doing the EOMA/PCMCIA initiative, so that a product is *not* restricted (requires a total motherboard redesign) to a particular CPU. http://elinux.org/Embedded_Open_Modular_Architecture/PCMCIA
unfortunately, this system illustrates why 1024x600 LCDs are undesirable. as does the genesi laptop with the same sized screen. other than the forced-installation of android, total non-upgradeability, inability to have 1gb of RAM and complete lack of interface for putting in an SATA SSD, the AC100 is actually very good. ok, in case you hadn't noticed, that was supposed to be ironic.
the first problem is that the cost of the whole system's components is actually, as the RaspberryPi shows, somewhere around the $40 mark. also, if you look closer at the Tegra 250 which is used in the TrimSlice, it doesn't have SATA-II. and as i mentioned in another post here, the number of modern ARM CPUs with PCI-e on the market is less than 5.
so you can't expand it (ARM systems aren't designed that way), and it happens not to have the _exact_ set of features which make it truly desirable to free software developers, which is why free software developers are plumping (reluctantly) for the OpenRD Ultimate, and wishing that there was something better.
right now, it's all a big big compromise. and that's why i started the EOMA initiative, so that those "compromises" do not impact on the development of a product: you can always go swap out the CPU card for something better when it comes along. http://elinux.org/Embedded_Open_Modular_Architecture/PCMCIA
ok - i'm pleased to see a response here: there are several points that are good, and some are, when you look closer, turn out to be unrealistic for mass-volume so-called "embedded" products.
1) the first is form-factor. this is great! yes, one of the options being considered is to have a standard Mini-ATX/ITX motherboard (into which an EOMA/PCMCIA CPU card can be plugged, at the back). there are several embedded companies that produce Mini ATX motherboards as standard, for their "modules", so it is not a new concept, it is in fact a proven one.
2) the second is connectors / interfaces. if you look right across the board at the very latest ARM processors coming out *right now*, you can count the number of Cortex A8 and Cortex A9 systems (as well as Marvell's "ARM-compatible" range of processors) that have PCI-e on the fingers of one hand.
i'll say that again.
the total number of modern ARM processors with even a 1x PCI-e interface is *below* 5 (five).
now there do exist some Cortex A8s (e.g. the OMAP35xx series) which have a HPI bus, onto which you could put a PCI-e "PHY" chip as it's called, but the total number of companies doing actual PCI-e "PHY" chips is, also, very very limited. typically, any company which has PCI-e PHY interface is a "Fabless Semi" company that gets bought up very very rapidly by the likes of Mentor Graphics, Synopsys and so on.
3) the third is the sheer overwhelming disparity between the ARM CPU's power consumption and the average PCI-e-based GPU's power consumption. the absolute ABSOLUTE lowest power consumption PCI-e-based GPU i could find is one from SiS, it's an older 65nm CMOS process, and if you ramp its speed down to the absolute lowest it will go without keeling over, it uses 6 watts. SIX watts!! you wanna connect a 6 watt GPU up to a 0.5 to 1.0 watt processor be my guest!
4) Multi-layer boards at ATX/ITX form-factor are expensive. if you have the CPU on-board the Motherboard (rather than being on a separate card), you then are forced to have the most complex part - the CPU-to-RAM interface - push up the number of layers required for the *whole* motherboard. by contrast, if you do the CPU-plus-RAM as a separate tiny, tiny board, just presenting its interfaces (SATA, ETH, USB, I2C, RGB/TTL etc.) via a simple connector (e.g. PCMCIA 68-pin) then you've just saved a fortune on the cost of the main motherboard because the main motherboard PCB can be done as an ultra-low-cost 4 or even if you're really lucky or a very good designer as a 2 layer board.
5) The power requirements of standard PCs are 10 to 200x larger than is actually needed! 500 to 1000 watts i mean for fuck's sake that's just insane. these ARM processors, the fastest most powerful one available on the market right now (sampling) is the NuSmart 2816, and that uses _two_ watts (shock horror) at 2ghz. wow big fucking deal. why on god's green earth would you want to match a 2 watt CPU with a 1000 watt Power Supply?? the entire motherboard would probably need a big resistor just to draw enough current in order to convince the PSU that nothing's wrong! i'm not joking about that - i'm dead serious.
6) The level of integration on these so-called ARM "embedded" CPUs is so high that it's really not worth the effort. present a USB bus, present an Ethernet port, present an SATA socket, along with an HDMI out and maybe even VGA, you're done! ship the damn product out the door, it cost you $35 to make! don't believe that price? just look at the cost of the RaspberryPi - it's doable. the irony is that for $35 of the "upgraded" RaspberryPi you can get an 800mhz Cortex A9 with an AML-8726-M (single core) for the same price. and the same size. credit-card-sized. you have to ask yourself: why would you _want_ to fit a credit-card-sized computer into a 12 x 15 x 8in "Desktop" case??:) why not fit it into a 4in x 5in x 0.75in box, instead?
so, whilst on the face of it, fitting into the "standard" - i'm going to go further than that i'm going to
Slashdot Mirror
i've mentioned this before, and it's worth mentioning again: the p2p-dns project's goals appear to be to create a separate ".p2p" top-level domain rather than to provide a complete distributed DNS replacement. that's just simply not ambitious or useful enough. we need a replacement where you put in the alternative DNS into your system and it takes over and goes seamlessly from there. you then rely on "crowd-sourcing" from the intelligent people just like cloudmark do distributed spam filtering to check that the submitted DNS alternative zone files are actually correct.
well, it depends on what kind of impression you want to give. the setup that i had at ISS was a swivel chair that had a split keyboard, with a mouse track-pad on one half. even as a touch-typist, it took about 2 weeks to get used to, for two reasons:
1) the split keyboard when mounted on the arms of the chair turns out to be just outside of peripheral vision. it was a real surprise to learn that i was relying on peripheral vision to get 150wpm typing speed.
2) the split spacebar (one on each half) had me going "rattle rattle rattle THUMP rattle THUMP" for about a week as i missed the (shortened) spacebar with left thumb. after a while, again, i got used to it.
now, the really utterly cool thing about having a "Command Console" Chair was that, with the 4 metre cable, i could put my feet up on the desk, staring at a black linux 80x60 console screen using alt-f1 to alt-f6 to select different applications. people stopping by could hear that i was definitely "working", because of the distinct sound of 150wpm typing speed.
however this may not necessarily be the kind of impression that you wish to give at work: laid-back cool but way fast working, i dunno. it's definitely better than the pizza-consuming caffeine-crazed internet junkie stereotype, though.
wait... hang on... it's ok for the U.S. govt to *actually* have warrantless wiretapping, but it's not ok to have china *maybe* doing warrantless wiretapping? huh. how about Huawei provide the full schematics and full source code of the LTE Cell-Towers under license, and the parts be manufactured in... oh wait, the cheapest place to have the parts manufactured is: China.
the cost of shipping parts from supplies to factories, and cost of assembly, as well as retooling factory costs, costs or printing up of boxes, is taken into account in the "FOB" price. that's out of the *factory*: that's what "FOB" means.
so that leaves shipping of units to stores (in bulk, by sea, with a 2-3 month delivery time, this shouldn't be more than $4). the hardware development NREs should not be more than $250,000 (as a one-off cost): if you spend more than that on designing case-work, you're doing something seriously wrong.
that just leaves the Operating System development costs, which i really don't think should be more than 10 man-years, especially as the ippad software's "fundamentals" are from MacOSX anyway. 10 man-years... average programmer $50k.... that's $500k NREs in software development. ok, call it 100 man-years, that's $USD 5 million.... that's a *one-off* cost, then you can ramp down or deploy those programmers elsewhere. how many ipads sold? that $5 million gets amortised pretty quickly...
warehouses _surely_ don't cost that much to rent. ... you see where this is leading?
what many people don't realise is that the apple ippad's FOB price, out of Shenzen (FOB - "Free on Board" as in "your responsibility once it's on the ship"), is $USD 150. that's in direct contrast to that article which back-calculated a completely arbitrary set of prices for components, which came up with a number "$300". it's wrong. here's the major components: battery: $15. ARM processor: $20. NAND Flash RAM: $10. DDR memory: $15. screen: $25. capacitive panel: $25. that's $110, right there. add on about another $15 (which is very generous), you come to $125. add on a build cost, add on a profit margin, you see how you get to $150 and not *more* than $150.
this same cost of components applies equally to all the other tablets out there. so why in god's name are these manufacturers trying to sell these devices at a 300% markup? i don't understand.
um, i know it's being said quite a lot, already, but it's worth repeating: java's pretty much dead on the desktop. people are even replacing Flash applications with HTML5, as it's reaching high market share and maturity, especially now that IE9 has actually better (read "stricter") HTML5 compliance than the Free Software equivalents. how in god's name is oracle expecting to break into that?
the other thing that's worth emphasising is that when you have alternative language bindings to HTML5, you get the best of both worlds. so... why doesn't oracle put its money behind getting java bindings (or, better "generic" bindings like DCOM and XPCOM) on top of HTML5 browser engines? with Trident (the engine behind MSHTML aka IE) that's a done deal already: Trident (MSHTML.DLL and MSXML.DLL) already *has* DCOM bindings so it's a matter of about 2-3 weeks to get something like that up-and-running. XPCOM (XulRunner) is a little trickier: you'd have to find or create java bindings to XPCOM (they don't exist afaik) and the hardest (technically speaking) is webkit (used in android, safari, ipphon etc.)
then you have literally the best of both worlds. HTML5 as the "front-end", and whatever-language-you-choose to control and direct it. btw this is exactly what's been done for the pyjamas project (http://pyjs.org) except using python not java.
ok - i may just be a very strange individual, then, because reverse-engineering, whilst time-consuming, is something that i can do pretty easily. and, just that one "eyeball" ok two i have binocular vision, it really didn't take long to "crack" NT Domains Security Logins - about 30 days - and immediately it was obvious that there was a serious problem (40-bit bottleneck). then, i had to tackle NTLMSSP later on: again, about 40 days, and again, immediately detected a serious problem or two.
the gnuradio guys: they're not that many people who bother to reverse-engineer APCO P25. yet the moment they did, they found serious flaws in the algorithms, which have been QUOTES SECURE QUOTES for what... over a decade? what bothers me about this is that it's only when people actually try do you find out that actually it's pretty easy to find security flaws.
so the real problem with the whole "security through obscurity" approach is that you *don't* know who's attacked the algorithm.
there's a very interesting exercise which you should try. take a number, say 1000, and invert it. then subtract from one. so, you get 0.999 in this case. now assume that that's the probability that something is "secure through obscurity". now multiply that 1,000 times (1,000 people) - it drops pretty rapidly, huh? now increase that number to 1,000,000. so you do pow(0.999999, 1000000) - what do you notice? it's roughly the same number, isn't it? actually the number is 1 / 2.718281828 which you should recognise, immediately. now, what's interesting is if you either increase the number of people by even a small margin, or you decrease the probability by even a small margin: that "security" drops like a stone.
basically what this means is that if you rely on security through obscurity, it only takes *one* person - out of however many millions the system is exposed to - to "crack" the system, and you're screwed. and, because the intentions of that person are equally unknown, to rely on security through obscurity is just very very dumb.
that's funny, because only a few hours ago there was an article posted on slashdot saying how good "security through obscurity" is, with the author of the paper saying that ignorance of the hardware and software is a "good defense". now someone else is saying that the pace of research into hardware is accelerated, and as a Reverse-Engineer and Security Researcher and an intelligent person whom that "security through obscurity" paper clearly sees as a threat, i feel warm and fuzzy now.
Drones don't kill people - people kill people
there is a common misconception that it's necessary to have a large ultra-expensive highly-polluting rare-earth-metal battery pack. you don't. the conditions for not needing a $25,000 battery pack (worth stealing) are as follows:
* the vehicle weight must be under 550kg (400kg EU Category L7E is perfect)
* low-rolling resistance tyres are essential
* you must be happy with a top speed of 60mph and a top cruising speed of about 55mph
* the frontal area of the vehicle must be no more than 1.5 sqm
* the drag coefficient must be 0.30 or less
* the full drivetrain efficiency must be no less than 80%
under these circumstances, which are perfectly reasonable for most peoples "commuting" needs, you can get away with putting in an off-the-shelf 240/120V AC 5kW or 6kW Diesel Generator and a "Fast Charger" with about 50 Amp output, and that is enough to keep the batteries continuously "topped up" or in fact just to directly drive the Electric Vehicle.
if you try to go BEYOND these circumstances (even putting in a 700kg vehicle) then you get into trouble, because the "Range Extender" now has to be an 8-10kW Diesel Generator, which now weighs 250kg not 100kg, doesn't pull the same level of fuel economy as a 5-6kW Generator (which work out at about 1 Litre per hour), and the exercise is a complete waste. so you have to stick to those conditions, and the maths works out very very well. almost... "too well", to the point where it's hard to believe the MPG figures.
the maths, principle and links to various sites is here: http://lkcl.net/hybrid_electric_vehicle/design_principle.html
and there's a discussion here:
http://www.diyelectriccar.com/forums/showthread.php/why-there-no-board-generatorsi-p261099.html
which if you look back about a week, you'll find a link to a LibreOffice spreadsheet where you can play and plug in your own "vehicle" line and confirm the maths i did, above.
the point is: *if* you do this sort of thing, then yes, large battery packs become irrelevant: you can treat that $500 lead-acid battery pack as a disposable (recyclable) item, and yes, you could even consider running the diesel generator to plug back into the National Grid. personally i think that'd be a bit of a waste of perfectly good Diesel, i'd say, but you could do it.
you'll understand when peak oil hits, and you can't _get_ 110 watts of electricity.
marvell == 1 :) sorry, i keep forgetting about marvell because of their NDA policy. when they quit with that shit, i'll be able to count their CPUs, because i will have seen the f*****g data sheets! i knew they had at least one, though.
this is why China's ICT have added the 200 most-common x86 instructions as "emulated" but hardware-accelerated emulation to their upcoming Godson / Loongson 2G MIPS CPU. throw-away statistic about the 2G: even the single-core 1ghz 65nm version of the 2G has such a powerful Vector Processing Unit that it can do 1920x1080 MPEG decode at 100fps. and they plan to put 16 of these on one die! they're insane! :)
http://lists.gpl-violations.org/pipermail/legal/2010-March/001936.html
http://lists.gpl-violations.org/pipermail/legal/2010-March/001872.html
http://www.codon.org.uk/~mjg59/android_tablets/
oh _good_! very very good to hear. keep in touch, ok? btw, the EOMA/PCMCIA spec, we're *not* going for PCMCIA electrical interoperability: it's re-use of the 68-pins, much like the Conditional Access Modules for satellite TV.
actually if you look up that video showing a web browser of an ARM system vs an Intel Atom, it's only towards the end of the video that they show the specs. 1.6ghz Intel Atom, vs Dual-Core FIVE HUNDRED mhz Cortex A9. the performance was about the same.
this is in part due to the x86 instruction set. it's "compact" i.e. it takes up less memory. that was fine and dandy and necessary 30 years ago, but now, memory is not the bottleneck. so x86 @ 1.6ghz is roughly equivalent to ARM @ 800mhz. yes there is the issue that ARM goes for higher latency (less power) whereas Intel goes for lower latency (more power), wider buses etc.
but the NuSmart 2816 has two versions - one is a 32-bit-wide bus, the other is 64-bit-wide... same width as the memory bus for the Intel Atom (64-bit). i think you'll find, therefore, that the 2ghz NuSmart pisses all over some fairly decent x86 systems. we'll just have to see, though :)
ok - it's too early to tell, yet, for the Zynq. you kinda get a feel for what these CPU manufacturers do. they go out and buy off-the-shelf "blobs" from fabless companies, slap together a few datasheets and see if anyone's interested: Xilinx is no exception here :) so, nobody expressed an interest in what they called the 7010, but plenty of people were interested in the 7030.
so anyway - i'm meeting with a xilinx rep next month, to get across that having this available in a beagle-board-like form-factor would be uhn... good!
second point is: do read what i wrote about "PCs" - there really isn't any point in sticking to the legacy PC form-factor, there really isn't. do you recall those IBM Mainframes where the engineer used to ask people to leave the room when they were being serviced? it was because this full-height cabinet had *one* PCB in it, right at the back, in the corner. to put an ARM-based motherboard into a standard desktop PC case would be something similar, but with about 100 to 1,000 times the cubic volume of the desktop PC case entirely wasted.
imagine having a Zynq-7030 as a desktop PC in a PCMCIA-sized unit, and on the end of the 68-pin connector there was an Arduino-compatible 2in x 2.5in Leafpad "Maple"-like Embedded Controller as well (STM32F). would that absolutely rock, or would that absolutely rock? oh wait - this is what's possible as outlined by the EOMA/PCMCIA initiative, here: http://elinux.org/Embedded_Open_Modular_Architecture/PCMCIA/MiniEngineeringBoard
yes - and it gets _particularly_ interesting if there is a free software toolchain for Xilinx FPGAs. oh wait - there is one! http://www.milkymist.org/fpgatools/
the trimslice is $200, is non-upgradeable and does not have an SATA-II interface (whereas the raspberrypi is $25 - a discrepancy of 85%+ in price, for no good reason). the genesi products use an iMX515 which has a hard limit of 512mb RAM, and the laptop only has a maximum LCD resolution of 1024x600, which is completely unusable. every single product out there right now has these hard compromises that make them completely dissatisfactory for at least one market. this is why i'm doing the EOMA/PCMCIA initiative, so that a product is *not* restricted (requires a total motherboard redesign) to a particular CPU. http://elinux.org/Embedded_Open_Modular_Architecture/PCMCIA
unfortunately, this system illustrates why 1024x600 LCDs are undesirable. as does the genesi laptop with the same sized screen. other than the forced-installation of android, total non-upgradeability, inability to have 1gb of RAM and complete lack of interface for putting in an SATA SSD, the AC100 is actually very good. ok, in case you hadn't noticed, that was supposed to be ironic.
the first problem is that the cost of the whole system's components is actually, as the RaspberryPi shows, somewhere around the $40 mark. also, if you look closer at the Tegra 250 which is used in the TrimSlice, it doesn't have SATA-II. and as i mentioned in another post here, the number of modern ARM CPUs with PCI-e on the market is less than 5.
so you can't expand it (ARM systems aren't designed that way), and it happens not to have the _exact_ set of features which make it truly desirable to free software developers, which is why free software developers are plumping (reluctantly) for the OpenRD Ultimate, and wishing that there was something better.
right now, it's all a big big compromise. and that's why i started the EOMA initiative, so that those "compromises" do not impact on the development of a product: you can always go swap out the CPU card for something better when it comes along. http://elinux.org/Embedded_Open_Modular_Architecture/PCMCIA
there was a discussion of the features available (and desired) on debian-arm a few months back, let me give you a link to jump somewhere into the middle of that:
http://lists.debian.org/debian-arm/2011/08/msg00012.html
ok - i'm pleased to see a response here: there are several points that are good, and some are, when you look closer, turn out to be unrealistic for mass-volume so-called "embedded" products.
1) the first is form-factor. this is great! yes, one of the options being considered is to have a standard Mini-ATX/ITX motherboard (into which an EOMA/PCMCIA CPU card can be plugged, at the back). there are several embedded companies that produce Mini ATX motherboards as standard, for their "modules", so it is not a new concept, it is in fact a proven one.
2) the second is connectors / interfaces. if you look right across the board at the very latest ARM processors coming out *right now*, you can count the number of Cortex A8 and Cortex A9 systems (as well as Marvell's "ARM-compatible" range of processors) that have PCI-e on the fingers of one hand.
i'll say that again.
the total number of modern ARM processors with even a 1x PCI-e interface is *below* 5 (five).
now there do exist some Cortex A8s (e.g. the OMAP35xx series) which have a HPI bus, onto which you could put a PCI-e "PHY" chip as it's called, but the total number of companies doing actual PCI-e "PHY" chips is, also, very very limited. typically, any company which has PCI-e PHY interface is a "Fabless Semi" company that gets bought up very very rapidly by the likes of Mentor Graphics, Synopsys and so on.
3) the third is the sheer overwhelming disparity between the ARM CPU's power consumption and the average PCI-e-based GPU's power consumption. the absolute ABSOLUTE lowest power consumption PCI-e-based GPU i could find is one from SiS, it's an older 65nm CMOS process, and if you ramp its speed down to the absolute lowest it will go without keeling over, it uses 6 watts. SIX watts!! you wanna connect a 6 watt GPU up to a 0.5 to 1.0 watt processor be my guest!
4) Multi-layer boards at ATX/ITX form-factor are expensive. if you have the CPU on-board the Motherboard (rather than being on a separate card), you then are forced to have the most complex part - the CPU-to-RAM interface - push up the number of layers required for the *whole* motherboard. by contrast, if you do the CPU-plus-RAM as a separate tiny, tiny board, just presenting its interfaces (SATA, ETH, USB, I2C, RGB/TTL etc.) via a simple connector (e.g. PCMCIA 68-pin) then you've just saved a fortune on the cost of the main motherboard because the main motherboard PCB can be done as an ultra-low-cost 4 or even if you're really lucky or a very good designer as a 2 layer board.
5) The power requirements of standard PCs are 10 to 200x larger than is actually needed! 500 to 1000 watts i mean for fuck's sake that's just insane. these ARM processors, the fastest most powerful one available on the market right now (sampling) is the NuSmart 2816, and that uses _two_ watts (shock horror) at 2ghz. wow big fucking deal. why on god's green earth would you want to match a 2 watt CPU with a 1000 watt Power Supply?? the entire motherboard would probably need a big resistor just to draw enough current in order to convince the PSU that nothing's wrong! i'm not joking about that - i'm dead serious.
6) The level of integration on these so-called ARM "embedded" CPUs is so high that it's really not worth the effort. present a USB bus, present an Ethernet port, present an SATA socket, along with an HDMI out and maybe even VGA, you're done! ship the damn product out the door, it cost you $35 to make! don't believe that price? just look at the cost of the RaspberryPi - it's doable. the irony is that for $35 of the "upgraded" RaspberryPi you can get an 800mhz Cortex A9 with an AML-8726-M (single core) for the same price. and the same size. credit-card-sized. you have to ask yourself: why would you _want_ to fit a credit-card-sized computer into a 12 x 15 x 8in "Desktop" case?? :) why not fit it into a 4in x 5in x 0.75in box, instead?
so, whilst on the face of it, fitting into the "standard" - i'm going to go further than that i'm going to