[Arm-netbook] [libreplanet-discuss] EOMA68 and freedom in digital technology

[Paul Kocialkowski]

Hi,

Le lundi 12 septembre 2016 à 06:19 +0100, Luke Kenneth Casson Leighton a écrit :
> On Sun, Sep 11, 2016 at 2:04 PM, Paul Kocialkowski <contact at paulk.fr> wrote:
> > Le samedi 10 septembre 2016 à 20:38 +0100, Luke Kenneth Casson Leighton a
> > écrit :
> > > I disagree. There is simply nothing you can compare this project to.
> > > > > We
> > > > > are achieving results that can't be demonstrated via any other means.
> > > > > If
> > > > > we could get here some other way at a lower cost with the same long
> > > > > term
> > > > > impact I would have gone that route.
> > > > 
> > > > See what Olimex has been doing for years then.
> > > 
> > >  you're aware that olimex operates as a criminal cartel,
> > 
> > This is a very strong accusation and I definitely do not share that
> > perspective,
> > at all.
> 
>  it dates back several years.  tsvetan's reaction when i brought this
> up on the gpl-violations mailing list was to try to belittle me (in
> front of 20,000 people) as a way to dodge the question. "what are you
> talking about, idiot, you've totally failed to even bother to release
> any product, what a total waster you are, har har, go away little
> loser i don't have to answer your question because you are such a
> failure" was the general gist of his response.

Someone brought up the EOMA68 at the Olimex forums and it is clear from that
discussion alone that there is a lot of bad blood between you two:
https://www.olimex.com/forum/index.php?topic=4383.msg18469

Frankly, I'm not interested in those kinds of ego clashes and speculated bad
intentions. I know you both have made contributions to freedom in digital
technology, that I appreciate. This is what I find to matter the most.

I am not sure Olimex's boards have shipped with Allwinner's GPL-violating
software preinstalled (some of them do not come with NAND). It is regrettable if
they did and it would have been much better to avoid that.

I think that offering the GPL-violating software for download separately would
have been a lesser evil (even though not quite acceptable). Perhaps this is what
they did, perhaps not.

Either way, I do not need to have an umbrella statement about Olimex as a
company. Their products helped the freedom in digital technology front and I'm
grateful for that. Perhaps they also did bad things, such as promoting and
distributing GPL-violating binaries. But so do a great number of other companies
that are also doing good on some aspects and much less on others. This is the
case of Google, IBM and many other.

I think such general considerations are only relevants to evaluate whether an
individual or a company is dedicated to helping us solve digital technology
freedom issues, or is only doing it sporadically. In that case, you may conclude
that Olimex falls in the latter position. I'm personally not quite sure about
it, but I do agree that shipping Allwinner's GPL-violating software is a
drawback in that regard. However, as I've mentioned before, I know first hand
that Olimex has been supportive of the linux-sunxi community (when many, many
other Allwinner board vendors barely acknowledges it).

> > >  from shipping
> > > GPL-violating A10 bootloaders and kernels provided by Allwinner, back
> > > around 2011/2012?
> > 
> > Olimex has always been about producing community-friendly boards, not about
> > the
> > software. Nevertheless, Olimex has been involved with the linux-sunxi
> > community
> > from the early days
> 
>  paul: you may not be aware that the linux-sunxi community formed
> around the arm-netbook mailing list and resources.  the people using
> the resources that i set up decided to *create* the sunxi mailing list
> and wiki and to form their own community.

I have to admit that had skipped my mind when writing those previous emails. I
do recall that linux-sunxi was initially started on the arm-netbook mailing
list. And indeed, I also recall seeing your name around for a long time.

> > and has always been very supportive, by providing developers
> > with hardware to work on, taking part in the community, etc.
> 
> that doesn't change the fact that the very early boards with the A10
> processor were shipped by default with allwinner's original
> GPL-violating bootloader, u-boot and linux kernel.  now, the GPL is
> very very clear: on request you must supply the *EXACT* source and
> *EXACT* tools used to compile the *EXACT* binaries that were shipped.

That's making an umbrella statement about Olimex, which I don't think is very
relevant. There's good and there's bad there.

> if you can't do that, you MUST cease and desist distribution.   if
> you do not cease and desist distribution, you are no longer in
> compliance with the license.  if you are no longer in compliance with
> the license but CONTINUE to distribute GPL code (without a license),
> *that* is criminal infringement.
> 
> and if a company is in criminal infringement of copyright law, the
> company is no longer operating as a company but is in fact an
> organised crime syndicate: a criminal cartel.

