[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Enhancements and fixes for js-encumbered websites

From: Colby Russell
Subject: Re: Enhancements and fixes for js-encumbered websites
Date: Fri, 2 Jul 2021 13:36:37 -0500
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0

On 7/2/21 4:10 AM, W. Kosior wrote:
> is it really likely someone running Losedows will be interested in
> building the extension? [...] How about we instead tell Losedows users
> to install Cygwin?

This assumes that the user is in that moment using a machine that they
either own or have sufficient control over to install something like
Cygwin.  (And indeed, if that were the case, we wouldn't instruct them
on how to install Cygwin--we'd recommend installing a full GNU system.)

I mentioned this in my last message: consider someone who has heard the
message and has aligned themselves with free software ideals and the
movement but is nonetheless forced to use a shared workstation, e.g. in
a lab, or they find themselves at the public library and having to use
one of its computers.  They are unlikely to already be running free
software.  A conscientious person trying to exercise their freedom under
these circumstances will by necessity seek to minimize their use of
non-free software.  Upstream projects, Hachette included, should be
conscious of how decisions (like assumption of a POSIX environment)
might actually hamper the efforts of people affected.

It should go without saying that the objective of any free software
project should be to--as in the case of Hachette itself--survey the
places where the light of free software has not reached and work towards
fixing that.  That is, we should not be overly concerned with people who
are already able to use and are using free software.  (It's not like we
can make them "more free", can we?)  The goal should be to concern
ourselves with those who would like to exercise their freedoms but
presently cannot, as in the cases I described.  It is under similar
circumstances where the birth of the movement began, after all.

> The build process is somewhat too complicated for a user to perform by
> hand

I wasn't talking about a human manually performing the full build process
themselves.  I meant that so long as we're providing our build script in
the form of a `build.html`, we might as well exploit the roots of the
format (for conveying document structure) and include all the relevant
information (about *how* to use the build script) within that file

> other approach that comes to my mind is writing a .bat script that
> would be an equivalent of build.sh

But why would you?  You wouldn't need _any_ platform-specific build
script.  Just use `build.html` across all systems.  Browser behavior is
at least as consistent (arguably even moreso) from the different vendors
as the the various POSIX/freedesktop implementations that any given user
might be using.

> You mean documenting the build process?

Huh?  No.  Well, yes, I guess.  But I'm talking about being available
for mainline development.

> do you all think we should set up a mailing list for the project?

Not especially a fan of mailing lists, but at least in the meantime it
would be a good idea.  Having some place to discuss things that doesn't
devolve into polluting the bugtracker by treating it like a message
board--as is the fashion across repos for projects hosted on
GitHub--would be essential.  Neither the bug-librejs nor the
fsf-community-team mailing lists are particularly appropriate for the
current conversation, for example.

Really, I just wanted to make sure that if I'm not involved initially
that I don't lose track of future developments, announcements, etc.

Colby Russell

reply via email to

[Prev in Thread] Current Thread [Next in Thread]