[Arm-netbook] eoma68-jz4775 x-ray pictures

Luke Kenneth Casson Leighton lkcl at lkcl.net
Fri Apr 29 11:55:01 BST 2016


hiya phil,

ok apologies for being slightly ahead and quite short, as you know i'm
on limited time, so made a beeline for the conclusion.  lots of steps
that i left out, so this is, by necessity, very long, as it goes
logically through step-by-step each part of the chain of reasoning.
and, at each phase of that reasoning, i trust that you can see clearly
that at NO TIME is "deliberately causing harm or projecting malice
towards ANY party" something that i have time for.

as you know, i am quite goal-orientated.  i define goals, and i go for
them, directly.  to define one of those goals to include a sub-goal of
"deliberately cause physical, mental or emotional harm to a specific
person or group" as part of that goal would be... a definite "wtf"
moment, shall we say.  it would be... illogical, captain.  not least,
it would be a total waste of my time to include such a sub-goal, and,
even MORE importantly, such a sub-goal would actually risk destroying
any possibility of completing the main goal.

when you think of it in these terms, saying to me that i've either
explicitly, implicitly or otherwise "said that A Person Is Bad" and
thus causing them distress - such a thing cannot possibly be the case.
now, it's almost certainly the case that i don't use the right words,
or that i simply missed out "the usual words" which someone else might
know and use during a normal conversation: i'm simply too focussed on
what i'm doing to include them.

so i'm going to great lengths, below, to make an effort to include
words like "respect" - a *lot*.  it took a long time to do that, and
it was a major distraction, taking up almost 90 minutes to construct
an appropriate response.

if we can work out a way where i don't have to spend such an enormous
amount of time doing that again, in the future, i would be interested
to hear some proposals.


---
crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68


On Fri, Apr 29, 2016 at 8:59 AM, Philip Hands <phil at hands.com> wrote:

>>  all of this i should actually be able to code up myself, by redoing
>> that initial package and making sure that there's a separate
>> (overriding) repository with pinning on that replacement
>> debian-archive-keyring package.  means recompiling debian-installer
>> but that's cool.
>
> You wouldn't need to recompile anything, I suspect -- you _might_ need to
> replace the relevant udeb, or you can probably do some sort of (possibly
> somewhat disgusting) kludge via preseeding.

 cooool :)

> Most probably, if you have a sensible patch, it could be made into
> preseedable debconf variable ("fsf-endorsable-mode"?).
>
> Of course, the fact that is an option that could be turned off means
> that it's not going to satisfy the people that want Debian to make it so
> that some of our users will be unable to use their (crappy and annoying)
> hardware.  So, it's probably not worth bothering with.

 second sentence: given that all the other forks of various distros
are extremely lacklustre, seriously out-of-date with regard to
security updates and actual maintenance, my feeling is that it's
definitely worth tackling this.  if you can get an installation of
plain debian packages that's FSF-Endorseable, *great*.  less effort,
more modern, up-to-date and more secure.

 first sentence: i don't quite follow, but let me make a guess, tell
me if i'm near the mark.  based on the assessment here
http://mail.fsfeurope.org/pipermail/discussion/2016-April/010912.html
the implications are that the only hardware that a seller can get on
which you can apply for a RYF Certificate is.... really old and only
getting older.  thus it's really annoying.  so, this bit i absolutely
agree with, but - not that this is what you're saying in any way - i
don't see a connection to an assessement as to why anyone should not
*try* (to either provide better hardware, or to work out a way to
leverage vanilla debian for RYF Certification).

 i'm still having difficulty parsing the first bit of the sentence:
i've got a venn diagram in my head with about three or possibly four
different points that you're making in the sentence, and the
conditionals and negations are more than i can manage - sorry!

 let me move on, then - i believe the main thing you're saying which
is important is below, about the debian social contract.

> Debian will not make the experience worse for those users, to no real
> benefit to other users, because we have a Social Contract that ensures
> that we will not get in the way of people that want to use our software
> for things that we almost certainly disagree with.

 great!  sounds fantastic and it's why i love debian, that the social
contract is there and is basically inviolate.

> Apparently some people think it's important to make Debian a tiresome
> experience for those that were foolish enough to no know the exact
> chipset that was going to be in whatever hardware they bought, and thus
> found that it (currently) needs its proprietary firmware uploaded.

 ok.  so.   here's where it gets interesting, but let's answer the
other paragraph first....

> Of course, they think it's totally fine if the same crappy hardware has
> it's offensive firmware welded into a chip instead, but let's not worry
> about that too much, eh?

 companies are finding out the hard way that that's a bad idea.  of
course, they're replacing it with firmware that's RSA-signed and
DRM-locked - treacherous-zone for example.


 but leaving all that aside, what would happen if a hardware vendor
*deliberately* picked hardware *in advance* that did *NOT* require
proprietary firmware and did NOT have anything that could fall foul of
the usual justifications for having a nonfree section in debian?

 what if the people who bought that hardware were, as a general rule,