I have to say, this sounds over-exaggerated to me. In French, the word "crime"
only refers to the most serious offenses. But Wikipedia apparently states that
crime is not so precisely defined in English. Oh well.

Still, I don't really see a need for pointing fingers this way. Stating that the
distribute GPL-violating software is the informative thing to do. I don't see
the point of getting personal about the company with harsh considerations
(however technically correct these considerations may be). It also feels like an
attempt to discredit Olimex, to be honest. I believe all parties would be better
of without that kind of heat, by staying factual and informative.

Also, let's not forget that Allwinner's the culprit for all this mess in the
first place. Olimex may has been a distributor of it, which may be the same from
the copyright law's standpoint, but I think it makes a big difference. You may,
of course, disagree with these personal views.

> > Also, when they started with Allwinner, mainline software
> > wasn't an option.
> 
>  that's no excuse, paul.
> 
>  you're aware that it was me who released the very first allwinner
> u-boot and linux kernel sources, for the a10?  i obtained them from
> allwinner and immediately made them available on git.rhombus-tech.net.
> tom cubie, who was an allwinner employee at the time, bought some Mele
> A1000s and, in a very enterprising spirit, sold them as $50 developer
> boards from his aliexpress account.  from there he went on to develop
> his own company, made the first cubieboard and began selling it.

Then you were, in fact, in the same position of distributing GPL-violating
binaries. Unless you stripped them off off that release?

I think this makes you understand the kind of tricky position this leads to.
People need those GPL-violating binaries (for some of them, for direct use, for
others, to do reverse engineering), so I wouldn't send the first stone to the
distributor, but to the company that caused the problem in the first place.

So nobody wants to distribute them, but people need them. I'm really not sure
what the right thing to do here. And frankly, if everyone had stayed away from
it with a ten-feet-pole, we wouldn't be here today.

