[Arm-netbook] fosdem2016
Luke Kenneth Casson Leighton
lkcl at lkcl.net
Fri Feb 5 11:36:00 GMT 2016
On Fri, Feb 5, 2016 at 9:34 AM, GaCuest <gacuest at gmail.com> wrote:
>> remember, this is *not* a "give up after 6-8 months" project, it's a
>> "remain committed for the next 10-12 years" project.
>
>
> The problem is that if you sell a few units will not have
> money to make more EOMA-68 (or devices) and will also
> be difficult to attract more investors.
that is not a problem, because i have sponsors - not investors.
investors demand short-term profits and dividends. there is a place
for investors, but that place is later.
also for example: i met someone at fosdem2016 who is willing to pay
cash up-front to purchase a number of early-adopter kits, and he will
go round the world selling those kits, arranging workshops where
people may come along and assemble their products. those people will
be *delighted* to assemble their own eco-conscious laptop, and the
person sponsoring the kits loves to see that sort of thing happen.
where you perceive there to be "problem" there is in fact no such
thing. that is just one door closing and saying "you don't do it this
way, because that's not good for the project. find another way".
> For example, Aaron sold slow and left the project.
which says "this is not the right way", and in fact that turns out to
be absolutely correct. if you recall, aaron's associates attempted to
become the world leading authority on the EOMA68 standard, telling
people for example that "Multi-port SATA would be supported in a
future version of EOMA68". they were NOT AUTHORISED to make ANY such
misleading statements that could completely destroy four years of
extremely thorough and careful analysis.
basically they thought that they could take control of the entire
project, and they did not listen to my advice. many of the lessons
that i had already learned (which took time to learn) they ignored.
and because of the mistakes, aaron ran out of funds before we could
solve the mistakes that had been made.
but that's ok - we learned some important lessons. we learned the
ways how *not* to succeed. and, critically, the people who had tried
to take control of the project were no longer interested in it.
> And in addition to paying the hardware, you have to pay
> salaries for people who develop software, advertising, and so on.
> So you need a lot of money.
no, not really. there are other business models. creative
solutions come out of *not* having a lot of money. wealth comes from
your own mind, *not* from actual physical cash.
business is defined as "providing a service and being financially
adequately rewarded for doing so". there are many many ways to
provide a service that achieves the end-goal. those ways do not
necessarily *have* to involve "having a lot of money, personally".
in the past few weeks it's become clear to me that "money" equates
pretty much directly proportionally to "environmental impact". even
in the case of the ipad 1 which cost only $USD 125 to make, foxconn
charged apple $140, and apple sold it for a whopping $700+, the
discrepancy between the purchase price and the sale price is *still*
an environmental impact because apple had to (a) pay engineers (b) pay
investors (c) invest in environmentally-damaging silicon fabs for the
next generation SoC that went into the iphones and the ipad2.
so when you say "you need a lot of money", what you are actually
indirectly saying is "you need to make a large amount of environmental
damage in order to get this project off the ground".
and it is my responsibility to ensure that this project, which is an
eco-conscious one, carefully evaluates options which minimise
environmental impact - i.e. minimise everyone's costs.
so that's why we're looking at crowd-funding, and the "open hardware"
model, which i've been faithfully following.
> I guess you maybe think the community develop the software,
i'm *inviting* them to - but if they do not wish to have the exciting
opportunity of being involved with the project, then i will do it
instead. they will lose the enjoyment of being an early stage
developer, but that's not my problem.
> but if you sell little units, it is difficult to attract the scene.
> For example, only devices that sell a lot like Raspberry have
> a good scene.
again, you're forgetting that it's important to ramp things up in
stages. i have mentioned this many many times: i would say that i am
curious as to why you are perceiving that there are only roadblocks
and problems instead of envisioning success, but i'm actually *not*
interested in hearing about the roadblocks and problems that you
envisage.... *UNLESS* you are interested to hear of possible SOLUTIONS
to those roadblocks and problems.
so i am going to ask you to do something very specific. if during
the development of the project that you are doing, you have any
specific problems or roadblocks, please discuss them here with an open
mind.
however if you wish to only say "the EOMA68 project is a failure
because of X Y and Z could not possibly work" i.e. the only thoughts
in your mind are "failure failure failure omg crash problem problem
problem no money no money no money" then i'm going to have to ask you
to stop doing that, ok?
right now, in the past two messages, they basically summarise as
"this project is a failure, i can't see how it can possibly succeed".
i'm inviting you to turn your thoughts around, and to begin asking, "i
see there is this problem: how do you envision it being solved?" or "i
see this happened, do you perceive it to be a problem or not - what
insights can you share about it?"
i trust that this is absolutely clear. if it is not, PLEASE ASK
before sending another message in which you imply that there must be
"no possible solutions", ok?
>>
>> > Perhaps it would be interesting to establish requirements for
>> > software and minimum hardware requirements as did 96boards.
>>
>> no. absolutely not. ok, clarification: the standard defines the
>> minimum hardware requirements, in terms of what interfaces MUST be
>> provided (even if they're lower speed).
>>
>> but software-wise: how can you define minimum software requirements
>> for a pass-through card? you can't. how can you define minimum
>> software requirements for an FPGA-based card? you can't.
>>
>> the whole point of the exercise is that there should be a *range* of
>> CPU Cards. i've discovered a $3.50 SoC from Ingenic that has 128mb of
>> built-in RAM. it's possible to create a 2-layer PCB based around it.
>> total BOM could well be around the $8 mark.
>>
>> ... should i define "minimum software requirements" that exclude the
>> possibility of creating such a low-cost CPU Card? hell no!!
>>
>> now, if that $3.50 SoC happened not to have the required SD/MMC
>> interface, or happened not to have 18-pin RGB/TTL which could do
>> 1366x768, or anything else, *then* it automatically gets excluded.
>
>
> I understand what you say. I mean that much variety can
> confuse non-expert people. For example, a classification.
such as labels being put on the outside of the boxes, in
colour-coding and so on, and then that colour-coding becomes a
de-facto part of the standard or a pre-arranged part of the standard.
yes, the idea was discussed four years ago.
> Can anyone buy an EOMA-68 destined for a router and put
> it in a laptop? Not now.
no of course not, because the OS on the router would turn the laptop
*into* a router! exactly as the product you are developing (a "games
CPU Card") would turn a laptop into a games laptop. that's the whole
idea: the CPU Cards, with pre-installed OSes, you can buy for specific
purposes and they are less money than they would be to buy the same
monolithic devices from other manufacturers.
let's envisage the scenario the other way round: why would you put a
dual or quad-core laptop CPU Card into a router "base"? because you
would want the faster CPU Card to handle traffic encryption, that's
why. the kinds of 400mhz MIPS processors that go into the low-cost
4-port routers simply cannot handle the decrypt/encrypt of end-to-end
traffic at 100mbit/sec speeds let alone gigabit, whereas a dual or
quad-core processor could easily handle it, especially if it has an
on-board hardware crypto unit.
would a "traditional" manufacturer make a quad-core router monolithic
box? of COURSE NOT! the number of people who would understand its
benefits are not big enough to justify the cost. however, creative
people such as those we encounter at FOSDEM2016 (one of whom
immediately "got" the concept of using high-end CPU Cards for
end-to-end traffic encryption including WIFI, and running TOR and VPNs
as well) *DO* get it, and they *REALLY* appreciate the freedom and
flexibility that comes with this concept.
basically there are limitless scenarios that we could not possibly
envisage, which are suddenly opened up, as 3rd party base units are
combined with 3rd party CPU Cards in ways that were never imagined by
*either* manufacturer.
when i described the "3G CPU Card with Digital SLR Camera" scenario
to someone at FOSDEM2016, the person i told the story to went, "oh
that's really cool, a journalist being able to upload images and video
footage in real-time to their editor and also to the BBC and to
Reuters. how about adding GPG Digital-Signing to the photos and the
video, so that the BBC and Reuters can tell that the images are coming
from a known journalist's camera?"
can you imagine approaching a Digital SLR Camera company and saying,
"we'd like you to add GPG Digital-Signing to your Camera OS"???
they'd look at you like you had 2 heads and had your hair tie-dyed in
psychedelic patterns.
so the only way to achieve that goal on a monolithic designed camera
would be to reverse-engineer the camera.... only to find that the
processor is totally incapable of handling the encryption speed of
real-time video traffic.
whereas, with a 3rd party general-purpose CPU Card with a
general-purpose OS (such as android, linux or even windows), the BBC,
Reuters, the Journalist or their News Agency could conceivably pay
someone to write the general-purpose software to do the encryption....
*OR* they could most likely find, online, a pre-existing app that does
the job.
does this start to make it clear?
l.
More information about the arm-netbook
mailing list