*never* going to want to install a piece of nonfree firmware in their
lives, because they had had it "up to here" [insert visual image of
putting hand flat, palm down, way over top of head] not with "The
Usual Way That People View The FSF" but with the plain and simple
irritating crap revolving around upgrades where stuff broke ALL the
F******G TIME because some piece of critical proprietary firmware
suddenly became incompatible or was deleted or corrupted or was
removed as part of the upgrade process... a ton of reasons which we
all know.

 those are the people that chris serves with his business.  people buy
hardware from thinkpenguin because it just *damn well works*.

 so.  under this scenario, the likelihood of such people even ever
*needing* a nonfree repository is precisely and exactly zero.



> The obvious unintended consequence of making Debian tiresome for those
> users is that they will be driven to use Ubuntu or something even less
> free that does support the hardware sitting in front of them.

 hooray! :)  they can go away and stay on the php forums specially set
up for them, where they'll leave everyone else alone.  hooray! :)


> Having switched away from Debian, those people will probably never worry
> about the non-freeness of their hardware again.
>
> If they continue with Debian, they continue to have the chance to notice
> the "-nonfree" bit of the package name, and notice that there's other
> stuff that's cluttering up their system, and think about disabling it to
> see what breaks, and then maybe include that new knowledge in their next
> purchasing decision.
>
> So, feel free to do whatever you are moved to do, but when you start
> spouting your overly-definite statements about how good or bad you think
> Debian is when judged on this basis, you're making the perfect the enemy
> of the good, and you're alienating your friends and allies while you're
> about it.

 i appreciate that you're likely talking to a wider audience here than
this one, and thank you for explaining.  i assume you're referring to
other people who *might* make the mistake of explicitly saying that
"debian is bad because it includes non-free".  certainly nobody here
has made such a hypothetical statement, implicitly or explicitly.

 if this discussion has given the *impression* of saying "debian is
The Enemy Because It Includes Non-Free" then you are absolutely wrong.
the whole idea of the EOMA projects is to bring to market a subset of
available modern and continuously up-to-date hardware that simply
doesn't *need* the nonfree repository of debian.  nobody is saying
"people are bad because of an inviolate Social Charter".


> That press release is from 2014 BTW, so it's not exactly news that this
> issue is really not much of an issue.  The way you talk about it gives
> the impression that Debian encourages people to use non-free software,

 nobody's said anything remotely like that in these discussions.

 there's a very specific subset of the venn diagram here, which is
being discussed.  the options are:

 * hardware which requires non-free firmware vs hardware which doesn't (ever)
 * debian which includes the non-free archive vs when debian doesn't
have the non-free archive

so to be absolutely clear: the ENTIRE segment of non-free hardware is
eliminated from these discussions.  that has the implication of making
the non-free debian archive *REDUNDANT* but ****NOT DISRESPECTED IN
ANY WAY SHAPE OR FORM, BY IMPLICATION, EXPLICIT STATEMENT OR
ASSUMPTION****.

 we RESPECT the debian community for providing the non-free
repository.  we just don't need it, because it's irrelevant to the
target hardware and to the target market... but to repeat: just
because it's not needed, does NOT in ANY WAY imply any disrespect or
any kind of "BadNess".

 at this point i'm probably overstating the point, made in several
different ways, but that's probably a good thing.

 so, is it absolutely clear now that there is nobody who is
disrespecting debian for honouring the debian social contract?



> whereas Debian/Debian Developers were for instance instrumental in
> moving binary blobs out of the kernel, something that is a pre-requisite
> to being able to have a Free Software Linux system at all.

 very cool.


 ok.

 so.

 let's assume that it's been accepted that nobody is disrespecting
anybody else for what they are doing.  let's please also assume that
NO STATEMENT EVER MADE is disrespecting anybody for anything - without
making it necessary to clutter up the entire discussion with caveats
and additional sentences re-stating that continuously.  which i might
end up doing anyway.  it's tiresome to do that, so let's agree in
advance that it hasn't happened, isn't happening, and isn't going to
happen.

 moving on.


 the hardware situation is: there's no proprietary firmware required.  period.

 the software situation is: in debian, a nonfree repository is easy to