> > Better yet, the latest one (A64) was designed with KiCad, so those design
> > sources can even be handled with free software! This is an unprecedented
> > achievement that even the EOMA68 project has not reached (yet).
> 
>  there's a reason for that: i'm not an electronics engineer (and KiCAD
> simply wasn't ready for use).   five years ago i asked on the
> arm-netbook mailing list if anybody would like to help out, in return
> for profit-sharing in the end result.  due to some "deliberate"
> misunderstandings (which are still going around the internet) various
> people saw my offer as a "demand" instead of what it genuinely was: an
> offer to share in the profits.  i won't go into details.

You don't need to. Those are past stories, I'm rather interested in the state of
things as they are now.

>  so, i began to try to use KiCAD myself (see
> http://git.rhombus-tech.net/?p=eoma.git).  it didn't go very well.
> there were some severe bugs in KiCAD (that have still yet to be fixed)
> that make using KiCAD for such large BGA ICs a near impossibility: i
> had to hand-edit the library parts.  when it came to actually doing
> the PCBs the lack of professional-level features met head-long with my
> lack of knowledge of electronics CAD design and i began to realise
> very very quickly that i was completely out of my depth.

Of course, I'm not surprised. And I know that Olimex was only able to use KiCad
for such a complex project at the cost of lots of efforts, bugreports, etc. But
I'm really glad that they did and this is the kind of extra step that makes me
believe Olimex and Tsvetan are not only there to collect money but actually want
to push things forward on the freedom-in-technology front.

> rather than end up spending time (and money) doing iterative PCB
> design (which could be a bottomless pit) i made a number of other
> efforts to invite other people to profit-share in the planned project
> scope, but in the end these also fell through and i had to teach
> myself electronics CAD design.  with no experience in this field i was
> forced into the position of first paying people to do CAD designs for
> me, and then later when there wasn't a financial budget available,
> learning and using the professional CAD software that we'd paid those
> people to develop the designs in.
>  now, EOMA68 succeeds in the engineering arena by making it simpler
> for people to update sophisticated products at a fraction of the cost
> of other "monolithic" designs.  a "monolithic" design is typically a
> minimum of a 4-layer PCB to cover the SoC and the DDR3 RAM.  if
> there's a 64-bit RAM path you are usually looking at a 6-layer or
> 8-layer PCB.  that's *expensive* territory: $700 for QTY 5 PCBs, $400
> for components, and $600 for assembly.  make a single mistake and it's
> another $1800 and another 4-6 weeks turnaround.
>
> and at the end of all that effort, you're "on the clock" as to the
> usefulness of the product, because the key part - the processor - is
> going to be superceded very very quickly.  with specialist
> vendor-lockin on the various interfaces you're even *more* on the
> hook, especially if the fabless semi company doing the SoC doesn't
> "grok" libre principles and releases GPL-violating android-only
> binaries.

This is interesting background (I'm quite familiar with it, but others may not
be, so it'll probably help them realize what a task designing that kind of
circuit board can be). Thanks for sharing it.

>  now, what if there were "modules" which you knew complied to a simple
> interface that you could just get off-the-shelf, even from Best Buy or
> Walmart, and could make a simply 2-layer PCB around it?  that would be
> amazing, wouldn't it?

I'm not sure this would solve the multi-layer requirement. Also, a standard
interface does have drawback, as it limits the possible number of interfaces
exported by the SoC board.

>  what would be even better would be if there were plenty of example
> schematics and PCB designs around that you could work from, that were
> simple 2-layer PCBs that you could pay china or eastern european
> companies to make with a 48-hour turnaround at the fraction of the
> cost of 4+ layer PCBs?  it would be *even better* if those reference
> designs were available as gEDA or KiCAD designs, wouldn't it?

Yeah, definitely. We're still a long way from that being a reality comparable to
what it is with software, but we're getting there :)

>  so this is why i started that KiCAD-based set of designs back in
> 2011... unfortunately i haven't had time to come back and revisit
> them.  i understand from joe micha that KiCAD has a "Gerber Import"
> feature, so it *should* be possible to import (and recreate) KiCAD GPL
> compliant sources from pretty much any proprietary CAD package, with
> quite a bit of work.  i hear also that there are some proprietary
> importers... it's complicated, hazardous, but doable.

I wouldn't expect those kinds of automatic imports to be 100% reliable,
especially for complex designs though. But it's great that it's there.

>  all of these things i haven't got time to do immediately, myself, but
> it is definitely part of the vision - it always was.  i've not been
> talking much online about these things because i've had to focus
> instead on "getting it done".  bringing the project out of that
> critical "vapourware" barrier... but sticking to

That's great to hear!

> > Get https://github.com/OLIMEX/OLINUXINO/tree/master/HARDWARE/A64-OLinuXino/A
> > 64-O
> > linuXino_Rev_A and open it up with KiCad if you wish to see for yourself!
> 
> when the A64 doesn't require a proprietary bootloader, i'll start the
> evaluation process again.  however given that the A64 is a 40nm IC and
> the Cortex A53 is 15% more power-hungry performance-watt-wise than a
> Cortex A7 *and* it's limited to 2GB RAM as a hard limit, i'm much more
> inclined to go with a quad-core Cortex A7 instead, or an 8-core 28nm
> (or both).

Whatever suits you best! But why stick to Allwinner platforms? Rockchip
platforms such as RK3288 (and possibly the upcoming RK3399) do just as well in
terms of software freedom. I guess you've also considered the i.MX6. GPU support
is being reviewed upstream as we speak. Tegra K1 is also really nice, but
perhaps more power-hungry. Is this really an issue for a non-mobile device
though?

>  currently "in the slot" for evaluation is the Samsung/Nexell S5P6818
> and the Allwinner R40.  both of those are an improvement over the A64.
> the S5P6818 is a 28nm octa-core A53 so is power-equivalent to the R40
> (40-28nm is a 2x power improvement, but it's double the number of
> cores so roughly back up to the same power usage).  we don't yet know
> what geometry the R40 is, but if we assume it's 40nm then it will be
> at least 15% more power-efficient than the A64.

By the way, I'd be very interested in your notes and conclusions when evaluating
platforms!

>  basically it's highly likely that i'll skip the A64 entirely.

Well, I guess it depends on your timeline. Perhaps free software support won't
be ready in time for the next generation of your products. Or maybe it's not
that interesting on the technical side either.

> > I think his contribution to freedom in digital
> > technology has been solid and significant.
> > The devices he's producing show as much.
> 
>  given that he's released the designs of a number of products -
> libre-licensed full SCH and PCB files which i wasn't aware of before -
> i have to agree with you.  but be under absolutely no illusion that
> it's all "roses".  he's prepared to compromise on ethics (because he
> doesn't understand their importance - as in he *genuinely* doesn't
> understand it).   he'd rather take your money.

I hear you.

> > > also, the A64's processor - which tsvetan is using for the olimex
> > > laptop - requires a proprietary early-bootloader.  in fact, the first
> > > A64 SDK that came out was an absolute mess, comprising several GPL
> > > violations in both the early-bootloader, the u-boot source *and* the
> > > linux kernel.  the SDK was even exclusively distributed over a chinese
> > > illegal filesharing network (this is an "official" released SDK from
> > > allwinner!)
> > 
> > Of course, we all know that, but that's how you move forward! We can't just
> > wait
> > for the situation to be magically resolved before considering producing
> > hardware
> > with it, and staying away from it with a teen-feet-pole before.
> 
>  true.
> 
> > 
> > Simply because
> > no change will ensue of that. Olimex has the ability to create boards early-
> > on,
> > that will encourage the community to work on this chip, and also create
> > leverage
> > with Allwinner.
> 
>  ok.  right.  are you familiar with the story behind the Allwinner R8
> "NextThingCo" "CHIP" computer?  that was going to be a GPL-violating
> product until some people on the crowd-funding campaign pointed out
> that it would be a bit of a problem for a USA-based company to be
> importing copyright-violating product.

Hehe, yeah I'm aware of it.

>  so, NextThingCo had a rather urgent meeting with Allwinner (one of
> the team worked for them so knew who to call), and basically "put
> their foot down".  they said, in effect, "give us the source, or you
> don't get the order.  oh... and we have 50,000 orders".
> 
>  end result?  allwinner's R-Series team is now scrambling to get fully
> GPL-compliant source code out the door (and i am arranging to go over
> to the main office in Zhuhai in a few days time to help them out).

I didn't know about those details. I'm really glad you're helping with this,
too.

>  *THIS* is what both Pine64 and Tsvetan *SHOULD* have done with the
> A64. they should have said, "give us the source, or you don't get our
> money".  it's only 200 lines of code in this case: libdram is mostly
> identical in all versions, there's one main function (the DDR3
> initialisation).
> 
>  because they *didn't* put their foot down when it mattered, the sunxi
> community is now forced to reverse-engineer libdram.

That's an interesting perspective. It would be interesting to bring it up with
those companies to see what they have tried or why they didn't try to take that
stand.

>  these kinds of compromises when it matters are *VITAL* lost
> opportunities....

I would tend to agree with you on this one. Hardware manufacturers have leverage
in those situations, so it's sad that they don't use it.

>  all because people like Tsvetan and the team at
> Pine64 prefer to take your money.

There's probably a wide range of possible explanations for this. It's not
certain that these companies' volumes matter. But either way, I'd be interested
in starting that discussion to see where each actor stands on this.

> > So it's really not about what the situation is right now, but about what it
> > can
> > possibly become. Allwinner chips have *always* been a mess to deal with at
> > first, but efforts from companies like Olimex and the community made it
> > possible
> > to have the kind of support we know today for chips like the A20.
> 
>  paul, i reiterate here: the sunxi community exists because of my
> early efforts :)  i *am* aware of the sunxi community's work since
> then: i've been an indirect contributor myself (i did the
> reverse-engineering of USB-FEL that allowed the sunxi-tools fel-boot
> program to be completed - i used usbmon from outside of a qemu session
> running LIVESUIT.EXE to sniff the usb traffic).

