Re: Enhancements and fixes for js-encumbered websites

[W. Kosior]

On Fri, 2 Jul 2021 13:36:37 -0500
Colby Russell <js-extensions-discuss@x.colbyrussell.com> wrote:

> 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.)

So you mean installing Cygwin requires administator privileges? Sorry,
I did not know that (although I don't find it surprising).

> 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.

This leads me to yet another consideration. Depending on the
scenario someone might be allowed more or less. Someone in a lab might
even be allowed to set up a GNU/Linux VM. Someone in a library might be
forbidden even from installing browser extensions.

Anyway, my thought was that at some point (just not now yet) we will
start distributing this extension prebuilt and then the availability of
the build process will not be a problem.

> Upstream projects, Hachette included, should be conscious of how
> decisions (like assumption of a POSIX environment) might actually
> hamper the efforts of people affected.

Do you think assuming POSIX in just the build system, after we start
distributing prebuilt versions, will still have the potential to hamper
the adoption? This is a serious question, not ironical one.

> 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.

That's a really good thought.

> 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?)

While this is a fair point in general, the javascript case is
different. Yes, we can make them more free because there are close to
zero people who actually refuse to run all nonfree js. Most freesw
enthusiast do enable it on at least a couple of sites they really need
for some reason. And for those few who don't, life isn't easy. I hope
this project will at some point enable us to make online banking and
shopping possible with free software because, frankly, it is hard to
live without something the entire society relies on.

But in general I still agree: it is important to reach people who never
heard about doftware freedom.

>  > 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.

Sorry, I misunderstood you.

> 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
> itself.

>  > 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.

So by `build.html' you meant an html file with javascript capable of
performing the entire build? This means I misunderstood you even more.
Now, as I am reading your previous message again, it seems pretty clear
what you wanted to propose...

Ok, let's forget what was said before we actually got to what each of
us means.

>  > 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.

Forum offered by Redmine[1] is separate from the actual issues. I think
we could safely use forum as a message board and bugtracker as a
bugtracker. Do you think this is a good approach?

> Neither the bug-librejs nor the fsf-community-team mailing lists are
> particularly appropriate for the current conversation, for example.

Yeah, I just wanted to reach as many ppl as possible. I admit, this is
not nice of me. I decided to prioritize the project over being nice in
this single case. There is some risk this was a bad decision and it will
backfire on me. But I hope it won't.

> 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.

That's understandable. I'll copy some of the email conversations to
the forum and move the technical discussion there.


Wojtek

[1] https://hachettebugs.koszko.org/projects/hachette/boards

-- 
website: https://koszko.org/koszko.html
PGP: https://koszko.org/key.gpg
fingerprint: E972 7060 E3C5 637C 8A4F  4B42 4BC5 221C 5A79 FD1A

pgp2Z_HqcND92.pgp
Description: OpenPGP digital signature