add, and is possible - and convenient - to add by default during the
installation as well as during normal operation [see preamble sentence
above about not reading into this as being "disrespectful" in any way:
it's just stating the facts].

 the FSF situation is: they state that having non-free software on
your system is detrimentally risky (because of the unknowns),
therefore rather than have the users do a half-way-house risk
assessment (which most people are not equipped mentally to do), they
go the "whole hog".

 an RYF Certification is therefore only possible if:

 (a) the software source code is entirely libre, right down to
power-up (boot time) of the hardware.

 (b) the installation of proprietary software, whilst *NOT*
prohibited, must at the very least not be made "convenient".

 assessment of (b) is made on a case-by-case basis, but let's be
absolutely clear, here:

 (1) buying an RYF-Certified product then ripping out the OS and
putting proprietary software on it is a right of the user that the FSF
fully respects.

 (2) buying an RYF-Certified product then installing proprietary
software on a libre, RYF-Certified OS is a right of the user that the
FSF fully respects.

 (3) buying an RYF-Certified product, then plugging in peripherals or
other hardware upgrades which REQUIRE non-free firmware is, again, a
right of the user that the FSF fully respects.

in all cases, however, none of those things are the FSF's problem, nor
are they the RYF-Certified product vendor's problem.  note, again,
however, that the word "respect" has been used above, just as it has
been used in relation to the debian developers, the charter, and
everything associated with debian.

so - with that in mind, and having respect for ALL parties involved,
now we come to re-stating the possible scenario where the
*possibility* exists for Debian to be on an RYF-Certified product (one
which, as-supplied, is *defined* as having no hardware which requires
proprietary firmware or software to operate).

.... this is, btw, all just a logical chain - a subset of the venn
diagram of possibilities.  no "disrespecting" ever even enters the
discussion.  "disrespect" or "emotional harm" to ANY party is NOT part
of the venn diagram.  it is NOT ONE OF THE GOALS.  why on god's green
earth anyone would wish to include "emotional harm" as an additional
sub-goal in a project which furthers libre software, i really don't
know - but i'm certainly not going to have people using this list to
inflict harm on others.


so, taking all the requirements into account, whilst respecting all
parties at the same time, the simple logical intersection and result
is, quite reasonably and rationally:

(1) to modify the debian installer (perhaps by doing preseeding) so
that the question "do you wish to install the nonfree archive" is
simply not asked [does this disrespect anyone in debian for adding
this as a possibility? no it does not].  this is to satisfy criteria
(b) above, whilst also at the same time RESPECTING the Debian Charter.
see below as to why.

(2) to move the nonfree archive GPG key into a separate package, which
is then not installed.  this again satisfies FSF criteria (b), above.

this basically satisfies and respects the both the Debian Charter and
the FSF's requirements, without implying any disrespect for either.
what is STILL POSSIBLE for an end-user to do is as follows:

 (3) at any time, an end-user MAY still install that [hypothetical]
keyring for the nonfree archive.  it will be slightly inconvenient.
lots of steps will be needed, such as maybe even downloading a dpkg
and running as root, and following written instructions.

 (4) once that package is installed, they will then need to edit
/etc/apt/sources.list - by hand.  this, again, will be slightly
inconvenient - and to add "nonfree" to the sources.list debian archive
line.

 this "inconvenience" is an extra hoop which i believe would help
satisfy the FSF's criteria in a respectful way whilst, critically, NOT
actually preventing the end-user from doing it in the first place.
and that, i believe, would mean that it also satisfies and respects
the *Debian* Social Charter, because it's not actually stopped
end-users from doing something that they want to do.

 now, here's where we "split", should the hypothetical scenario become
a reality.

 * scenario (1) - this is all done independently of and without
involving debian developers in any way.  the debian-archive-keyring
package is *replaced* with an over-ride package which simply removes
the nonfree GPG key.   this is the initial approach that i was
considering taking, phil.  discussions with debian developers aren't
even on the table in this scenario!  that's not being disrespectful,
it's just... not needed in order to achieve the goal.

 * scenario (2) - debian developers are brought into the loop.  here's
where it would get interesting, because a decision would need to be
made about where the {hypothetical-nonfree-keyring} package would
actually be kept (i.e. in which achive).  i *hope* that, on assessing
this, the debian developers would appreciate that the sensible place
to put it would be in the nonfree repository itself, *not* in main,
and that a udeb would be created which debian-installer would download
explicitly if and only if the question "do you want nonfree" was ever
answered "yes" during an install.

 now, in scenario (2), i trust you can see clearly why the
{hypothetical-nonfree-keyring} would need to go into the nonfree
archive itself (because that would satisfy the FSF's "make it
inconvenient but not impossible to install non-free software"
requirements), and why the udeb would be needed (because that would
satisfy Debian's Charter to "make it convenient and don't stand in the
way of anyone doing anything with their hardware and software"
requirements).  once the udeb is installed, you'd have the
{hypothetical} non-free GPG public key on your system [forever, unless
removed], and thus it would be convenient to install nonfree packages.

 *but*, what's nice is, both camps are happy and totally separate....
out of the exact same mirrors.  it's just organised slightly
differently.  everyone - all parties - can do what they want.

 sharing an insight with you, when this is laid out like this, i see
no reason why this should not be viewed as a "next logical step" by
the debian developers, moving on from their excellent and tireless
work to move nonfree blobs out of the linux kernel.

 also, it's inclusive and respectful of those people who would like to
follow the FSF's advice.  or, even if they don't, who just don't want
any hassle, just like chris's customers, and they'd like to go
one-stop shopping with someone they trust.

 thoughts and insights appreciated.

l.



More information about the arm-netbook mailing list