That could be a problem. If it's successful, people will associate the concept with Intel and assume that eoma is a cheap ripoff. Also, with Intel controlling it, you can bet x86 will dominate it.
Our response should be to publicly urge Intel to use an eoma standard, to ensure architecture agnosticism and that there isn't a conflict of interest.
-- Julie Marchant https://onpon4.github.io
On Jan 5, 2017 12:38 PM, Alain Williams addw@phcomp.co.uk wrote:
I wonder where they got the idea from:
http://www.bbc.co.uk/news/technology-38515472
http://www.intel.co.uk/content/www/uk/en/compute-card/intel-compute-card.htm...
-- Alain Williams Linux/GNU Consultant - Mail systems, Web sites, Networking, Programmer, IT Lecturer. +44 (0) 787 668 0256 http://www.phcomp.co.uk/ Parliament Hill Computers Ltd. Registration Information: http://www.phcomp.co.uk/contact.php #include <std_disclaimer.h>
arm-netbook mailing list arm-netbook@lists.phcomp.co.uk http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook Send large attachments to arm-netbook@files.phcomp.co.uk
--- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68
On Thu, Jan 5, 2017 at 6:05 PM, Julie Marchant onpon4@riseup.net wrote:
That could be a problem. If it's successful, people will associate the concept with Intel and assume that eoma is a cheap ripoff. Also, with Intel controlling it, you can bet x86 will dominate it.
... yyup.
Our response should be to publicly urge Intel to use an eoma standard, to ensure architecture agnosticism and that there isn't a conflict of interest.
if they've actually reused the PCMCIA connectors then that's an incompatibility issue which would be a Certification Mark infringment [risk of bringing EOMA68 into disrepute through electrical or electronic incompatibility].
l.
On 05/01/17 18:05, Julie Marchant wrote:
That could be a problem. If it's successful, people will associate the concept with Intel and assume that eoma is a cheap ripoff. Also, with Intel controlling it, you can bet x86 will dominate it.
Our response should be to publicly urge Intel to use an eoma standard, to ensure architecture agnosticism and that there isn't a conflict of interest.
I would expect them to laugh at you.
Why would they want to cripple their product by restricting themselves to the set of interfaces Luke has chosen.
Intel operates under a totally different set of constraints from Luke. If Luke wants to make a successor to his compute cards he needs to find a new SoC that has the right set of interfaces. If Intel wants to make a successor to their compute cards they can ensure that one of their upcoming SoCs has the right set of interfaces.
--- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68
On Thu, Jan 5, 2017 at 6:48 PM, peter green plugwash@p10link.net wrote:
On 05/01/17 18:05, Julie Marchant wrote:
That could be a problem. If it's successful, people will associate the concept with Intel and assume that eoma is a cheap ripoff. Also, with Intel controlling it, you can bet x86 will dominate it.
Our response should be to publicly urge Intel to use an eoma standard, to ensure architecture agnosticism and that there isn't a conflict of interest.
I would expect them to laugh at you.
Why would they want to cripple their product by restricting themselves to the set of interfaces Luke has chosen.
?? peter!!
Intel operates under a totally different set of constraints from Luke. If Luke wants to make a successor to his compute cards he needs to find a new SoC that has the right set of interfaces. If Intel wants to make a successor to their compute cards they can ensure that one of their upcoming SoCs has the right set of interfaces.
which are, in your opinion, the "right set of interfaces"? serious question. if you're going to make such comments, you'd better be prepared to back them up and be prepared to justify them with a *REALLY* thorough analysis.
l.
On Thu, Jan 5, 2017 at 1:50 PM, Luke Kenneth Casson Leighton lkcl@lkcl.net wrote:
which are, in your opinion, the "right set of interfaces"? serious question. if you're going to make such comments, you'd better be prepared to back them up and be prepared to justify them with a *REALLY* thorough analysis.
I think all he meant was that Intel can pick whatever interfaces they want for the standard that they think will be relatively future-proof. They don't have to worry about finding SoCs with those interfaces, because they manufacture the SoCs - they just have to decide on them at the start.
It's a shame that none of the previous EOMA-68 devices got off the ground before Intel pulled this out - "hey this already exists" would've been a serious advantage for EOMA-68 as a standard.
On Thu, Jan 5, 2017 at 2:22 PM, Jonathan Frederickson silverskullpsu@gmail.com wrote:
On Thu, Jan 5, 2017 at 1:50 PM, Luke Kenneth Casson Leighton lkcl@lkcl.net wrote:
which are, in your opinion, the "right set of interfaces"? serious question. if you're going to make such comments, you'd better be prepared to back them up and be prepared to justify them with a *REALLY* thorough analysis.
I think all he meant was that Intel can pick whatever interfaces they want for the standard that they think will be relatively future-proof. They don't have to worry about finding SoCs with those interfaces, because they manufacture the SoCs - they just have to decide on them at the start.
--- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68
On Thu, Jan 5, 2017 at 7:54 PM, Jonathan Frederickson silverskullpsu@gmail.com wrote:
It's a shame that none of the previous EOMA-68 devices got off the ground before Intel pulled this out -
that's what i thought, initially... but then i realised that it's better with a long-term standard to get it right than to release before the standard's ready.
standards have *ONE SHOT* at getting it right. make even one single mistake and that's it, nobody will trust the standard - EVER (they also won't trust you, either).
look up my analysis of the 96boards consumer standard, and the CEO's response, for an example.
l.
On 05/01/17 18:50, Luke Kenneth Casson Leighton wrote:
Why would they want to cripple their product by restricting themselves to the set of interfaces Luke has chosen.
?? peter!!
Intel operates under a totally different set of constraints from Luke. If Luke wants to make a successor to his compute cards he needs to find a new SoC that has the right set of interfaces. If Intel wants to make a successor to their compute cards they can ensure that one of their upcoming SoCs has the right set of interfaces.
which are, in your opinion, the "right set of interfaces"? serious question. if you're going to make such comments, you'd better be prepared to back them up and be prepared to justify them with a *REALLY* thorough analysis.
If you look through the history of this list you will find the evolution of EOMA68 is a battle to find a compromise between
1. Interfaces that are useful. 2. Interfaces that are ubiquitous on SoCs today 3. Interfaces that are likely to be ubiquitous on SoCs tomorrow. 4. Interfaces that fit within the pins of a pre-existing economical connector.
Intel doesn't have to worry nearly as much about 2 through 4 as you do. They have no reason to make it easy for competitors to make compatible products. They can ensure that their own future SoCs retain the Interfaces previous ones had. They think and work on a scale where custom connectors are an economical option.
Of course this also means they have a much higher threshold of success. A product line with hundreds of thousands of sales would be a big success for someone like you but would likely be considered a flop for them.
If I was in their place I would be including PCIe, SATA and Ethernet (likely in some kind of MII form so the card isn't burdened with the cost of a transceiver).
--- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68
On Thu, Jan 5, 2017 at 7:40 PM, peter green plugwash@p10link.net wrote:
On 05/01/17 18:50, Luke Kenneth Casson Leighton wrote:
Why would they want to cripple their product by restricting themselves to the set of interfaces Luke has chosen.
?? peter!!
Intel operates under a totally different set of constraints from Luke. If Luke wants to make a successor to his compute cards he needs to find a new SoC that has the right set of interfaces. If Intel wants to make a successor to their compute cards they can ensure that one of their upcoming SoCs has the right set of interfaces.
which are, in your opinion, the "right set of interfaces"? serious question. if you're going to make such comments, you'd better be prepared to back them up and be prepared to justify them with a *REALLY* thorough analysis.
If you look through the history of this list you will find the evolution of EOMA68 is a battle to find a compromise between
- Interfaces that are useful.
- Interfaces that are ubiquitous on SoCs today
- Interfaces that are likely to be ubiquitous on SoCs tomorrow.
- Interfaces that fit within the pins of a pre-existing economical
connector.
sounds like a reasonable set of requirements. keep going. you've started so you're going to have to go through with a full evaluation.
If I was in their place I would be including PCIe, SATA and Ethernet (likely in some kind of MII form so the card isn't burdened with the cost of a transceiver).
ok so those are the set you're going with? what about video, sound, GPIO, low-speed peripherals and sensors?
i'm not letting you off the hook here after you said that EOMA68's interfaces are "crippled", peter.
l.
I don't think the Intel announcement is bad news. Firstly it validates/builds recognition of the general idea, which may be helpful in some quarters. Second, there are plenty of people that will want the cheap, low power version, which means ARM. Intel can't do that. And they hate really pushing cheap stuff, in case it undercuts the expensive stuff.
As you were...
On Thu, Jan 5, 2017 at 9:24 PM, Luke Kenneth Casson Leighton lkcl@lkcl.net wrote:
i'm not letting you off the hook here after you said that EOMA68's interfaces are "crippled", peter.
ok, so can you see what i did, peter? you laid down a challenge (to do better)... and after three days, you've not responded. you *provisionally* described an alternative standard... but did not follow through.
*that's* what makes the difference, here. it's *not enough* to say "the standard you came up with is rubbish", you have to *follow through*, and if you can't follow through then it's.... you know what i'm trying to say?
what you *should* have said, is:
"i appreciate all the hard work and persistence that you've shown, luke, and how comprehensively you've worked on designing EOMA68, making tough decisions and comprehensive evaluations that, each time you removed an interface you had to throw away thousands of dollars of money and you also made sure that you kept everybody informed, solicited people for ideas and reviews of each decision, and i *do* recall you saying that this is just the first standard in the series and that you're deliberately creating one which is 'within reach' of a libre engineer *and* uses SoCs that are actually accessible rather than being cartelled or require NDAs and much more, BUT...."
... and *then* went into "i still feel that the EOMA68 interfaces are crippled", i would have gone, "yeahh, i know... tell you what: i would really like to design the next standard for a future Card, how about we start that now?"
... which would have been a _much_ less confrontational way to introduce the topic you wanted, wouldn't it?
ehn?
*rueful*....
l.
On 08/01/17 12:58, Luke Kenneth Casson Leighton wrote:
On Thu, Jan 5, 2017 at 9:24 PM, Luke Kenneth Casson Leighton lkcl@lkcl.net wrote:
i'm not letting you off the hook here after you said that EOMA68's interfaces are "crippled", peter.
ok, so can you see what i did, peter? you laid down a challenge (to do better)... and after three days, you've not responded. you *provisionally* described an alternative standard... but did not follow through.
*that's* what makes the difference, here. it's *not enough* to say "the standard you came up with is rubbish", you have to *follow through*, and if you can't follow through then it's.... you know what i'm trying to say?
The compromises you made are a result of your goals. You wanted a standard that could be implemented with virtually any cheap SoC. That basically forced you into the decisions to use USB and parallel RGB.
Unfortunately USB has a reputation for poor performance and reliability. Some of this is possibly the fault of the USB standards themselves, some is a result of crappy implementations.
Intel has different goals, their job is to make something that takes best advantage of their own current and future products. EOMA68 does not do that, it drags it down to the lowest common denominator. As such I believe that by adopting EOMA68 Intel would be crippling their product. I gave some examples of interfaces I think Intel should include that were unsuitable for EOMA68.
I don't know exactly what Interfaces it would be best for Intel to include, that would require knowing both full details of the chips they plan to use in their current cards as well as their future roadmaps (if they have something on their SoCs today but plan to drop it in the future it would be stupid for them to put it on their compute cards).
2017-01-09 0:08 GMT+01:00 peter green plugwash@p10link.net:
On 08/01/17 12:58, Luke Kenneth Casson Leighton wrote:
On Thu, Jan 5, 2017 at 9:24 PM, Luke Kenneth Casson Leighton lkcl@lkcl.net wrote:
i'm not letting you off the hook here after you said that EOMA68's
interfaces are "crippled", peter.
ok, so can you see what i did, peter? you laid down a challenge (to do better)... and after three days, you've not responded. you *provisionally* described an alternative standard... but did not follow through.
*that's* what makes the difference, here. it's *not enough* to say "the standard you came up with is rubbish", you have to *follow through*, and if you can't follow through then it's.... you know what i'm trying to say?
The compromises you made are a result of your goals. You wanted a standard that could be implemented with virtually any cheap SoC. That basically forced you into the decisions to use USB and parallel RGB.
Unfortunately USB has a reputation for poor performance and reliability. Some of this is possibly the fault of the USB standards themselves, some is a result of crappy implementations.
Examples please.
If USB had such a bad track record then why is it the most used peripheral interface?
And which part of the USB standard? The physical interface or the communication protocols?
Intel has different goals, their job is to make something that takes best advantage of their own current and future products. EOMA68 does not do that, it drags it down to the lowest common denominator. As such I believe that by adopting EOMA68 Intel would be crippling their product. I gave some examples of interfaces I think Intel should include that were unsuitable for EOMA68.
The lowest common denominator is what's going to get this running. Everyone can join in with almost everything. You could even create a EOMA Card with a beefy Microcontroller.
Once everyone is in, new interfaces can be chosen/developed for the next version/type.
I don't know exactly what Interfaces it would be best for Intel to include, that would require knowing both full details of the chips they plan to use in their current cards as well as their future roadmaps (if they have something on their SoCs today but plan to drop it in the future it would be stupid for them to put it on their compute cards).
Intel could force a "new" standard by flooding or hyping the market. That would require every other vendor to follow the Intel route.
For other company's to follow that usually comes in two tracks: 1. Intel has made a success en the they "chime" in on the succes 2. Intel actively recruits "partners" to co-develop products
But I don't think so. Intel is desperate to find new grounds and are shooting with hail. It'll surprise me if they are still around after ten years.
1. Desktop and Laptop markets are shrinking. 2. Server market is shifting to better Power/Watt ratios. ARM is gaing. The market is opening again to other CPU architectures becaus of Saas offerings. 3. Computing market is shifting to GPU's. 4. Intel failed at the mobile market. To power hungry/To late. 5. Intel failed at the IoT market. To power hungry/To late.
arm-netbook mailing list arm-netbook@lists.phcomp.co.uk http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook Send large attachments to arm-netbook@files.phcomp.co.uk
arm-netbook@lists.phcomp.co.uk
-
Boris Barbour -
Jonathan Frederickson -
Julie Marchant -
Luke Kenneth Casson Leighton -
mike.valk＠gmail.com -
peter green