Great to hear and sorry for implying it was not the case.

> > Also bear in mind that you were able to get the EOMA68 together, with that
> > level
> > of free software support, in part thanks to people like Tsvetan who put
> > together
> > (free hardware) boards for the community to work on those chips and
> > supported
> > their efforts early on, when the situation is indeed a mess.
> 
>  this isn't historically accurate: back in 2010, 2011 it was my first
> release of the A10 u-boot and kernel source, and the rhombus-tech
> wiki, arm-netbook mailing list and irc channel, using the Mele A1000
> and then tom cubie's cubieboards that allowed the sunxi community to
> first form: tsvetan's boards came out at least a year later (i think)
> than the first cubieboard.  *later* boards - around... probably
> something like.... 2012: *then* yes, you are correct.

Same here, sorry for not connecting the dots earlier. I'm now under no
impression that you just waited idle and got your product out after others did
the work for you.

> > > over a considerable period of time, pine64 and the sunxi community
> > > worked to eliminate as many of those GPL violations as they could, but
> > > Allwinner insisted on keeping the early-bootloader proprietary.
> > > 
> > > so at present the A64 is classified as a "non-libre" processor.  that
> > > it's the basis of the olimex laptop tells you everything you need to
> > > know.
> > 
> > Again, you're looking at the situation right now, which indeed matches what
> > you
> > describe. However, I think Olimex sees a lot of potential in A64 and so do
> > I.
> > Only time will tell whether it was a dead-end or not.
> > 
> > > 
> > > now, whilst tsevtan is making money selling you hardware that requires
> > > non-free components to operate basic functions, i've put my foot down
> > > and said NO, i will NOT sell GPL-violating product.  i don't care if
> > > that means it's harder to deliver ethical products, i'll deal with
> > > that on an ongoing basis, but here's the thing: it means i've
> > > established a reputation for setting some ethical rules *AND STUCK TO
> > > THEM*.
> > 
> > Frankly, I don't care that a device doesn't work with free software right
> > now if
> > it has potential to be liberated eventually
> 
>  this is an extremely exhausting approach that burdens the entire
> sunxi community with a hell of a lot of unpaid work.... and will
> result in each and every processor being *years* behind.  if it takes
> 2 years to complete the reverse-engineering, that's an *entire
> generation* behind!  look at how long it took to get the full source
> together for the A20!  in the meantime the A33, A31, A83 *and* the A64
> came out!

