we'll have a dual-core CPU Card available once we've found both a SoC vendor willing to be open about their CPU design as well as a partner willing to make an at-cost EOMA-68 CPU Card or do a deal of some kind, ok? we'll get there, all right?:)/peace
In brief, keep up the good work, that sounds really good!
thank you, that's really appreciated. can i suggest you join the mailing list or just keep an eye on it via gmane or something, if you prefer? lots of people subscribe "no-mail" then lurk on gmane and they can then post if they want to, without filling up their mailbox. here's the subscription page: http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
feel free to ask anything you like, there, ok? or, ah, what might suit you: join the irc channel #arm-netbook on freenode./peace
Uh, the Pi is meant an educational and hobby platform. It has a bunch of slots and connectors. This thing is obviously a commercial product without a lot of slots or connectors that's meant to be embedded in a larger product.
Not being an embedded systems person, I'd be grateful if somebody linked examples of the kind of system that uses this kind of CPU card.
The supposedly "Open" EOMA-68 standard is a repurposed PCMCIA connector and PC-Card that is actually under "an undisclosed patent and the project had to make sure that everything produced fell under that patent so an undisclosed fee could be charged."
i notice that you're posting as anonymous coward. we had some trouble with a particular individual who promised to deliver, reneged on that promise and caused us a great deal of aggravation. the patents were mentioned very early on in the project and were raised again much later, during a fire-fighting exercise dealing with the shit raised by the vindictive pissed-off and self-serving individual.
to explain: the patents are there to protect people from physical harm due to the possibility of idiotic companies creating non-interoperable products that could potentially short-circuit things e.g. a lithium battery. if the scope of this project was to sell only 50,000 units maximum, we would not bother with the patents. however, given that the volume of units is expected to reach several million per year, there is no way in hell that we can leave this to "self-policing".
look up the story that i told about my uncle, Anthony Pickford, who was Smith Kline Beecham's Director at the time when some moronic companies in the UK started importing "clones" of one of SKB's drugs. the clone drugs were *KILLING* people; SKB had to move very quickly. they managed to solve it by suing the Inland Revenue when Customs and Excise refused to comply with a 3rd party discovery request for the Import Records. the case was taken very swiftly to the House of Lords, where, fortunately, SKB won and was able to obtain the records, contact the importers and get the killer drugs stopped. if they did not *have* the patents, there would be no way that they could stop people from being killed.
sometimes, patents can be used for good reasons. for someone who hates software patents and patents in general with a vengeance, that's really saying something.
so, anonymous coward: if you've got questions, anonymous coward, fucking well ask them and stop making accusations, please.
It's a schematic (actually, the picture shows a board layout)
shit. you're right. it is! no wonder the other guy said we'd be 6 months from release:) no, it's definitely a board layout. first samples will be available for testing by next week. definitely not 6 months from now.
It's not clear why you'd want an Allwinner A10 in a PCMCIA form factor. The Allwinner A10 has a sizable set of peripherals on-chip. Ethernet, HDMI, etc. Usually, boards for this part have a whole row of connectors. Bringing out the pins on a PCMCIA connector means you need another board to fan out the peripherals.
we wanted something that is user-installable and user-upgradeable. if we had wanted factory-installable (only) then we would a) not really have bothered at all, given the proliferation of offerings from direct-insight.co.uk and variscite.com and many many others b) we would have created something like the q-seven standard and, again, really to be honest, would not have bothered with that, either, because why create a competing standard?
no, you're missing a couple of points. one is that the A10 EOMA-68 CPU Card can operate stand-alone, powered by USB-OTG, booting from USB-OTG, NAND or Micro-SD as you choose, and having both HDMI out and Stereo Audio. that's not bad, right there.
the other point is that we picked interfaces that happen to be "common buses", that happen to all have backwards-compatible speed negotiation. 24-pin RGB/TTL you can drop down even to as low as 15 pin by ignoring the higher-res bits; you can reduce the clock-rate to run a 320x240 LCD or you can ramp it up to run 2048x2048 @ 30fps in full colour. USB2 goes all the way from 11mbit/sec to 480mbit/sec. SATA-II has down-level negotiation all the way to 150mbit/sec. I2C goes from something like 75khz up to 4mbit/sec or thereabouts. Gigabit Ethernet goes through 10 to 100 to 1000.
so there is a hell of a lot of thought gone into the selection of those interfaces, in order to keep the pin-count down. it was just pure luck that when you added 16 GPIOs and some power and ground that the pin-count came to *exactly* 68. jammy or what. and if you look at that interface set, it's *extremely* flexible and powerful. but i believe i know what you're saying: why didn't you make *all* the pins available? because if you've looked at the cost of user-hot-swappable 100-pin connectors, they're insanely expensive: $12 is not uncommon.
so instead, we're recommending the use of a low-cost STM32F on the other side (I/O Board side). we've tracked down the OpenEC2 project (originally the firmware for the OLPC XO-1) and intend to port it to RTEMS-lite, then extend it to provide Audio Drivers in the form of A/D and D/A converters, amongst other things. ST Micro actually recommend their 75mhz+ CPUs for use as Audio ICs. but it can pretty much cover everything. this practice is standard in x86 PCs (using an Embedded Controller) but is quite rare in the ARM world: normally you'd use the ARM CPU itself to do this job! but, because of the EOMA-68 "break", we can't do that. swings and roundabouts: it'll come out in the wash:)
I've been following this project for a while now, and it is going in a direction which I believe in.
thank you. i'm very encouraged to hear that.
I am getting tired of proprietary ARM hardware and software.
... you and me both. update from mjg on the Android-related GPL-violations situation of 18 months ago: it hasn't got any better. http://mjg59.dreamwidth.org/8991.html
that's actually an incorrect perception. the rhombus tech initiative was formed quite some time before the raspberry pi was conceived. we've just been applying a different strategy (zero-investment) which has resulted in some raather long delays as we've got up-to-speed.
The schematic is often the easiest part of the design. An EMC compliant PCB is usually harder; passing FCC/CE/* EMI compliance is harder; setting up for mass production is not for beginners either. Those guys just made the first step on a long road. And that's exactly why it's so hard to build hardware these days; the progress is so fast that by the time you are ready to manufacture the key parts are obsolete and out of production. Even if the parts are still available your design may be already obsolete because newer, better parts became available. It's either "design it under 3 months" or "do something else with your life."
you know what? i'm really glad you raised this point. it's *exactly* why we sub-divided the CPU Card from the actual device. independent development and product life-cycles for the CPU and the device! so yes, sure, the CPU becomes obsolete, but that's ok: you can just buy the latest CPU card... *without* having to throw away the entire product. so you've highlighted the very core of the strategy, here. it's not just about upgradeability, it's about being eco-conscious as well as providing redundancy without disrupting the user.
think about it: yes, sure, we're having a hard time getting the first CPU Card out, but you know what? it's just the first. it took 3 months to source just 5 connectors at reasonable prices (mostly because they are unusual: mid-mount HDMI, mid-mount audio, sub-1.8mm Micro-SD, mid-mount USB-OTG and the increasingly-obscure PCMCIA). but guess what? having found those suppliers, we won't have to do that again for subsequent CPU Cards, and we will have pre-established relationships by the time the 2nd CPU Card comes out.
also, with the 2nd and subsequent CPU Cards, we expect to actually have some profits made so that we can pay good people to work promptly and according to *our* timescales. one of the issues that we have is that we've got this far with *zero* investment. absolutely none. think about that for a moment. no money has changed hands; we are beholden to no-one, yet there are software engineers ready to get the OS onto the CPU Card, but not only that, the CPU Card Schematics have been made.
how is that even possible? we did deals, based on the strength of committment and the desire of our PRC State-Sponsored client to make use of the EOMA-68 solution and concept that we came up with. it's *perfect* for them.
so CE compliance will be covered by our client: they are big enough to be able to self-certify. FCC is more problematic: we're simply not going to even bother unless we receive an order from a USA/Canadian company of minimum 50k units, and the cost of the FCC Certification will be included in the quote. as the USA market is below 1/10th the size of the PRC market, we don't see this as being a problem.
but yes - the key here is that this first CPU Card is a heavy learning curve. we're on the lookout for faster and better CPU Cards, and we fully anticipate - especially with the Linaro-sign-ups such as TI, Samsung and Freescale creating fully open Schematics for the Origen, Pandaboard, IMX53QSB and the upcoming iMX6 - being able to very rapidly adapt those Open Schematics into EOMA-68 CPU Cards. what we would *really* like is for someone else to step forward and do that work, and we'd do a deal with them to introduce their product to our clients. that would be great. we much prefer to do these kinds of "cost-plus" deals. it's fairer to everyone who is involved.
it's also worthwhile pointing out that we've added a DIL2-44 (2.5in IDE size) expansion header which gives access to the more common "engineer's" GPIO functions, such as an extra USB 480mb/sec, as well as AC97/I2S, dual-channel LVDS, VGA out and more; as well as adding a more "factory-style" FPC-45 which provides access to the kinds of functions that you'd see in commercial IPTV and other products (Dual Transport Streams; GPS; Smart Card, TV-IN and so on).
obviously, that "factory / engineering" mode, you'd not be able to get the standard 5mm height PCMCIA case on, but that's ok, because it's either factory-installed or being used for engineering, R&D or educational purposes. i've documented the full pin-outs here: http://rhombus-tech.net/allwinner_a10/orders/
but as a minimum you'd need a docking station to connect to everything.
An odd number of cores. Perhaps they have 4 cores, each controlling 16 CPUs. Or 4 cores set aside for other purposes?
68 pins, not 68 cores:) of course, if you'd like to create a server box containing 64 or even 68 EOMA-68 CPU Cards, please feel free to do so! the idea was raised here: http://rhombus-tech.net/community_ideas/cluster_server/
i adapted the EOMA-68 standard after that discussion, and squeezed in 10/100/1000 Ethernet to make it more attractive. the Allwinner A10 doesn't have Gigabit Ethernet, but future CPU Cards definitely will.
apologies. it's the first in a series of CPU Cards, based around a mass-volume modular computing initiative that allows both china factories and software (libre) developers the opportunity to work together to create desirable, affordable mass-volume computing appliances. at the risk of melting your brain with another link, here's the news article which provides some background as to why the project exists: http://www.itwire.com/opinion-and-analysis/open-sauce/52054-british-company-looks-to-create-cheap-open-platforms
allow me to go over what you wrote:
it is a PCMCIA (PC-card) sized integrated computer
correct. it can operate stand-alone via USB-OTG power, if needed. without the case on, there's access to the remaining interfaces of the A10 that we could not fit onto the 2 ends of the CPU Card.
designed to compete with the Raspberry Pi...
incorrect. this is more a commercial venture than an educational venture, with volumes approaching several million units a year. our goals almost accidentally encompass those of the raspberry pi (hence the reason why the developers were a bit rude to me on their forums a few months back: they feel threatened, unfortunately. can't be helped... *sigh*).
supposedly cheaper
incorrect. this perception is based on a misinterpretation that unfortunately was propagated through more channels than we have resources to spend time chasing down and correcting.
and faster.
correct. it's a 1ghz Cortex A8, whereas the rbpi CPU is... a 700mhz(?) ARM11. it's therefore guaranteed to be at least twice as slow.
as the scope of the rhombus tech project goes way beyond just this one CPU Card or just one device, we'll be constantly on the lookout over the next decade and beyond for upgraded CPUs, and for new products to create. we'll also review the standards: EOMA-68 is just the first. i'll risk being responsible for causing brain-melt and provide you with another link, if that's ok. http://elinux.org/Embedded_Open_Modular_Architecture/EOMA-68
ha! spot the bug in the algorithm where the "" key did not work and i hit "submit" before noticing, yaay! i'm sure there will be plenty of slashdotters who notice that, but how many tech entrepreneurs will, eh? oh... they don't read slashdot....
Step 1: Read the question Step 2: Record current time Step 3: Think. Step 4: Re-examine current time. Step 5: If elapsed time 1.0 seconds, goto Step 3 Step 6: If answer to Step 1 != "yes", Goto Step 1.
uhnnn.... is this the same FBI that was to be involved with the *deliberate* disinformation "strategy" - if it can be called that - to put out complete whopper lies and try to back-track where they came from in order to catch "terrorists" and other criminals?
there's a program called backuppc which does the job very very effectively, even across multiple systems. [note: do not imagine for one second that the god you call windows has all the answers]. run yourself a 2nd system, even if it's a virtual machine, install debian gnu/linux in it and then run and configure backuppc.
backuppc uses MD5/SHA checksums to identify files, such that it stores only *one* copy of any given file. this occurs entirely automatically. given the size of the task you can expect it to take some considerable time, however even if it is interrupted the backup process can be restarted and it will happily chunder on from where it left off.
if you want to, backuppc can create "snapshots" for you. however given the sheer number of files i would not recommend you enable that feature unless a) absolutely necessary b) you've at least made one complete backup of the files!
realistically, you should have been running backuppc or something like it for some considerable number of years, now. backuppc and systems like it can do "incremental" backups very very efficiently... but the first time you ever run it is absolute hell.... well, that's going to be the case regardless of what system you use: you'll just have to bite the bullet.
backwards-compatible APIs requires the developers to maintain a long-term discipline, committing to at least a 10-year support lifetime for any API. if the underlying technology doesn't even offer that as a feature, let alone make it easy to do, guess what? they're not going to bother!
correction: committing to at least a 10-year support lifetime for *multiple versions* of any one API.
no, his complaint is that there are too many different ways of accessing different components, and that it would be really nice if everyone used a common one.
thank you for chipping in, here, gbj - but that's not quite it. what i was doing was supporting miguel's original assertion, that linux on the desktop has failed due to binary-level API non-interoperability (see the little example i gave about trying to run a gnome 1.0 binary widget on a gnome 3.0 system). and i describe a potential technology which, *if used*, *could* have solved that problem.
I think Linux already has this - its the file API, where "everything is a file" concept and you build your systems by piping inputs to outputs.
ah no: again, this is another example that is comparable to d-bus and to x11 messaging. files *don't* have - per se - the concept of "binary interface backwards-compatibility" built in to them. yes, sure, files can be used to transfer the messages, but unless those messages are used to ask "what version of the interface do you support?" and to go from there, it's of absolutely no real value and is missing the point.
An OO object model would be a bit restrictive and is definitely coming from a programmer viewpoint rather than a sysadmin one.
the full power of COM - when used properly - is *not* restrictive. at all. you do however have to cross a certain "pain threshold" in both your programming and also your outlook and perceptions - before being able to fully appreciate the power of COM. by the time you get to Visual Basic, for example, all that "pain" has *entirely* gone.
in fact, you end up with an entirely new problem, which is the one that microsoft now suffers from. the use of COM in Visual Basic is *so* easy and *so* transparent that not even the new developers who joined microsoft as the years went by truly truly understand - understood - it. so, they instead started talking about doing something called ".NET", and "Silverlight", entirely forgetting that the earlier success of microsoft was based on COM.
Incidentally, DCE was excellent, so it would be a good choice if Linux did decide upon a common API system, but that in itself would be against the concept of Linux.
yes. exactly. and there you have it, in a nutshell. linux on the desktop is failing... because there is no driving motivation to pull together and work together. isn't that sad? all that source code out there, and from one month to another, because of this failure to agree to use a common subsystem (in direct contrast to apple and microsoft *have* set a common subsystem), none of that code can really properly talk to any other bits of code.
So your complaint is that you don't know x11 messaging and dbus?
ahh, that's a fatal mistake to mention d-bus where i can hear it being said:) i'll deal with this first, then answer your question directly, ok?
back in 2005 i did a comparison of the d-bus specification and the DCE/RPC specification. the similarity was... unbelievable. i mean, truly, truly unbelievable. the people who wrote the d-bus specification could *literally* have taken the DCE/RPC specification, substituted different words and then published it as the d-bus specification. let me reiterate that, for emphasis, in a different way. *every* concept that is in d-bus is in DCE/RPC.
however, what d-bus does *not* have is the higher-level APIs. d-bus is so immature when you compare it to DCE/RPC (and then to DCOM which is built on top of DCE/RPC) that it is a child's toy by comparison. the main thing that d-bus is missing - the main benefit which you get from DCE/RPC and DCOM - is the IDL compiler.
d-bus expects you to hand-marshal all the data! you get a whole bunch of macros, and you're expected to make your own messages out of them! that's just so fucking shit! you'd actually be better off ripping out d-bus from every single application that has that piece of shit in it, and replacing it with 1500 lines of c code, implementing a unix domain socket, and a bunch of #ifdef macros e.g the SIVAL and SSVAL ones from samba's smb.h header file!
why is that?
because d-bus gives you the *expectation* that it's solving a problem, when in fact it's doing nothing of the sort. at least 1500 lines of c code and a few macros leaves you under no illusions that you still have a hell of a lot of work to do..... which finally provides some context which allows me to answer your question. d-bus DOES NOT provide a means to make it easy to do backwards-compatible interfaces. it doesn't even make it easy to make *one* interface, so of *course* developers go and change the API and throw out all backwards-compatibility.
what i'm saying is: you've entirely missed the point of what miguel is getting at, and what i am also emphasising. perhaps this is due to a lack of concrete examples. so let's make one, ok?
what do you imagine would happen if you took some component - say... a gnome "clock" widget that plugs into the taskbar - and by that i mean you took the *binary* not the source code - from Gnome 1.0 (whenever it was written - when was it - 15 years ago, now?) and tried to use it in Gnome 3.0?
what would happen? it would utterly, utterly fail, wouldn't it?
now, what miguel's pointing out is that even if you took code from *six months ago*, you have the same problem! and that the consequences of this, over the 15+ years in which linux desktop software has been developing - have burdened both the developers, the users and the gnu/linux distros - with constant problems that they're just getting fed up with.
contrast this with the fact - the FACT - that if you grabbed a random 20-year-old Microsoft OLE (COM) / Active-X (COM) DLL from anywhere off the internet (assuming you can find it), and you tried dropping that Active-X component into I.E. 10 or into the absolute latest-and-greatest version of microsoft office, guess what will happen? IT WILL FUCKING WELL WORK.... does that drive the point home? do you understand now that saying "you don't know how x11 messaging or d-bus work" is a) failing to appreciate that i know a fuck of a lot about inter-process communication b) entirely missing the point.
x11 messaging only works because it hasn't really changed significantly. even if you use x11 messaging for general-purpose communications, you *still* have to create backwards-compatible APIs, and i don't imagine that x11 messaging offers any significant assistance in doing that (otherwise i would have heard about it, a looong time ago).
it's real, real simple. the successful OSes have, at their heart, a highly effective "Common Object Model" of some description, which provides a) fully-compliant backwards compatibility across APIs, dating back even 20 years b) interoperability between applications and application components *regardless* of the language they're written in.
every f*****g time i raise this successful strategy - deployed by both microsoft (DCE/RPC and then DCOM) *and* apple (Objective-C has an Object Model built-in to the language) - on free software mailing lists, i get shouted down. i get told "that stuff is a piece of shit, why are you even bothering to mentioning it?"
now, the linux distros are paying the price of that arrogance, why is anyone even surprised?
firefox. firefox has a "COM-like" system which was "inspired" by microsoft's COM. it's called XPCOM. what XPCOM does *not* have is the ability to merge interfaces (they're called "coclasses"). that has two implications:
1) whenever there's a change to an interface, all backwards compatibility is lost. with coclasses you can have *both* the "old" interface as well as the "new" one, supported by the *same* application.
2) if you want to have "default values"... you can't. what XPCOM has to have instead is a highly-dubious modification which adds as an *extra* explicit argument into the actual function saying how many arguments are actually used! imagine if the people who wrote the ANSI-C++ standard said "oh yes, if you want the last arguments of any function call to be optional then the very first argument has to be an integer saying how many parameters there are", there would be people laughing at them for decades.
i've raised this with the mozilla foundation core developers at least twice. the first time i was told by one of the key subcontractors that coclasses were "too complicated" for the mozilla developers to understand. the second time, that person wasn't there: i raised it directly with the mozilla foundation core developers; they didn't understand, took it as personal criticism and then later on enacted very fascist censorship onto the mozilla mailing lists, preventing any further discussion.
so, that subcontractor was indeed right: the concept of coclasses *is* too complicated for the mozilla core developers to comprehend..... but it's not just the mozilla foundation developers.
the KDE team had an opportunity to replace DCOP with something more substantial, as part of the $10m E.U-grant-sponsored KDE4 redesign: i recommended that they start with FreeDCE and go from there.... and they didn't.
the Gnome team make extensive use of GObject, but GObject is a very very poor substitute for COM. only now with the GObject "Introspection" is it *beginning* to approach the capabilities of COM, but because GObject has no concept of co-classes, *again*, there is no way to have backwards-compatibility for APIs.
i won't even get into what happened with the webkit developers.
the bottom line is that time and time again, in every major engineering team behind each of the major projects which make up "a linux desktop" as we see it, there has been a fundamental failure to comprehend the power of having a strong base on which to create good successful software.
that success - stability of APIs and interoperability between components regardless of programming language - can *only* be achieved by using something like COM, with language bindings for every known major programming language, and support for "co-classes" that are then actually *used* - properly - by the developers.
this takes discipline, and i don't see any of the major free software projects getting this, any time soon.
miguel: i've raised FreeDCE with you, before. i know it was 10 years ago:) however, since then, i've learned that the WINE team have actually gone and made pretty much a complete implementation of both MSRPC *and* COM, including, i believe, a complete server implementation (albeit a basic one). they no longer require the installation of DCOM98.EXE for example which is a good sign. also i heard of a guy who managed to "extract" all that client-server code into a separate project: he called it "TangramCOM".
i have a simple question. why are these systems - and systems like them in the USA such as power grid systems - attached to the world-wide internet in the first place? surely people understand that critical systems must be physically isolated, yes? they do have two computers, one on each side of the room, yes? one set of computers controls the critical hardware, and the other set is for administrative purposes, to do email, surf for porn when the staff are bored and so on, yes? do these people in these companies, whether they be in iran, iraq, saudi arabia or the USA, not understand basic security procedures for running mission-critical systems??
ok, it's funny, because i've just been reviewing WebRTC. i was extremely excited to hear about it. i've been setting up videoconferencing systems on and off for some time. they've *always* had to be flash-based. if you've ever set up red5, you'll know it's a dog. now there's crtmpserver and there's even rtmplite and siprtmp: http://code.google.com/p/siprtmp/ - i just managed to get this to work a couple of days ago, with yate, thanks to the help of the people on freenode, in #yate
the problem with flash is this: back in 2008, flash was reasonably stable. but now, it's an absolute dog. flash under macosx on google chrome runs audio in "dalek" fashion. flash under gnu/linux, if ever you enable the webcam you *will* end up with an instant crash, because the video is read into a buffer that's the wrong size (you can see the picture jumping all over the place before the crash occurs).
and webex? i'd never heard of it until a couple of weeks ago: that crashes, too: at least once every 30 minutes. and you have to pay for it. also, it's a plugin that's only available for macosx and windows.
the bottom line is that the state of videoconferencing - ubiquitous videoconferencing that's easy to use - is in pretty deep shit. so i was *delighted* to hear of WebRTC.
unfortunately... *sigh* this was only about an hour ago... i spoke to the implementors on #webrtc about the standard, after finding that there's no way to select the microphone or the output. their response: we're not interested in listening to you. we are going to make this "secure". we have no interest in doing what everyone else in the industry has done. security is the absolute top priority.
so what that means is: if you create a phone call application, and you want the sound of the call to go out over speakers, and the call to come in on headphones - tough shit. why? because they want to make the *browser* UI (not a javascript API) select the audio output device - singular. likewise, if you wish to select different microphones - tough shit. why? because they want the *browser* UI to select one and *only* one mic source.
the reason stated (only about an hour ago)? "security". it's "not secure" to give information to web browsers, because people *might* write applications that abuse that information.
the fact that people *already* abuse cookies to track people very very accurately, and the fact that a UI popup could be made which says "do you wish to give this web site access to the list of audio devices?" then "do you wish to give this web site access to audio device N" were completely ignored.
so the opportunity to level the playing field - to take over the monopoly that flash has had for decades, and that skype has had for almost a decade - is being lost *not* by the WebRTC technology but by the people *implementing* that technology.
if the people implementing WebRTC in google chrome and firefox are the same people behind the WebRTC standard, then i am really not surprised to hear that microsoft is going ahead with an alternative standard.
much as i don't actually like microsoft's abusive dominance which we've all witnessed over the past two decades, i've spoken to the IE team a couple of times and i know that they really really do a hell of a good job, under difficult high-pressured circumstances: their HTML5 compliance is now second to none, for example, and they *still* get flak for it!:)
so the opportunity is being lost - by the people behind WebRTC - and i truly hope that microsoft's initiative will give them a good kick up the backside and get them to sort themselves out. sort yourselves out, damnit!
i forgot to mention: i also had to do a vehicle simulator. mostly that was using v-squared = u-squared + 2.a.s and all that, but i also had to do torque calculations, to force, back-caclulating to a maximum acceleration which was turned into a maximum power, limited, and turned back again. the reason for doing that is that you musn't over-spin the wheels by having too much acceleration. so it's quite complex stuff, but is definitely iterative loops and all. involves a hell of a lot of physics equations which luckily are all well-defined.
the original that i did 18 years ago (called SpecManager, for Detroit Diesel), was far more complex. that we had to do automatic torque converters as well as manual gearboxes. uunnnfortunately, with torque converters there are *four* parameters: torque+RPM on one side, and torque+RPM on the other. but what you actually get given at any one time is only *two* of the four values! you either know the torque+RPM on one side or the other, or you know the torque on both sides but not the RPMs on either side.... it was absolute hell.
anyway, i made a good guess, and picked an acceptable ratio that the torque+RPM would be at, and that turned out to be good enough to get the whole thing accurate to within 0.5% of real-world fuel economy (with one small error in the gear-change algorithm under very specific conditions).
but, again, yes: all that was definitely iterative programming loops - luckily an O(N) algorithm (approximately. there was a bit of game theory thrown in which made it O(N*M) where M was much smaller than N).
Slashdot Mirror
we'll have a dual-core CPU Card available once we've found both a SoC vendor willing to be open about their CPU design as well as a partner willing to make an at-cost EOMA-68 CPU Card or do a deal of some kind, ok? we'll get there, all right? :) /peace
In brief, keep up the good work, that sounds really good!
thank you, that's really appreciated. can i suggest you join the mailing list or just keep an eye on it via gmane or something, if you prefer? lots of people subscribe "no-mail" then lurk on gmane and they can then post if they want to, without filling up their mailbox. here's the subscription page:
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
feel free to ask anything you like, there, ok? or, ah, what might suit you: join the irc channel #arm-netbook on freenode. /peace
Kudos to you and your crew for getting even this far on a shoestring.
:) thanks. that's really appreciated. uh, i actually made a mistake: it's the board layout photo i released, not the schematics. biiiig difference.
Uh, the Pi is meant an educational and hobby platform. It has a bunch of slots and connectors. This thing is obviously a commercial product without a lot of slots or connectors that's meant to be embedded in a larger product.
Not being an embedded systems person, I'd be grateful if somebody linked examples of the kind of system that uses this kind of CPU card.
can't do that. can link you to planned and discussed products though:
http://elinux.org/Embedded_Open_Modular_Architecture/EOMA-68#Example_Motherboards
http://rhombus-tech.net/community_ideas/
the first will be a laptop. we have a deadline to meet of 10th october to get 25 prototype samples ready, for our client. yes. really. that soon.
The mailing list had some interesting discussions on the secrets, patents and companies behind this project
http://lists.phcomp.co.uk/pipermail/arm-netbook/2012-May/003950.html [phcomp.co.uk]
The supposedly "Open" EOMA-68 standard is a repurposed PCMCIA connector and PC-Card that is actually under "an undisclosed patent and the project had to make sure that everything produced fell under that patent so an undisclosed fee could be charged."
i notice that you're posting as anonymous coward. we had some trouble with a particular individual who promised to deliver, reneged on that promise and caused us a great deal of aggravation. the patents were mentioned very early on in the project and were raised again much later, during a fire-fighting exercise dealing with the shit raised by the vindictive pissed-off and self-serving individual.
to explain: the patents are there to protect people from physical harm due to the possibility of idiotic companies creating non-interoperable products that could potentially short-circuit things e.g. a lithium battery. if the scope of this project was to sell only 50,000 units maximum, we would not bother with the patents. however, given that the volume of units is expected to reach several million per year, there is no way in hell that we can leave this to "self-policing".
look up the story that i told about my uncle, Anthony Pickford, who was Smith Kline Beecham's Director at the time when some moronic companies in the UK started importing "clones" of one of SKB's drugs. the clone drugs were *KILLING* people; SKB had to move very quickly. they managed to solve it by suing the Inland Revenue when Customs and Excise refused to comply with a 3rd party discovery request for the Import Records. the case was taken very swiftly to the House of Lords, where, fortunately, SKB won and was able to obtain the records, contact the importers and get the killer drugs stopped. if they did not *have* the patents, there would be no way that they could stop people from being killed.
sometimes, patents can be used for good reasons. for someone who hates software patents and patents in general with a vengeance, that's really saying something.
so, anonymous coward: if you've got questions, anonymous coward, fucking well ask them and stop making accusations, please.
It's a schematic (actually, the picture shows a board layout)
shit. you're right. it is! no wonder the other guy said we'd be 6 months from release :) no, it's definitely a board layout. first samples will be available for testing by next week. definitely not 6 months from now.
It's not clear why you'd want an Allwinner A10 in a PCMCIA form factor. The Allwinner A10 has a sizable set of peripherals on-chip. Ethernet, HDMI, etc. Usually, boards for this part have a whole row of connectors. Bringing out the pins on a PCMCIA connector means you need another board to fan out the peripherals.
ah. right. this is covered here: http://elinux.org/Embedded_Open_Modular_Architecture
we wanted something that is user-installable and user-upgradeable. if we had wanted factory-installable (only) then we would a) not really have bothered at all, given the proliferation of offerings from direct-insight.co.uk and variscite.com and many many others b) we would have created something like the q-seven standard and, again, really to be honest, would not have bothered with that, either, because why create a competing standard?
no, you're missing a couple of points. one is that the A10 EOMA-68 CPU Card can operate stand-alone, powered by USB-OTG, booting from USB-OTG, NAND or Micro-SD as you choose, and having both HDMI out and Stereo Audio. that's not bad, right there.
the other point is that we picked interfaces that happen to be "common buses", that happen to all have backwards-compatible speed negotiation. 24-pin RGB/TTL you can drop down even to as low as 15 pin by ignoring the higher-res bits; you can reduce the clock-rate to run a 320x240 LCD or you can ramp it up to run 2048x2048 @ 30fps in full colour. USB2 goes all the way from 11mbit/sec to 480mbit/sec. SATA-II has down-level negotiation all the way to 150mbit/sec. I2C goes from something like 75khz up to 4mbit/sec or thereabouts. Gigabit Ethernet goes through 10 to 100 to 1000.
so there is a hell of a lot of thought gone into the selection of those interfaces, in order to keep the pin-count down. it was just pure luck that when you added 16 GPIOs and some power and ground that the pin-count came to *exactly* 68. jammy or what. and if you look at that interface set, it's *extremely* flexible and powerful. but i believe i know what you're saying: why didn't you make *all* the pins available? because if you've looked at the cost of user-hot-swappable 100-pin connectors, they're insanely expensive: $12 is not uncommon.
so instead, we're recommending the use of a low-cost STM32F on the other side (I/O Board side). we've tracked down the OpenEC2 project (originally the firmware for the OLPC XO-1) and intend to port it to RTEMS-lite, then extend it to provide Audio Drivers in the form of A/D and D/A converters, amongst other things. ST Micro actually recommend their 75mhz+ CPUs for use as Audio ICs. but it can pretty much cover everything. this practice is standard in x86 PCs (using an Embedded Controller) but is quite rare in the ARM world: normally you'd use the ARM CPU itself to do this job! but, because of the EOMA-68 "break", we can't do that. swings and roundabouts: it'll come out in the wash :)
I've been following this project for a while now, and it is going in a direction which I believe in.
thank you. i'm very encouraged to hear that.
I am getting tired of proprietary ARM hardware and software.
... you and me both. update from mjg on the Android-related GPL-violations situation of 18 months ago: it hasn't got any better. http://mjg59.dreamwidth.org/8991.html
that's actually an incorrect perception. the rhombus tech initiative was formed quite some time before the raspberry pi was conceived. we've just been applying a different strategy (zero-investment) which has resulted in some raather long delays as we've got up-to-speed.
The schematic is often the easiest part of the design. An EMC compliant PCB is usually harder; passing FCC/CE/* EMI compliance is harder; setting up for mass production is not for beginners either. Those guys just made the first step on a long road. And that's exactly why it's so hard to build hardware these days; the progress is so fast that by the time you are ready to manufacture the key parts are obsolete and out of production. Even if the parts are still available your design may be already obsolete because newer, better parts became available. It's either "design it under 3 months" or "do something else with your life."
you know what? i'm really glad you raised this point. it's *exactly* why we sub-divided the CPU Card from the actual device. independent development and product life-cycles for the CPU and the device! so yes, sure, the CPU becomes obsolete, but that's ok: you can just buy the latest CPU card... *without* having to throw away the entire product. so you've highlighted the very core of the strategy, here. it's not just about upgradeability, it's about being eco-conscious as well as providing redundancy without disrupting the user.
think about it: yes, sure, we're having a hard time getting the first CPU Card out, but you know what? it's just the first. it took 3 months to source just 5 connectors at reasonable prices (mostly because they are unusual: mid-mount HDMI, mid-mount audio, sub-1.8mm Micro-SD, mid-mount USB-OTG and the increasingly-obscure PCMCIA). but guess what? having found those suppliers, we won't have to do that again for subsequent CPU Cards, and we will have pre-established relationships by the time the 2nd CPU Card comes out.
also, with the 2nd and subsequent CPU Cards, we expect to actually have some profits made so that we can pay good people to work promptly and according to *our* timescales. one of the issues that we have is that we've got this far with *zero* investment. absolutely none. think about that for a moment. no money has changed hands; we are beholden to no-one, yet there are software engineers ready to get the OS onto the CPU Card, but not only that, the CPU Card Schematics have been made.
how is that even possible? we did deals, based on the strength of committment and the desire of our PRC State-Sponsored client to make use of the EOMA-68 solution and concept that we came up with. it's *perfect* for them.
so CE compliance will be covered by our client: they are big enough to be able to self-certify. FCC is more problematic: we're simply not going to even bother unless we receive an order from a USA/Canadian company of minimum 50k units, and the cost of the FCC Certification will be included in the quote. as the USA market is below 1/10th the size of the PRC market, we don't see this as being a problem.
but yes - the key here is that this first CPU Card is a heavy learning curve. we're on the lookout for faster and better CPU Cards, and we fully anticipate - especially with the Linaro-sign-ups such as TI, Samsung and Freescale creating fully open Schematics for the Origen, Pandaboard, IMX53QSB and the upcoming iMX6 - being able to very rapidly adapt those Open Schematics into EOMA-68 CPU Cards. what we would *really* like is for someone else to step forward and do that work, and we'd do a deal with them to introduce their product to our clients. that would be great. we much prefer to do these kinds of "cost-plus" deals. it's fairer to everyone who is involved.
This CPU card might form the core of another product, like a tablet,
or a laptop, smartphone, PDA, workstation, desktop, power-saving server, router, All-in-One LCD computer, Media Centre, IPTV, All-in-One keyboard computer, upgradeable camera, upgradeable videorecorder, games console, and many many more that have been discussed and we're always on the lookout for more - feel free to make suggestions on this page:
http://rhombus-tech.net/community_ideas/
http://elinux.org/Embedded_Open_Modular_Architecture/EOMA-68#Example_Motherboards
it's also worthwhile pointing out that we've added a DIL2-44 (2.5in IDE size) expansion header which gives access to the more common "engineer's" GPIO functions, such as an extra USB 480mb/sec, as well as AC97/I2S, dual-channel LVDS, VGA out and more; as well as adding a more "factory-style" FPC-45 which provides access to the kinds of functions that you'd see in commercial IPTV and other products (Dual Transport Streams; GPS; Smart Card, TV-IN and so on).
obviously, that "factory / engineering" mode, you'd not be able to get the standard 5mm height PCMCIA case on, but that's ok, because it's either factory-installed or being used for engineering, R&D or educational purposes. i've documented the full pin-outs here: http://rhombus-tech.net/allwinner_a10/orders/
but as a minimum you'd need a docking station to connect to everything.
not "everything": that would mean that without the docking station you'd not be able to gain access to the HDMI port, USB-OTG port, SD/MMC socket or the Audio Jack :) but i believe i know what you mean. you mean like this?
http://elinux.org/Embedded_Open_Modular_Architecture/EOMA-68/MiniEngineeringBoard
An odd number of cores. Perhaps they have 4 cores, each controlling 16 CPUs. Or 4 cores set aside for other purposes?
68 pins, not 68 cores :) of course, if you'd like to create a server box containing 64 or even 68 EOMA-68 CPU Cards, please feel free to do so! the idea was raised here: http://rhombus-tech.net/community_ideas/cluster_server/
i adapted the EOMA-68 standard after that discussion, and squeezed in 10/100/1000 Ethernet to make it more attractive. the Allwinner A10 doesn't have Gigabit Ethernet, but future CPU Cards definitely will.
no intro telling me what this is.
apologies. it's the first in a series of CPU Cards, based around a mass-volume modular computing initiative that allows both china factories and software (libre) developers the opportunity to work together to create desirable, affordable mass-volume computing appliances. at the risk of melting your brain with another link, here's the news article which provides some background as to why the project exists: http://www.itwire.com/opinion-and-analysis/open-sauce/52054-british-company-looks-to-create-cheap-open-platforms
allow me to go over what you wrote:
it is a PCMCIA (PC-card) sized integrated computer
correct. it can operate stand-alone via USB-OTG power, if needed. without the case on, there's access to the remaining interfaces of the A10 that we could not fit onto the 2 ends of the CPU Card.
designed to compete with the Raspberry Pi...
incorrect. this is more a commercial venture than an educational venture, with volumes approaching several million units a year. our goals almost accidentally encompass those of the raspberry pi (hence the reason why the developers were a bit rude to me on their forums a few months back: they feel threatened, unfortunately. can't be helped... *sigh*).
supposedly cheaper
incorrect. this perception is based on a misinterpretation that unfortunately was propagated through more channels than we have resources to spend time chasing down and correcting.
and faster.
correct. it's a 1ghz Cortex A8, whereas the rbpi CPU is... a 700mhz(?) ARM11. it's therefore guaranteed to be at least twice as slow.
as the scope of the rhombus tech project goes way beyond just this one CPU Card or just one device, we'll be constantly on the lookout over the next decade and beyond for upgraded CPUs, and for new products to create. we'll also review the standards: EOMA-68 is just the first. i'll risk being responsible for causing brain-melt and provide you with another link, if that's ok. http://elinux.org/Embedded_Open_Modular_Architecture/EOMA-68
https://sourceforge.net/tracker/?func=detail&aid=3565324&group_id=4421&atid=104421
ah fascinating - it's a bug in slashdot!
test less-than symbol: ""
test html entity: "<"
test backslash in front of less-than symbol: "\"
test two less-than symbols: ""
ha! spot the bug in the algorithm where the "" key did not work and i hit "submit" before noticing, yaay! i'm sure there will be plenty of slashdotters who notice that, but how many tech entrepreneurs will, eh? oh... they don't read slashdot....
Step 1: Read the question
Step 2: Record current time
Step 3: Think.
Step 4: Re-examine current time.
Step 5: If elapsed time 1.0 seconds, goto Step 3
Step 6: If answer to Step 1 != "yes", Goto Step 1.
uhnnn.... is this the same FBI that was to be involved with the *deliberate* disinformation "strategy" - if it can be called that - to put out complete whopper lies and try to back-track where they came from in order to catch "terrorists" and other criminals?
there's a program called backuppc which does the job very very effectively, even across multiple systems. [note: do not imagine for one second that the god you call windows has all the answers]. run yourself a 2nd system, even if it's a virtual machine, install debian gnu/linux in it and then run and configure backuppc.
backuppc uses MD5/SHA checksums to identify files, such that it stores only *one* copy of any given file. this occurs entirely automatically. given the size of the task you can expect it to take some considerable time, however even if it is interrupted the backup process can be restarted and it will happily chunder on from where it left off.
if you want to, backuppc can create "snapshots" for you. however given the sheer number of files i would not recommend you enable that feature unless a) absolutely necessary b) you've at least made one complete backup of the files!
realistically, you should have been running backuppc or something like it for some considerable number of years, now. backuppc and systems like it can do "incremental" backups very very efficiently... but the first time you ever run it is absolute hell.... well, that's going to be the case regardless of what system you use: you'll just have to bite the bullet.
backwards-compatible APIs requires the developers to maintain a long-term discipline, committing to at least a 10-year support lifetime for any API. if the underlying technology doesn't even offer that as a feature, let alone make it easy to do, guess what? they're not going to bother!
correction: committing to at least a 10-year support lifetime for *multiple versions* of any one API.
no, his complaint is that there are too many different ways of accessing different components, and that it would be really nice if everyone used a common one.
thank you for chipping in, here, gbj - but that's not quite it. what i was doing was supporting miguel's original assertion, that linux on the desktop has failed due to binary-level API non-interoperability (see the little example i gave about trying to run a gnome 1.0 binary widget on a gnome 3.0 system). and i describe a potential technology which, *if used*, *could* have solved that problem.
I think Linux already has this - its the file API, where "everything is a file" concept and you build your systems by piping inputs to outputs.
ah no: again, this is another example that is comparable to d-bus and to x11 messaging. files *don't* have - per se - the concept of "binary interface backwards-compatibility" built in to them. yes, sure, files can be used to transfer the messages, but unless those messages are used to ask "what version of the interface do you support?" and to go from there, it's of absolutely no real value and is missing the point.
An OO object model would be a bit restrictive and is definitely coming from a programmer viewpoint rather than a sysadmin one.
the full power of COM - when used properly - is *not* restrictive. at all. you do however have to cross a certain "pain threshold" in both your programming and also your outlook and perceptions - before being able to fully appreciate the power of COM. by the time you get to Visual Basic, for example, all that "pain" has *entirely* gone.
in fact, you end up with an entirely new problem, which is the one that microsoft now suffers from. the use of COM in Visual Basic is *so* easy and *so* transparent that not even the new developers who joined microsoft as the years went by truly truly understand - understood - it. so, they instead started talking about doing something called ".NET", and "Silverlight", entirely forgetting that the earlier success of microsoft was based on COM.
Incidentally, DCE was excellent, so it would be a good choice if Linux did decide upon a common API system, but that in itself would be against the concept of Linux.
yes. exactly. and there you have it, in a nutshell. linux on the desktop is failing... because there is no driving motivation to pull together and work together. isn't that sad? all that source code out there, and from one month to another, because of this failure to agree to use a common subsystem (in direct contrast to apple and microsoft *have* set a common subsystem), none of that code can really properly talk to any other bits of code.
So your complaint is that you don't know x11 messaging and dbus?
ahh, that's a fatal mistake to mention d-bus where i can hear it being said :) i'll deal with this first, then answer your question directly, ok?
back in 2005 i did a comparison of the d-bus specification and the DCE/RPC specification. the similarity was... unbelievable. i mean, truly, truly unbelievable. the people who wrote the d-bus specification could *literally* have taken the DCE/RPC specification, substituted different words and then published it as the d-bus specification. let me reiterate that, for emphasis, in a different way. *every* concept that is in d-bus is in DCE/RPC.
however, what d-bus does *not* have is the higher-level APIs. d-bus is so immature when you compare it to DCE/RPC (and then to DCOM which is built on top of DCE/RPC) that it is a child's toy by comparison. the main thing that d-bus is missing - the main benefit which you get from DCE/RPC and DCOM - is the IDL compiler.
d-bus expects you to hand-marshal all the data! you get a whole bunch of macros, and you're expected to make your own messages out of them! that's just so fucking shit! you'd actually be better off ripping out d-bus from every single application that has that piece of shit in it, and replacing it with 1500 lines of c code, implementing a unix domain socket, and a bunch of #ifdef macros e.g the SIVAL and SSVAL ones from samba's smb.h header file!
why is that?
because d-bus gives you the *expectation* that it's solving a problem, when in fact it's doing nothing of the sort. at least 1500 lines of c code and a few macros leaves you under no illusions that you still have a hell of a lot of work to do. .... which finally provides some context which allows me to answer your question. d-bus DOES NOT provide a means to make it easy to do backwards-compatible interfaces. it doesn't even make it easy to make *one* interface, so of *course* developers go and change the API and throw out all backwards-compatibility.
what i'm saying is: you've entirely missed the point of what miguel is getting at, and what i am also emphasising. perhaps this is due to a lack of concrete examples. so let's make one, ok?
what do you imagine would happen if you took some component - say... a gnome "clock" widget that plugs into the taskbar - and by that i mean you took the *binary* not the source code - from Gnome 1.0 (whenever it was written - when was it - 15 years ago, now?) and tried to use it in Gnome 3.0?
what would happen? it would utterly, utterly fail, wouldn't it?
now, what miguel's pointing out is that even if you took code from *six months ago*, you have the same problem! and that the consequences of this, over the 15+ years in which linux desktop software has been developing - have burdened both the developers, the users and the gnu/linux distros - with constant problems that they're just getting fed up with.
contrast this with the fact - the FACT - that if you grabbed a random 20-year-old Microsoft OLE (COM) / Active-X (COM) DLL from anywhere off the internet (assuming you can find it), and you tried dropping that Active-X component into I.E. 10 or into the absolute latest-and-greatest version of microsoft office, guess what will happen? IT WILL FUCKING WELL WORK. ... does that drive the point home? do you understand now that saying "you don't know how x11 messaging or d-bus work" is a) failing to appreciate that i know a fuck of a lot about inter-process communication b) entirely missing the point.
x11 messaging only works because it hasn't really changed significantly. even if you use x11 messaging for general-purpose communications, you *still* have to create backwards-compatible APIs, and i don't imagine that x11 messaging offers any significant assistance in doing that (otherwise i would have heard about it, a looong time ago).
backwards-compatibl
it's real, real simple. the successful OSes have, at their heart, a highly effective "Common Object Model" of some description, which provides a) fully-compliant backwards compatibility across APIs, dating back even 20 years b) interoperability between applications and application components *regardless* of the language they're written in.
every f*****g time i raise this successful strategy - deployed by both microsoft (DCE/RPC and then DCOM) *and* apple (Objective-C has an Object Model built-in to the language) - on free software mailing lists, i get shouted down. i get told "that stuff is a piece of shit, why are you even bothering to mentioning it?"
now, the linux distros are paying the price of that arrogance, why is anyone even surprised?
firefox. firefox has a "COM-like" system which was "inspired" by microsoft's COM. it's called XPCOM. what XPCOM does *not* have is the ability to merge interfaces (they're called "coclasses"). that has two implications:
1) whenever there's a change to an interface, all backwards compatibility is lost. with coclasses you can have *both* the "old" interface as well as the "new" one, supported by the *same* application.
2) if you want to have "default values"... you can't. what XPCOM has to have instead is a highly-dubious modification which adds as an *extra* explicit argument into the actual function saying how many arguments are actually used! imagine if the people who wrote the ANSI-C++ standard said "oh yes, if you want the last arguments of any function call to be optional then the very first argument has to be an integer saying how many parameters there are", there would be people laughing at them for decades.
i've raised this with the mozilla foundation core developers at least twice. the first time i was told by one of the key subcontractors that coclasses were "too complicated" for the mozilla developers to understand. the second time, that person wasn't there: i raised it directly with the mozilla foundation core developers; they didn't understand, took it as personal criticism and then later on enacted very fascist censorship onto the mozilla mailing lists, preventing any further discussion.
so, that subcontractor was indeed right: the concept of coclasses *is* too complicated for the mozilla core developers to comprehend. .... but it's not just the mozilla foundation developers.
the KDE team had an opportunity to replace DCOP with something more substantial, as part of the $10m E.U-grant-sponsored KDE4 redesign: i recommended that they start with FreeDCE and go from there.... and they didn't.
the Gnome team make extensive use of GObject, but GObject is a very very poor substitute for COM. only now with the GObject "Introspection" is it *beginning* to approach the capabilities of COM, but because GObject has no concept of co-classes, *again*, there is no way to have backwards-compatibility for APIs.
i won't even get into what happened with the webkit developers.
the bottom line is that time and time again, in every major engineering team behind each of the major projects which make up "a linux desktop" as we see it, there has been a fundamental failure to comprehend the power of having a strong base on which to create good successful software.
that success - stability of APIs and interoperability between components regardless of programming language - can *only* be achieved by using something like COM, with language bindings for every known major programming language, and support for "co-classes" that are then actually *used* - properly - by the developers.
this takes discipline, and i don't see any of the major free software projects getting this, any time soon.
miguel: i've raised FreeDCE with you, before. i know it was 10 years ago :) however, since then, i've learned that the WINE team have actually gone and made pretty much a complete implementation of both MSRPC *and* COM, including, i believe, a complete server implementation (albeit a basic one). they no longer require the installation of DCOM98.EXE for example which is a good sign. also i heard of a guy who managed to "extract" all that client-server code into a separate project: he called it "TangramCOM".
i have a simple question. why are these systems - and systems like them in the USA such as power grid systems - attached to the world-wide internet in the first place? surely people understand that critical systems must be physically isolated, yes? they do have two computers, one on each side of the room, yes? one set of computers controls the critical hardware, and the other set is for administrative purposes, to do email, surf for porn when the staff are bored and so on, yes? do these people in these companies, whether they be in iran, iraq, saudi arabia or the USA, not understand basic security procedures for running mission-critical systems??
ok, it's funny, because i've just been reviewing WebRTC. i was extremely excited to hear about it. i've been setting up videoconferencing systems on and off for some time. they've *always* had to be flash-based. if you've ever set up red5, you'll know it's a dog. now there's crtmpserver and there's even rtmplite and siprtmp: http://code.google.com/p/siprtmp/ - i just managed to get this to work a couple of days ago, with yate, thanks to the help of the people on freenode, in #yate
the problem with flash is this: back in 2008, flash was reasonably stable. but now, it's an absolute dog. flash under macosx on google chrome runs audio in "dalek" fashion. flash under gnu/linux, if ever you enable the webcam you *will* end up with an instant crash, because the video is read into a buffer that's the wrong size (you can see the picture jumping all over the place before the crash occurs).
and webex? i'd never heard of it until a couple of weeks ago: that crashes, too: at least once every 30 minutes. and you have to pay for it. also, it's a plugin that's only available for macosx and windows.
the bottom line is that the state of videoconferencing - ubiquitous videoconferencing that's easy to use - is in pretty deep shit. so i was *delighted* to hear of WebRTC.
unfortunately... *sigh* this was only about an hour ago... i spoke to the implementors on #webrtc about the standard, after finding that there's no way to select the microphone or the output. their response: we're not interested in listening to you. we are going to make this "secure". we have no interest in doing what everyone else in the industry has done. security is the absolute top priority.
so what that means is: if you create a phone call application, and you want the sound of the call to go out over speakers, and the call to come in on headphones - tough shit. why? because they want to make the *browser* UI (not a javascript API) select the audio output device - singular. likewise, if you wish to select different microphones - tough shit. why? because they want the *browser* UI to select one and *only* one mic source.
the reason stated (only about an hour ago)? "security". it's "not secure" to give information to web browsers, because people *might* write applications that abuse that information.
the fact that people *already* abuse cookies to track people very very accurately, and the fact that a UI popup could be made which says "do you wish to give this web site access to the list of audio devices?" then "do you wish to give this web site access to audio device N" were completely ignored.
so the opportunity to level the playing field - to take over the monopoly that flash has had for decades, and that skype has had for almost a decade - is being lost *not* by the WebRTC technology but by the people *implementing* that technology.
if the people implementing WebRTC in google chrome and firefox are the same people behind the WebRTC standard, then i am really not surprised to hear that microsoft is going ahead with an alternative standard.
much as i don't actually like microsoft's abusive dominance which we've all witnessed over the past two decades, i've spoken to the IE team a couple of times and i know that they really really do a hell of a good job, under difficult high-pressured circumstances: their HTML5 compliance is now second to none, for example, and they *still* get flak for it! :)
so the opportunity is being lost - by the people behind WebRTC - and i truly hope that microsoft's initiative will give them a good kick up the backside and get them to sort themselves out. sort yourselves out, damnit!
i forgot to mention: i also had to do a vehicle simulator. mostly that was using v-squared = u-squared + 2.a.s and all that, but i also had to do torque calculations, to force, back-caclulating to a maximum acceleration which was turned into a maximum power, limited, and turned back again. the reason for doing that is that you musn't over-spin the wheels by having too much acceleration. so it's quite complex stuff, but is definitely iterative loops and all. involves a hell of a lot of physics equations which luckily are all well-defined.
the original that i did 18 years ago (called SpecManager, for Detroit Diesel), was far more complex. that we had to do automatic torque converters as well as manual gearboxes. uunnnfortunately, with torque converters there are *four* parameters: torque+RPM on one side, and torque+RPM on the other. but what you actually get given at any one time is only *two* of the four values! you either know the torque+RPM on one side or the other, or you know the torque on both sides but not the RPMs on either side.... it was absolute hell.
anyway, i made a good guess, and picked an acceptable ratio that the torque+RPM would be at, and that turned out to be good enough to get the whole thing accurate to within 0.5% of real-world fuel economy (with one small error in the gear-change algorithm under very specific conditions).
but, again, yes: all that was definitely iterative programming loops - luckily an O(N) algorithm (approximately. there was a bit of game theory thrown in which made it O(N*M) where M was much smaller than N).