Which developer operating systems do we support?

[brainwane]

Type: code issue

Followup for #13597:

Come to think of it, we should probably create a list of platforms we wish to be supported, and then use that as a guide for which platforms we should actively work on to support.

Let's have that discussion here -- there's a bunch of relevant discussion in #13597 . I assume that we'll try to support a few recent Windows versions, a few recent versions of common Linux distributions, and a few recent Mac OS X versions; the way we do that may involve Vagrant or some other virtualization approach. And we could work on a cloud solution like what Zulip provides to some contributors as well.

[jeremyn]

We need to articulate what the goals are here or this will just be people spitballing popular and/or their personal favorite OSes.

We also need to decide what "supported" means. To me, supported means up-to-date documentation, automated tests, and someone at the EFF who is willing to help a contributor with their build error. (You can't rely on volunteers here since volunteers are free to ignore issues if they want, and that's not support.)

I also presented some alternative ideas in #13597 (comment) to increasing the number of potential contributors besides just increasing the number of supported platforms. It would be nice to get feedback on that. (Another alternative I didn't suggest there is for the EFF to simply run its own public server and give out shell access to established contributors who want it. This has some potential problems but might be cheaper overall than requiring @Hainish to do tech support.)

[wonderchook]

@jeremyn in your comment what path are you thinking to be more Windows friendly? Doing something other than WSL for development?

I've worked a lot in emerging economies and almost everyone was running Windows, though I think with clear instructions the WSL path wouldn't be too bad. That said if someone was in a low bandwidth environment it might be annoying to download.

[jeremyn]

@wonderchook WSL works for people using Windows 10 with reasonably good equipment/internet access who are familiar with Linux. I suppose most of these people are also capable of creating a VM, setting up a VPS, dualbooting Linux, or at least capable of figuring out how to do one of those things. So WSL support isn't about enabling access to people who couldn't participate before, but reducing their barrier to entry (aka enabling their laziness if you want to be uncharitable about it).

People with very low resources (ancient computer, Windows XP/Vista, shared and expensive dial-up) should probably be steered toward cloud/remote development, or the CodeMirror tool with GitHub for ruleset work. I'm interested in your thoughts here, especially with your expertise in emerging economies.

Native Windows support could encourage participation by people with low and/or Windows-only tech knowledge who have access to good equipment/internet access. On one hand, more participation sounds good, but on the other hand I'm concerned about attracting people who will need heavy guidance on basic stuff like git commands. Some technical knowledge should be assumed.

There's an issue (#5101) discussing making HTTPS Everywhere available for Edge. I don't know how Edge extension development works but it might require native support.

[wonderchook]

@jeremyn in the areas I've worked people had cheap, but pretty new laptops rather than ancient ones. That was why I was thinking at least in some places they would be more inclined to have Windows 10.

I'm not against the idea of Native Windows support, though I was picturing it would require a complete rewrite of the install script. As you mentioned the expectation of people having some basic technical knowledge was making me think they could handle WSL or other options.

I was reading through the Edge discussion, prior to it I had not actually ever opened Edge. So I don't know much about developing on it.

[jeremyn]

I'm not in favor of either WSL or native Windows development, as I've said before, with the possible exception of enabling Edge development if native support is required for that to happen. This project is full of half-developed/half-supported/abandoned stuff, I don't want to add to that list. The best hope of getting something well-supported is to funnel everyone into the same dev environment.

It's maybe worth noting that @Hainish, the primary person here, literally did not have a Windows system available to test with as of this week and had to order one (#13731 (comment)). This is not a good sign for what Windows support would look like in, say, a year.

[jeremyn]

Amazon recently announced their AWS Cloud9 service.

AWS Cloud9 is a cloud-based integrated development environment (IDE) that lets you write, run, and debug your code with just a browser. It includes a code editor, debugger, and terminal.
...
AWS Cloud9 gives you the flexibility to run your development environment on a managed Amazon EC2 instance or any existing Linux server that supports SSH.

Maybe we want to look into this, or some other cloud development environment.

[Hainish]

@jeremyn said:

It's maybe worth noting that @Hainish, the primary person here, literally did not have a Windows system available to test with as of this week and had to order one (#13731 (comment)). This is not a good sign for what Windows support would look like in, say, a year.

I expect our backend dependencies not to shift much here. Once we have established a build process for a specific platform, it should only require maintenance if our dependency graph changes, or the underlying build system becomes out of date. So forming a cost-benefit analysis on OS support should account for this as a factor.

That being said, I'm not convinced we should support Windows, and was intending to use the Windows device to test proper operation of the ruleset debugger (#13731) which does not require building from source. I don't have much of an opinion about supporting Windows as a development environment. Rulesets can now be debugged and written from the extension itself.

While most people in the world are using Windows as their desktop OS, I don't see it in high usage as an open-source development platform. @wonderchook has pointed out that this might be a self-perpetuating problem, so there is that factor as well. I'm inclined to give support for Windows via WSL a good-faith try, assessing how difficult it will be to build support. Taking an initial shot at it should at the very least reveal how difficult it will be, and we can re-evaluate from there.

[wonderchook]

Development using Windows 10 with WSL works already. I had one little snag when I tried it, but that was because I git cloned into Windows. dos2unix and then it worked. I think the only specific recommendation I would make for using this method is to run git directly within the sublinux system rather than in Windows itself.

[jeremyn]

I've made my position pretty clear and don't really want to keep going on about it. I think anyone who proposes supporting a new OS should also describe how they are going to make sure contributors don't encounter the sorts of problems I did with Fedora described in #5584 (comment) and #5628 (comment), not just immediately after support is added but also a year or two later on.

[jeremyn]

FYI, I created a Docker configuration for HTTPS Everywhere development at https://github.com/jeremyn/https-everywhere-docker-environment. It works on an Ubuntu 16.04 system, but hangs on a Windows 10 system. I don't know about macOS.

It's not perfect, but I think Docker is probably the "2018 way" of doing cross-platform development.