It may not be the most efficient strategy, but I'm saying that it's something.
The situation is much worse on a number of other platforms, where we have no
friendly circuit board manufacturer at all.

>  as a community we simply cannot be expected to shoulder the burden of
> responsibility for clearing up Allwinner's mess, only to be "rewarded"
> with having to tolerate being at least *TWO YEARS* behind the times in
> terms of what processors are available for us to use in libre
> projects!  that's completely insane!
> 
>  no.  i REJECT that approach.

Again, I'm not saying it's optimal and good as it is. But it's something and has
lead to results (that were, indeed delayed by years due to the technical burden
that Allwinner induced by requiring the community to do reverse engineering).
But considering the size of the task, I think the community has done an amazing
job here.

> > But of course, Olimex and you are not in the same position.
> 
>  it's much more than that.  i'm first and foremost a software libre
> engineer and advocate.  i place libre principles FIRST.  i do NOT
> place "making money" first and foremost.  i choose NOT to compromise
> on software freedom.
> 
>  and i also choose to FIND WAYS to GET software freedom and to create
> an ethical business.
> 
>  so it's not that we are not "in the same position", it's that we
> operate *FROM* totally different positions.  Tsvetan (and pine64, and
> numerous china-based OEMs) operate from the basis of "money first,
> software freedom second".

Again, I'm not sure I fully share your stand on Olimex, but I sure am glad to
see read this about the way you're conducting your effort. I am grateful there
are people like you around.

