[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [libreplanet-discuss] [Arm-netbook] EOMA68 and freedom in digital te
Luke Kenneth Casson Leighton
Re: [libreplanet-discuss] [Arm-netbook] EOMA68 and freedom in digital technology
Mon, 12 Sep 2016 06:19:38 +0100
crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68
On Sun, Sep 11, 2016 at 2:04 PM, Paul Kocialkowski <email@example.com> 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
> 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.
>> 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
> software. Nevertheless, Olimex has been involved with the linux-sunxi
> 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.
> 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.
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.
> What software they ship, or used to ship by default is IMHO a bit irrelevant.
> They shipped whatever Allwinner provided
... which was GPL violating. which was why i never shipped product.
i waited until the full GPL source was available. which took several
> but always supported community free software effort.
> 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.
at around the same time the linux-sunxi community was set up... but
it *started* on arm-netbook.
>> you're also aware that with the sole exception of
>> the olimex laptop's PCBs the only thing that they provide is
>> auto-generated PDFs *from* the schematics source code... not the
>> actual schematics and certainly not the PCB design files?
> Huh? This is factually not correct. Olimex has released the PCB source designs
> of a number of Allwinner boards. That's what those .brd and .sch files are at:
yeah, elena kindly pointed this out as well [on arm-netbook - thanks
elena, really appreciated that you - and paul too - corrected me here]
i've been head-down on the eoma68 designs for the last three of the
past five years, so wasn't even aware these resources *existed*.
> 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.
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.
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
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?
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?
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.
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
> 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
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.
basically it's highly likely that i'll skip the A64 entirely.
>> > They're also coming up with a laptop design.
>> ... where they've taken off-the-shelf china-sourced (proprietary)
>> casework: i started the GPLv3+ casework project for the EOMA68 15.6in
>> laptop housing *two years* ago as a completely and fully libre
>> project. you can verify that by looking at the git commit logs.
> Of course, I do agree that free mechanical designs are important and a great
> thing to have, so I'm very happy that the EOMA laptop housing design is free.
> But my focus here was about digital technology, not mechanical parts. This is
> out of that scope.
>> tsvetan has caused a hell of a lot of trouble for the EOMA68 project
>> and has sponged off of the resources of a *lot* of people. he truly
>> doesn't understand the word "libre". at all.
> I don't share that perspective.
you didn't see the message he wrote (and deleted in under 48 hours)
when he announced the A64 laptop project. when somebody pointed out
that the A64 SDK was *yet another* example of GPL-violating crapware
from allwinner, and that it contained a proprietary early-bootloader
as well as GPL-violating binary-only libraries (libnand... AGAIN...
god those scripts from tom cubie's manager back in 2011 have got to
die...) tsvetan responded something along the lines of, "to be honest
i really don't understand the fuss over this proprietary blob stuff".
when i returned 48 hours later he'd deleted the message.
> 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.
>> 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
> Of course, we all know that, but that's how you move forward! We can't just
> for the situation to be magically resolved before considering producing
> with it, and staying away from it with a teen-feet-pole before.
> Simply because
> no change will ensue of that. Olimex has the ability to create boards
> that will encourage the community to work on this chip, and also create
> 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.
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).
*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
because they *didn't* put their foot down when it mattered, the sunxi
community is now forced to reverse-engineer libdram.
these kinds of compromises when it matters are *VITAL* lost
opportunities.... all because people like Tsvetan and the team at
Pine64 prefer to take your money.
> So it's really not about what the situation is right now, but about what it
> 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
> 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).
> Also bear in mind that you were able to get the EOMA68 together, with that
> of free software support, in part thanks to people like Tsvetan who put
> (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.
>> 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
> Again, you're looking at the situation right now, which indeed matches what
> 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
> Frankly, I don't care that a device doesn't work with free software right now
> 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
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.
> 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".
> I'm really surprised that you don't see things this way and attack Olimex for
> what level of support their latest products have *right now*.
as you can see from the length of what i've outlined above, it's
complicated. summary is: if you're prepared to prioritise "making
money" over "libre principles", basically you'll never get the source.
continuing to give money to allwinner *without* asking for the source
will basically give them the message that it's *OKAY* for them to
continue to violate the GPL. NextThingCo's ballsy gamble is working.
it's got the message across to the R-Series team that they *have* to
release the source.
remember: allwinner is a complicated company. there are multiple
very powerful investors, all of them carving out their own niches
under the "umbrella" of what we *believe* - from the outside - is a
single unified organisation: nothing could be further from the truth.
>> > 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
> 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.
you have to bear in mind that the reactions of various people back in
2011 to what i was doing were so "wtf??" that i realised that i wasn't
going to get anywhere until i had working hardware. that took 3-4
years to get to the crowdfunding campaign, which meant that there's
been 3-4 *years* where i've been almost completely out of the picture
in the software libre world, it's been so intense that i had to just
"get on with it" (and i realised that i wasn't going to get any help,
so *had* to get it done myself).
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).
> 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
> 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
... oops... :)
> 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.
>> *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.
>> > > 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
> 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). so if you *only*
focus on the modularity, you'll be completely lost and won't
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
> "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?
>> > 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
> 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.
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.
> 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 :)
>> 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
> along, not commitment. I do agree that commitment such as the one displayed
> 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? :)
> 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...
... 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"
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
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.
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
> 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
>> .... 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
> 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)...
> 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
> 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
Re: [libreplanet-discuss] [Arm-netbook] EOMA68 and freedom in digital technology, Paul Kocialkowski, 2016/09/11
- Re: [libreplanet-discuss] [Arm-netbook] EOMA68 and freedom in digital technology,
Luke Kenneth Casson Leighton <=