wolfgang at openmoko.com
Sat Feb 16 08:54:53 CET 2008
> ... and what's the quantities you want to buy. I think if we could
> buy their whole company, the openness should not be an issue anyway.
> But before that happens, ...
Tony, your explanation settles this topic once and for all...
Way to go!
On Feb 16, 2008, at 12:42 PM, Neng-Yu Tu (Tony Tu) wrote:
> joerg ??:
>> Am Fr 15. Februar 2008 schrieb Brandon Kruse:
>>> In that case it is not an open phone or platform.
>> It's a philosophical question, where "open" has it's limits. E.g.
>> you probably consider a plain vanilla x86 GNU/linux desktop system
>> to be pretty much "true open". However i guess you have no idea at
>> all of the firmware that's managing your harddisk in this system.
>> That's for a simple reason: IDE interface is age old (and so all
>> HD's (SATA, SCSII) inherited this way we are looking at these
>> devices), it is "just working", and it's well documented. Virtually
>> nobody cares about the firmware behind this interface, mainly
>> because it doesn't have a chance to stop you from doing anything
>> you like on the _main_system_. I'm almost certain there's a hacker
>> somewhere out there, who likes to mod his HD so the head motors
>> will produce funny sounds, and another one thinks he can tune
>> transfer rates even another 10k/s. However i never seen FOSS HD
> When things down to that low level, it's not only firmware issue. It
> also about chip selection for specific design. For example, every HD
> has some write cache mechanism in firmware, but some of read/wirte
> acceleron also chipset related, some chip vender's read/write cache
> command for SDRAM just faster and stable than others. And you will
> need these details specification to do the hardware ans firmware
> Chip selection also is the balance of performance/usability/price/
> marketing, especially for mass production products like hard disk,
> user won't even notice the changes on chips and cause of change chips.
> And transfer rate is a myth: means write into cache/or write on the
> disk and then verified it write correct. It has some many detais for
> a single bit from keyboard to your hard disk. If anyone could get
> 10% transfer faster algorithm for any hard disk, no vendor would
> refuse it :)
>>> It is well worth the investigation to go fully open somehow IMO.
>> Sure. But it's a silly idea to try and force the subsystem
>> manufacturers by refusing to support their closed source firmware
>> updates. When Seagate comes with a DOS-only firmware updater to add
>> some cool new features to their drives, OM says "No, it's not
>> FOSS!". Seagate (or here, the chip fabs) don't care. But OM
>> deprives NEO owners of any means to have a new firmware for these
>> subsystems. If a user doesn't like to have closed source on his
>> device, she is free delete or not install it. But OM will not
>> achieve anything by refusing to provide closed source drivers. I
>> think all they get is a huge number of returns, or less sales (at
>> least for me). And OM(!) isn't willing or able to provide circuit
>> diagrams, so any open drivers are extremely hard to develop. In my
>> opinion they can't do both, refuse to support closed source updates
>> *and* keep the hw specs closed. Not if they care about their
>> Not to mention, NEO will not be "open" at all as long as the
>> hardware is a 'big mystery'. A laugh to start with closed firmware
> Most function on GTA was exist in module format, and do a lot
> negotiation with vendor to open their document or firmware update
> utility. It is not OM say: We want this open. Then the vendor say:
> no problem, just open it. Usually comes with the answer that: Well,
> we need to ask our legal department first, and what's the quantities
> you want to buy. I think if we could buy their whole company, the
> openness should not be an issue anyway. But before that happens, we
> have to through long negotiation for each of the components for
> better hardware openness.
> I think GTA is not as complex as ps3 or close hardware as Aphone,
> you could almost ask any question in the kernel development mailing
> list for the details for hardware related except ask for full
> schematics directly :)
> I could not speak for OM, but open anything we did is the target,
> also the times we spent to talk with vendors, and we will keep
> persuade hardware vendor/industries anyway :)
>>> But I guess we could be like olpc and have a MOSTLY open platform
>>> (wifi chip is not, as you could have guessed)
>> I'd like it more to see OM pushing manufacturers to provide a
>> guaranteed API, which is specified by community, and not to care
>> about _how_ the mfactrs achieve to fulfill this contract. Than to
>> nag manufacturers to open the sources of firmware, "because we can
>> do better, and do not want to use what we paid for".
> Maybe you imply a open standard for each hardware module access
> here :)
> Tony Tu
> OpenMoko community mailing list
> community at lists.openmoko.org
More information about the community