> > > > I agree that you went steps further than most before, but this is
> > > > incremental improvement, not something truly new and groundbreaking
> > > > compared
> > > > to
> > > > what existed before.
> > > 
> > >  hmmm, an interesting perspective, which i feel may be based on not
> > > being aware of the sheer overwhelming number of issues being tackled
> > > (all at once).
> > > 
> > >  yes it's "incremental improvement" but it's a MASSIVE stack of
> > > MULTIPLE "incremental improvements", all done at once.
> > 
> > From what I can see, the actual improvements (again, from the digital
> > technology
> > side of things, so I'm not including the mechanical design) come down to not
> > including a Wi-Fi chip that requires proprietary software in a laptop
> > design,
> > which is what had been lacking from the ARM Chromebooks. If you see anything
> > else, please state it clearly.
> 
> there's too much to cover, paul.  i'm not saying that lightly: the
> fact that the ecocomputing whitepaper is seventeen *thousand* words
> long is testament to that.  it's not even specifically about the
> actual *hardware*: the actual hardware specs is just a "response" (if
> you will) to the systemic approach that i've taken, after doing an
> extremely comprehensive analysis of the entire computing industry.  if
> you start with the whitepaper you'll begin to get a feel for what
> EOMA68 is really about.
> http://rhombus-tech.net/whitepapers/ecocomputing_07sep2015/

That's probably a fascinating read, but you're again talking about an approach
here, not technical differences that matter from the perspective of freedom in
technology, about the product you're releasing now. This is the specific aspect
I wanted to highlight and get feedback on, not your general attitude.

>  the crowdfunding campaign was - is - just the beginning of emerging
> from an extremely intense period of work, learning an entirely new
> field (hardware design) in order to be in a position to influence an
> entire industry and turn it away from the entropic field of
> "proprietary software / hardware because it's cheaper".  reality is:
> it *isn't* cheaper (long-term).

I realize that, I have actually been following your work from a distance for
some time and I'm glad it finally got concrete.

> > There are also rare occurences in your design, meaning that only few
> > products
> > before (such as the ARM Chromebooks or the Novena) had reached that level of
> > support, such as: using a SoC that has few freedom flaws (GPU), having a
> > free
> > software keyboard controller. We could also add free hardware design there
> > (but
> > I'm still a bit confused about what the situation actually is and didn't
> > take
> > the time to look it up properly).
> 
>  dr stallman and i have been talking about this (privately).  the
> terms "open hardware", "open source hardware" and "libre hardware" are
> *all* very misleading, because "hardware" could mean *anything*.  it
> could be spoons, it could be heavy machinery, it could be casework, it
> could be PCBs, it could be ASICs (actual silicon ICs).
> 
>  so the whole episode (this thread) comes back to all of us (as a
> community) using a rather thoroughly ambiguous term.  if we want to be
> clear, we should be using the words "libre PCB designs", "libre
> casework designs" and so on - *not* "libre hardware".  it's way too
> general.

I believe the PCB design is the source form of the technology. Printed circuit
boards are the product form and the technology itself can be referred to as
"circuit boards". Just like software (form of technology) has source code
(source form) and binaries (product form). We can distinguish that from
Integrated chips, another aspects of digital technology.

I will be (and have been) using this specific terminology. I rarely talk about
"free hardware" in general (and even less  so about "open hardware'. However,
this confusion is very common, so it's good to bring it up.

> > If you feel like I'm missing something substantial, please let me know.
> 
>  you're missing an entire five years of work - the entire rhombus-tech
> initiative - which has run in parallel in the background side-by-side
> with the sunxi community efforts.  i've stayed off of the sunxi
> resources because they're using nonfree infrastructure.  sunxi mailing
> list: runs off the non-free google groups.  sunxi git repositories:
> runs off the non-free github repositories.  the key developers know me
> (because they were originally members of the arm-netbook mailing
> list), and we do occasionally talk (in private email) - but most
> people who use the sunxi mailing list don't even know that i exist.

Again, these are not the aspects I'm commenting about.

> > >  *nobody* has tried to do that before.  not Dell, not Olimex, not IBM
> > > - *nobody*.
> > > 
> > >  for example you compare the EOMA68 Housing to the olimex laptop.  the
> > > olimex laptop's casework is proprietary (the EOMA68 Housing's is
> > > GPLv3+ libre-licensed).  so automatically you can see that it's
> > > nowhere near being a legitimate comparison.
> > 
> > Again, my point is about digital technology here, not mechanical parts.
> 
>  i'm lost, sorry.  i don't quite follow what the term "digital
> technology" refers to, but you use the term again below so i think i
> might have been able to deduce what you mean from context... correct
> me if i'm wrong.

Digital technology refers to digital electronic technology, which includes
software, hardware configuration, circuit boards and integrated circuits.

Case design and mechanical parts don't fall into that scope.

> > > > > The issue is your looking at one thing. A few specs. It's not the
> > > > > specs?
> > > > > that matter. It's the standard, it's the modularization, it's the?
> > > > > response and cooperation we are getting already as a result of our?
> > > > > actions here, etc. Intel and AMD are not going to cooperate and
> > > > > building?
> > > > > off of other companies products (higher up the chain) is not a
> > > > > reliable?
> > > > > long term solution.
> > > > 
> > > > Again, I don't see how modularization changes anything here.
> > > 
> > >  you can't focus on just the one aspect and conclude that "it's not
> > > significant".  bear in mind that this has been a 5 year project, where
> > > i've had 15 years of working near-exclusively with software libre,
> > > looking at the endemic and systemic problems and coming up with a
> > > *long-term* strategy to tackle *all* of the issues associated with the
> > > consequences of proprietary computing... *all at once*.
> > > 
> > >  modularisation (and having open standards despite what the
> > > wikipedia-page-that's-already-scheduled-for-deletion would have you
> > > believe) is one - *one* - critical - *critical* part of that strategy.
> > 
> > Again, everything you can do with modularization you could do by producing
> > new
> > versions of boards.
> 
>  no, you can't.  read the ecocomputing whitepaper [and scan back up
> several paragraphs]

I probably will then, I find the subject quite interesting anyway.

> > It solves the environmental problem and is convenient to
> > users, but has little to do with freedom in digital technology.
> 
>  you're correct here (and this is why i said that you're missing the
> point by focussing exclusively on *one* aspect).

Well, what I asked was what I was missing about digital technology freedom
aspects, not what other aspects I was missing. I'm well aware that your project
comes with a much broader approach, that you have described a bit already
throughout this conversation.

>   so if you *only*
> focus on the modularity, you'll be completely lost and won't
> understand.
> 
>  what is needed is to have modularity... *AND* commit to software
> libre ethical principles.  making this clear is extremely hard to do.
> even the fact that i've just added a DRM section (it's banned) to the
> EOMA68 standard *still* doesn't really get the full message across.
> 
> > If you have
> > actual specific point to counter those points (other than vague statements
> > like
> > "part of a strategy"), I'd be happy to react to them.
> 
>  it's complicated, paul, and i'll be absolutely honest with you: i'm
> *working out* how to get it across, what i'm doing and why.  *five
> years* and i still haven't been able to put what i'm doing into a
> simple clear statement... because of the sheer overwhelming depth and
> scale of what i'm attempting to do.  it's so ambitious and audacious
> that when i start explain it, many people react with total disbelief,
> calling me "arrogant", "deluded" and many many other things which goes
> a long, long way to explaining the rather vehement reactions that you
> will see evidence of (if you look carefully enough).
> 
>  so if you can promise *not* to react in the same way, i'll make an
> effort to explain.  deal?

