[Arm-netbook] fosdem2016

[GaCuest]

En 5 de febrero de 2016 en 12:36:19, Luke Kenneth Casson Leighton (lkcl at lkcl.net) escrito:
> On Fri, Feb 5, 2016 at 9:34 AM, GaCuest 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.
> 


I may have misspoke. In my opinion, the EOMA-68 project is very 
good. The problem is that I see it from a very ambitious view, a 
project to change the world.

Perhaps your view is better. We must be realistic. It is a small 
company, so we have to do the simplest project. First do simple 
devices (one EOMA-68 basic with Allwinner A20 with a simple 
notebook, a simple tablet, a simple games console...) to sell 
between developers and fans of the genre, and then expand 
the concept to ordinary people with more complex and powerful 
devices. And try to do cheap products (at first) to avoid losing 
money if very few units sold.


> _______________________________________________
> arm-netbook mailing list arm-netbook at lists.phcomp.co.uk
> http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
> Send large attachments to arm-netbook at files.phcomp.co.uk