[Arm-netbook] EOMA server standard

[Gordan Bobic]

On 10/26/2012 07:05 PM, luke.leighton wrote:
> On Fri, Oct 26, 2012 at 5:33 PM, Roman Mamedov<rm at romanrm.ru>  wrote:
>> On Fri, 26 Oct 2012 17:20:32 +0100
>> "luke.leighton"<luke.leighton at gmail.com>  wrote:
>>
>>>   ok, i'm not sure what you're saying, here, roman, unless it is that
>>> yes, someone would read the writing on the box, "has 8 cores, is EOMA
>>> server standard compliant" but beyond that would be unlikely to read
>>> further about how many ports were on the connector.
>>
>> I meant to me it would seem entirely normal to have whole blocks of
>> functionality optional for implementation on the card, e.g. I could see a lot
>> of potential use for a card that leaves all of the RGB and HDMI and video and
>> audio and USB and whatever other irrelevant in a particular task crap^W pins
>> as NC (Not Connected), only implementing for example Ethernet.
>
>   ok - the purpose of these discussions is to guess/identify if there
> are any market segments where that kind of thing (a desire to ignore
> entire sets of interfaces) is so common that it's worthwhile making a
> completely separate standard for it, in order to reduce costs and not
> have peoples' money wasted on providing stuff that's never going to be
> used.
>
>> The connector standard can stay the same across all boards, but reading the
>> actual specs of the card you are getting (what it actually implements, and
>> does it implement things you need) should be absolutely expected from a
>> purchasing user, just as people today know basic things like how many cores in
>> the x86 CPU they are getting, how much RAM and HDD in their new PC, etc.
>
>   not good enough.  no.  i totally disagree.  i feel that they should
> be able to read up *once* on EOMA-{insertstandardhere}, then go to a
> store, glance at the specs "how much RAM, how many cores" and see the
> words EOMA-{insertstandardhere} and *know* that that means
> "non-optional interfaces A, B and C" are provided.
>
>   they should *not* have to read the fine print.  i fundamentally
> disagree with you that they should be forced to read and go "is it
> EOMAv5000001.00001 or is it EOMAv500002.2393123" because they're just
> going to go "fuckit, i don't care, this is too hard to understand:
> let's just go buy a rack of x86 1U servers and shove them in".

I'm not sure the tradeoff is worth it. Instead you are sacrificing 
backward/forward compatibility and still requiring the users to read the 
number behind the EOMA standard to see if it'll fit into their chassis 
(e.g. EOMA68 vs EOMA136). Maybe if you make sure that an EOMA68 would 
fit into the EOMA136 chassis (only using 1 slot instead of both), but 
otherwise you're back to the same problem just presented differently.

Gordan