Again, I think you're misunderstand what I'm asking here. I'm not asking about
the approach (but feel free to provide a comprehensive introduction to it, I
feel it is quite interesting). I'm talking about the specific level of support
of the products you're releasing now in regard to freedom in digital technology.

Also, I can guess how vast your effort is and how much work it represents. This
most certainly naturally explains why it took such a long time to actually get
something concrete produced from all these ideas.

And frankly, I'm not one to make personal attacks, so I don't think you have to
fear that sort of reaction from me :)

> > > > Hardware availability has never been the problem.
> > > 
> > >  libre hardware availability has *always* been a problem.  entropy
> > > guarantees that it always will.  you actually have to make a concerted
> > > continuous effort to push back against the corner-cost-cutting of the
> > > mass-volume industry.
> > 
> > So if we're talking about free hardware projects, then I'll agree that the
> > situation hasn't been that great. As far as I know, only Olimex, Novena and
> > a
> > few others have been producing free hardware computers that work well with
> > free
> > software.
> > 
> > But again, I'm still confused about the hardware freedom situation of your
> > device. The most meaningful part is, of course, the EOMA68 board with the
> > A20,
> > not the carriers (even though having them as free hardware is very nice).
> 
>  as i have the right (under the GPL) to release the CAD designs when i
> actually ship, that's what i'll be doing.  if i release the designs
> *right now*, there's the severe risk that somebody may take the
> designs and manufacture them *in advance* of me fulfilling my
> committment to the backers of the campaign.

Of course, you don't have to do anything until your products go live anyway!

>  i *specifically state* - very very clearly - right there on the
> crowdfunding campaign page - that this is why i will not be
> IMMEDIATELY releasing the EOMA68-A20 CAD designs.
> 
>  and i *specifically state* that *everything else* is made available in
> advance.
> 
>  this fits closely with the EOMA68 strategy from an engineering
> perspective, because the "computer" bit is not something that you
> should be manufacturing in small volumes anyway: the whole point is
> that if people group together to do "bulk buys" of EOMA68-XXX
> computing modules, everybody benefits from mass-volume bulk volume
> pricing whilst being at liberty to design and manufacture much simpler
> "Housings" using only 2-layer boards.

Okay.

> > On the other hand, the availability of boards that have components that work
> > well with free software have never been a problem, there's not discussion to
> > have here.
> > 
> > > 
> > > > 
> > > > For laptops, we only had minor
> > > > annoyances,?like Wi-Fi chips that require proprietary firmwares,
> > > 
> > >  proprietary firmware for WIFI is a bit more than a "minor" annoyance,
> > > paul!
> > 
> > That's not what I'm saying. I'm saying that there are easy and nearly
> > painless
> > ways to solve these problems, by using external ath9k_htc USB dongles.
> 
>  you're aware that my sponsor, chris from thinkpenguin, was
> responsible for bringing us the ath9k_htc libre firmware?  that
> chris's business model is founded around exactly the same ethical
> committment to libre principles as are behind the EOMA68 initiative is
> a big, big clue :)

Yes, I am well aware! Such a great thing to have. It has severely alleviated the
pain associated with Wi-Fi.

> > >  no, paul, what you're missing here is that there's an *active
> > > committment* to tackling the pain, cost burden and inconvenience that
> > > proprietary software (and hardware) causes.
> > 
> > Well, I have been talking about the freedom situation in digital technology
> > all
> > along, not commitment. I do agree that commitment such as the one displayed
> > with
> > your project is a rare thing.
> 
>  i'm prepared to prioritise libre principles over profit maximising,
> that's all there is to it.  the interesting side-effect of that is
> that i've had to get *really* creative about how to fulfil the goal
> [of bringing libre principles to mass-volume products].
> 
> 
> > And that is indeed groundbreaking (even though
> > projects like the Novena were here before),
> 
>  you _are_ aware that the EOMA68 initiative _pre-dates_ the Novena, right? :)

True, they just got it shipping faster (Bunnie is quite used to EE and the
Chinese circuit-board-making ecosystem, so that must have been a great help).

> > because that kind of intent is
> > clearly lacking from e.g. companies producing Chromebooks, so it rather
> > feels
> > like we got lucky (or that people inside these companies care a lot, but it
> > doesn't reflect in the company's PR).
> 
>  yeah.  i think now that chromebooks are out of the "R&D" phase (where
> they began solely as a google initiative) and are now seen as an
> actual profitable thing to "copy", we now see third party companies
> independently designing chromebooks *without* the assistance or
> involvement of google-sponsored engineering...

Really? I haven't seen any such example, and I'm not sure that Google will allow
any company to do this under the ChromeOS brand name. But I'm all ears for
details :)

>  ... and that's where you end up with the cost-cutting exercises such
> as "using SD/MMC soldered-down SIP modules onto the main PCB which
> require proprietary firmware"

Well, they have been using eMMC modules on ARM devices because most of them
don't have SATA or PCI-e interfaces. But I seem to recall that earlier x86
Chromebooks did use SATA disks. This is anyway a very common practice on those
kinds of devices. And any MMC card (soldered or not), just like any USB storage
key, comes with a proprietary firmware.

> now, here's where it gets interesting, because if you create an EOMA68
> chrome OS computer card, libre compliance is pretty much a "hard
> requirement"... because if it's not, chances are quite high that that
> EOMA68 ChromeOS Card *won't work* in Housings that require proprietary
> firmware.
> 
>  why is that?
> 
>  it's because you can't predict what peripherals future Housings will
> have... so you have to always upgrade the OS on the Computer Card (so
> that it's always compatible with the latest and greatest Housings and
> any newer peripherals that might be in them).... now you have to
> include *all* the bits of firmware that you can possibly get your
> hands on, and if those are non-free proprietary WIFI firmware blobs,
> now it gets really complicated.  but if they're *libre* firmware, it's
> a hell of a lot easier.

From a technical perspective, I don't think this has been a drawback for
ChromeOS devices. And they're continuously updating the system, too.

>  i really must put this as an "advisory" on the EOMA68 standard....
> another thing for the TODO list...
>
> > Commitment is important for the long run, so I'm really glad you're around.
> > We
> > can't just rely on sheer luck to get devices that do well with free software
> > from mainstream manufacturers, even though we've had good luck a great
> > number of
> > times already (and bad luck an astonishingly greater number of times, too).
> 
>  yyyeah... i learned recently that the latest chromebooks have
> integrated WIFI (with proprietary firmware... argh) whereas previously
> they had WIFI-as-a-USB-based-module-over-a-four-wire-cable).
> cost-cutting exercises are clearly beginning to creep into chromebook
> designs.... oops.

Again, not sure it's that. SDIO Wi-Fi modules have been really common all along.
And either way, it would be hard to replace them as everything's soldered
together. As long as we can use an external Wi-Fi dongle that runs with a free
firmware, I think we're good. This is why I don't focus on the Wi-Fi part that
much. Other aspects such as GPU support are a clearly much bigger task to
tackle.

> > >  .... it's a vicious self-sustaining cycle that has to be broken by an
> > > *active* committment.
> > 
> > Definitely, that's a (if not the only) reliable (but harder and perhaps more
> > dangerous) way to achieve progress for freedom in digital technology. Going
> > with
> > luck has worked well in some areas (again, ARM Chromebooks), but we knows
> > when
> > our luck will turn.
> 
>  yeahyeah.  it's why "businesses" (corporations) will never be trusted
> to deliver (even at their own long-term expense), because they have to
> prioritise "profit" above all else.  USB-based WIFI dongles ($3) are
> *always* going to be more expensive than soldered-down SD/MMC-based
> SIP "modules" ($1.50)...

Either way, I agree we can't expect them to always make the choices that will
benefit freedom first.

> > Even though this conversation may have taken a harsh tone at times and
> > places, I
> > do believe we share the same views and only disagree on details (which fill
> > up
> > most of our discussions here). I hope this is clear and this discussion
> > doesn't
> > come across as a strong attack against what you're doing!
> 
>  not at all.  it's through these kinds of conversations that i'll be
> able to clarify what the hell it is that i've been up to for five
> years.

Glad that we're good on that :) And yeah, I guess having to explain things makes
it a lot easier to present them clearly afterward.

Cheers,

-- 
Paul Kocialkowski, developer of low-level free software for embedded devices

Website: https://www.paulk.fr/
Coding blog: https://code.paulk.fr/
Git repositories: https://git.paulk.fr/ https://git.code.paulk.fr/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: This is a digitally signed message part
URL: <http://lists.phcomp.co.uk/pipermail/arm-netbook/attachments/20160913/ea1eb9f2/attachment-0001.sig>