Re: Packaging a free Firefox
Hi Pjotr, Pjotr Prins writes: > On Mon, May 21, 2018 at 04:07:10PM -0400, Mark H Weaver wrote: >> Pjotr Prins writes: >> >> > On Fri, May 18, 2018 at 06:14:24AM +0200, Pjotr Prins wrote: >> >> When Icecat stops crashing it will be totally useful for most people >> >> (95%). >> > >> > Now I am on fast internet I have far less crashes. Looks like it is a >> > JS timeout of sorts. I am on 45.5.1, so next step is an upgrade. >> >> 45.5.1? That's ancient, with a large number of known security flaws. >> Why are you running such an old version? > > Just to say that I upgraded to 52.6.0 and it is really stable. Thanks > for all that! I'm glad to hear it! Thanks for letting me know. Mark
Re: Packaging a free Firefox
On Mon, May 21, 2018 at 04:07:10PM -0400, Mark H Weaver wrote: > Pjotr Prins writes: > > > On Fri, May 18, 2018 at 06:14:24AM +0200, Pjotr Prins wrote: > >> When Icecat stops crashing it will be totally useful for most people > >> (95%). > > > > Now I am on fast internet I have far less crashes. Looks like it is a > > JS timeout of sorts. I am on 45.5.1, so next step is an upgrade. > > 45.5.1? That's ancient, with a large number of known security flaws. > Why are you running such an old version? Just to say that I upgraded to 52.6.0 and it is really stable. Thanks for all that! Pj.
Re: Packaging a free Firefox
Pjotr Prins writes: > On Mon, May 21, 2018 at 04:07:10PM -0400, Mark H Weaver wrote: >> 45.5.1? That's ancient, with a large number of known security flaws. >> Why are you running such an old version? > > Ancient? November 2016 released. Ancient is my thinpad and ancient is > me ;). Security matters, but my system is not *that* vulnerable. Note > that I run the browser in a degraded mode (noscript, noflash etc.). > That actually matters most. November 2016 is ancient for a web browser, which has an extraordinarily large attack surface. While it's true that disabling javascript helps, there are known vulnerabilities in several other parts of the code. Your system is vulnerable to attack. If you think otherwise, you are mistaken. Mark
Re: Packaging a free Firefox
On Mon, May 21, 2018 at 04:07:10PM -0400, Mark H Weaver wrote: > 45.5.1? That's ancient, with a large number of known security flaws. > Why are you running such an old version? Ancient? November 2016 released. Ancient is my thinpad and ancient is me ;). Security matters, but my system is not *that* vulnerable. Note that I run the browser in a degraded mode (noscript, noflash etc.). That actually matters most. I'll upgrade when I have the bandwidth and time. Pj.
Re: Packaging a free Firefox
Hello, Mark H Weaver writes: > Pjotr Prins writes: > >> On Thu, May 17, 2018 at 12:57:22PM -0500, Christopher Lemmer Webber wrote: >>> > Under the conditions (for packaging torbrowser) I talked about >>> > with Torbrowser-project >>> > it is okay to ship it fully branded. I will have to get back to >>> > them as soon >>> > as I am past the current bug and got it building. >>> >>> Hey, that's great news! Thank you :) >> >> That is really cool! Where libre shines :) >> >> When Icecat stops crashing it will be totally useful for most people >> (95%). >> >> For web developers or people who want/need a cutting edge Firefox >> browser, including it would be useful too. > > Did you know that Torbrowser is based on the same Firefox ESR 52 that > IceCat is based on? > Tor browser user here! It is currently based on 52.8.0 > Mark signature.asc Description: PGP signature
Re: Packaging a free Firefox
Pjotr Prins writes: > On Thu, May 17, 2018 at 12:57:22PM -0500, Christopher Lemmer Webber wrote: >> > Under the conditions (for packaging torbrowser) I talked about with >> > Torbrowser-project >> > it is okay to ship it fully branded. I will have to get back to them as >> > soon >> > as I am past the current bug and got it building. >> >> Hey, that's great news! Thank you :) > > That is really cool! Where libre shines :) > > When Icecat stops crashing it will be totally useful for most people > (95%). > > For web developers or people who want/need a cutting edge Firefox > browser, including it would be useful too. Did you know that Torbrowser is based on the same Firefox ESR 52 that IceCat is based on? Mark
Re: Packaging a free Firefox
Pjotr Prins writes: > On Fri, May 18, 2018 at 06:14:24AM +0200, Pjotr Prins wrote: >> When Icecat stops crashing it will be totally useful for most people >> (95%). > > Now I am on fast internet I have far less crashes. Looks like it is a > JS timeout of sorts. I am on 45.5.1, so next step is an upgrade. 45.5.1? That's ancient, with a large number of known security flaws. Why are you running such an old version? Mark
Re: Packaging a free Firefox
On Fri, May 18, 2018 at 06:14:24AM +0200, Pjotr Prins wrote: > When Icecat stops crashing it will be totally useful for most people > (95%). Now I am on fast internet I have far less crashes. Looks like it is a JS timeout of sorts. I am on 45.5.1, so next step is an upgrade. Pj.
Re: Packaging a free Firefox
On Thu, May 17, 2018 at 13:34:37 +0200, Ludovic Courtès wrote: > I wonder why IceCat is based on an ESR, and what it would take to have > it follow Firefox releases more closely. IWBN if IceCat could be pretty > much like Linux-libre, i.e., a set of scripts that semi-automatically > adjusts the Firefox source (I’m not sure if that is the case currently.) Its maintainer was struggling to keep up with any releases at all, which is why Mark Weaver stepped up backporting security patches for Guix. I'm not sure how much effort is involved with running the script and issuing a new release. > At any rate, people interested in this should probably team up with the > IceCat people (person?) to see how we can together move in the right > direction. Please do contact maintain...@gnu.org if anyone is interested! Rubén Rodríguez is IceCat's maintainer and is an employee at the FSF. I proposed to both rms and John Sullivan at different points that maybe IceCat maintenance can be made part of Rubén's responsibilities at the FSF. The FSF recently announced a paid contact position for LibreJS, so maybe at some point IceCat can see some attention too. -- Mike Gerwitz Free Software Hacker+Activist | GNU Maintainer & Volunteer GPG: D6E9 B930 028A 6C38 F43B 2388 FEF6 3574 5E6F 6D05 https://mikegerwitz.com signature.asc Description: PGP signature
Re: Packaging a free Firefox
On Wed, May 16, 2018 at 06:10:28PM +0200, Tonton wrote: > I guess channels already sort of exist. have a git repo or similar with > whatever guix packages in it and point $GUIX_PACKAGE_PATH at it. Then all > packages defined in your git repo are suddenly part of your available guix > packages. The GUIX_PACKAGE_PATH works on an individual basis. When it comes to sharing it is totally inconvenient. I know because we are using it in production. The main problems are (1) people need to check out a source tree to use it - with troublesome instructions and slow install routes (typically a few hours) and (2) the git versions of the GNU Guix repo has to be in sync with the GUIX_PACKAGE_PATH repo. With my collaborators we often face problems - even yesterday we had a package conflict. One reason we channels are slow in coming is because they need to resolve multiple problems. But in a nutshell they are about sharing software that is not in Guix mainline, divert responsibility to channel maintainers, while providing fast trusted binary installs. One thing that needs to be resolved is how much we share with the Guix trunk (i.e., the running Guix with pull). My current thought is that we should share *nothing*. This is the only way to have reproducible installs from channels. Of course the risk is that the daemon goes out of sync. But I think we can handle that if the guix client makes sure incompatibilities are notified. The channel should be updated to support updated daemons. You can see that thinking this through is non-trivial and Guix maintainers probably realize there are more problems ;) At this point everyone is hacking it their own way. Witness people writing their own packages for firefox. Would be nice to have a consistent path where we can be more efficient. Pj.
Re: Packaging a free Firefox
On Thu, May 17, 2018 at 12:57:22PM -0500, Christopher Lemmer Webber wrote: > > Under the conditions (for packaging torbrowser) I talked about with > > Torbrowser-project > > it is okay to ship it fully branded. I will have to get back to them as soon > > as I am past the current bug and got it building. > > Hey, that's great news! Thank you :) That is really cool! Where libre shines :) When Icecat stops crashing it will be totally useful for most people (95%). For web developers or people who want/need a cutting edge Firefox browser, including it would be useful too. I really think GNU Guix should support that use case, if we can under our GNU constraints. Pj.
Re: Packaging a free Firefox
Nils Gillmann writes: > Christopher Lemmer Webber transcribed 1.2K bytes: >> Nils Gillmann writes: >> >> > Ludovic Courtès transcribed 1.1K bytes: >> >> Hello Katherine, >> >> >> >> Katherine Cox-Buday skribis: >> >> >> >> > E.g. I've seen several people in this thread mention they had already, >> >> > or were trying to, package Firefox (myself included). Had there been an >> >> > official non-libre channel, this work might not have been duplicated. >> >> >> >> There will never be an “official” non-libre channel in that Guix as a >> >> project will not provide such a channel. >> >> >> >> Now, Firefox *is* free software, so there’s could be an official >> >> “firefox” package, but in essence, it would have to incorporate pretty >> >> much the same changes that IceCat provides. >> >> >> >> I wonder why IceCat is based on an ESR, and what it would take to have >> >> it follow Firefox releases more closely. >> > >> > I am not involved or speaking for Icecat, but ESR is moving slower than >> > Firefox "master" channel. This alone is good enough to base on it for >> > long-term support when you are a downstream vendor such as Torbrowser, >> > Icecat, or a simple company running a site-specific Firefox. >> >> It would be really nice to be able to have tor browser bundle in GuixSD. > > TL;DR is we can have it and I will pick up work on it again pretty soon. > (We had the idea for a custom browser based on Torbrowser, so I have a > requirement beyond simply using it.) > > Under the conditions (for packaging torbrowser) I talked about with > Torbrowser-project > it is okay to ship it fully branded. I will have to get back to them as soon > as I am past the current bug and got it building. Hey, that's great news! Thank you :)
Re: Packaging a free Firefox
Christopher Lemmer Webber transcribed 1.2K bytes: > Nils Gillmann writes: > > > Ludovic Courtès transcribed 1.1K bytes: > >> Hello Katherine, > >> > >> Katherine Cox-Buday skribis: > >> > >> > E.g. I've seen several people in this thread mention they had already, > >> > or were trying to, package Firefox (myself included). Had there been an > >> > official non-libre channel, this work might not have been duplicated. > >> > >> There will never be an “official” non-libre channel in that Guix as a > >> project will not provide such a channel. > >> > >> Now, Firefox *is* free software, so there’s could be an official > >> “firefox” package, but in essence, it would have to incorporate pretty > >> much the same changes that IceCat provides. > >> > >> I wonder why IceCat is based on an ESR, and what it would take to have > >> it follow Firefox releases more closely. > > > > I am not involved or speaking for Icecat, but ESR is moving slower than > > Firefox "master" channel. This alone is good enough to base on it for > > long-term support when you are a downstream vendor such as Torbrowser, > > Icecat, or a simple company running a site-specific Firefox. > > It would be really nice to be able to have tor browser bundle in GuixSD. TL;DR is we can have it and I will pick up work on it again pretty soon. (We had the idea for a custom browser based on Torbrowser, so I have a requirement beyond simply using it.) Under the conditions (for packaging torbrowser) I talked about with Torbrowser-project it is okay to ship it fully branded. I will have to get back to them as soon as I am past the current bug and got it building.
Re: Packaging a free Firefox
Nils Gillmann writes: > Ludovic Courtès transcribed 1.1K bytes: >> Hello Katherine, >> >> Katherine Cox-Buday skribis: >> >> > E.g. I've seen several people in this thread mention they had already, >> > or were trying to, package Firefox (myself included). Had there been an >> > official non-libre channel, this work might not have been duplicated. >> >> There will never be an “official” non-libre channel in that Guix as a >> project will not provide such a channel. >> >> Now, Firefox *is* free software, so there’s could be an official >> “firefox” package, but in essence, it would have to incorporate pretty >> much the same changes that IceCat provides. >> >> I wonder why IceCat is based on an ESR, and what it would take to have >> it follow Firefox releases more closely. > > I am not involved or speaking for Icecat, but ESR is moving slower than > Firefox "master" channel. This alone is good enough to base on it for > long-term support when you are a downstream vendor such as Torbrowser, > Icecat, or a simple company running a site-specific Firefox. It would be really nice to be able to have tor browser bundle in GuixSD.
Re: Packaging a free Firefox
Ludovic Courtès transcribed 1.1K bytes: > Hello Katherine, > > Katherine Cox-Buday skribis: > > > E.g. I've seen several people in this thread mention they had already, > > or were trying to, package Firefox (myself included). Had there been an > > official non-libre channel, this work might not have been duplicated. > > There will never be an “official” non-libre channel in that Guix as a > project will not provide such a channel. > > Now, Firefox *is* free software, so there’s could be an official > “firefox” package, but in essence, it would have to incorporate pretty > much the same changes that IceCat provides. > > I wonder why IceCat is based on an ESR, and what it would take to have > it follow Firefox releases more closely. I am not involved or speaking for Icecat, but ESR is moving slower than Firefox "master" channel. This alone is good enough to base on it for long-term support when you are a downstream vendor such as Torbrowser, Icecat, or a simple company running a site-specific Firefox. From Firefox; I remember reading Icecat ran into the same problems building beyond 54.x than I have, but I might be wrong. In any case ESR as long as it does provide the Off switch for rust should be kept around. After 54.x it's up to those who solve the problems our build system (and presuable other systems too) gets with the crates. > IWBN if IceCat could be pretty IWBN? What does that mean? > much like Linux-libre, i.e., a set of scripts that semi-automatically > adjusts the Firefox source (I’m not sure if that is the case currently.) > > At any rate, people interested in this should probably team up with the > IceCat people (person?) to see how we can together move in the right > direction. > > Ludo’. >
Re: Packaging a free Firefox
Mark H Weaver writes: > Can you tell me specifically what is wrong with GNU IceCat that makes it > unsuitable for you? It has been my primary browser for several years. I don't think aiming to change a user's motivations is a winning game, but I can enumerate why I personally wanted to use Firefox. Maybe it will help make Icecat better. - Icecat doesn't have any of the new, more performant, pieces Mozilla have been integrating into Firefox (quantum, sevro). - Icecat doesn't have the account synchronization meaning I didn't have access to bookmarks, history, synced tabs, etc. - Icecat very _strangely_ came preinstalled with extensions I didn't want (I think I remember an extension for a fast food chain?) - Icecat cut me off from the normal Firefox extension store. I can't remember if I was able to loan extensions I view as crucial for safely browsing the web. - The number of maintainers and the way in which it was (is?) being maintained did not inspire confidence. The people maintaining this are heros, but I'd rather rely on the boring engineering practices of upstream Firefox than heroic efforts. -- Katherine
Re: Packaging a free Firefox
Hello Katherine, Katherine Cox-Buday skribis: > E.g. I've seen several people in this thread mention they had already, > or were trying to, package Firefox (myself included). Had there been an > official non-libre channel, this work might not have been duplicated. There will never be an “official” non-libre channel in that Guix as a project will not provide such a channel. Now, Firefox *is* free software, so there’s could be an official “firefox” package, but in essence, it would have to incorporate pretty much the same changes that IceCat provides. I wonder why IceCat is based on an ESR, and what it would take to have it follow Firefox releases more closely. IWBN if IceCat could be pretty much like Linux-libre, i.e., a set of scripts that semi-automatically adjusts the Firefox source (I’m not sure if that is the case currently.) At any rate, people interested in this should probably team up with the IceCat people (person?) to see how we can together move in the right direction. Ludo’.
Re: Packaging a free Firefox
Hello Mike, Mike Gerwitz skribis: > IceCat is based on an old ESR; FF has undergone many substantial changes > (and rewrites of parts of the system) since then; it's much more > performant and I've found it to be much more stable over the years. > (I use IceCat at home and FF at work.) > > So when users compare IceCat to "Firefox", they're not likely > performing a valid comparison, since they're going to use a modern > version of Firefox. > > I think Rubén is working on an ESR upgrade, so maybe users' experiences > will be a bit better soon. Oh OK, thanks for explaining, I wasn’t aware of that. Ludo’.
Re: Packaging a free Firefox
On 17.05.2018 03:26, Mark H Weaver wrote: Can you tell me specifically what is wrong with GNU IceCat that makes it unsuitable for you? It has been my primary browser for several years. While that question wasn't addressed to me, my case was similar to what Katherine described, so here's my take on it: Coming from latest Firefox, IceCat on GuixSD felt ridiculously slow. Hidden-HTML warnings and the LibreJS thing were unbearably annoying. I understand the reasoning behind LibreJS, but to me, personally, it is akin to fighting in a lost war instead of getting to the information I want here and now. After disabling everything IceCat comes with, I found the replacement Add-on pages to be misdesigned for the context they appear in. I did not succeed in installing uMatrix, one of the few add-ons I care about. -- Thorsten Wilms thorwil's design for free software: http://thorwil.wordpress.com/
Re: Packaging a free Firefox
Hi Katherine, Katherine Cox-Buday writes: > Pjotr Prins writes: > >>> Not packaging FF or crippling FF is a no-go! Doing so will discourage >>> users from using GuixSD and Free Software. > > As an anecdote with a data-point of one, I uninstalled GuixSD because I > suddenly needed the machine I was running it on to be my daily driver. I > had been attempting to package Firefox whenever I had a spare moment, > but I ran out of time and needed it to work as I didn't have time to > migrate all the machines I use to a libre-friendly browser (nor am I > sure I want to). Can you tell me specifically what is wrong with GNU IceCat that makes it unsuitable for you? It has been my primary browser for several years. Thanks, Mark
Re: Packaging a free Firefox
Oleg Pykhalov writes: > I understand this, but still you could use almost all Guix stuff > except Shepherd system services [1] on a foreign distribution. Guix > works smoothly for me on a working computer with GNU/Linux Mint on a > board, and I use GuixSD on my personal computer and laptop. Also > GuixSD has the latest Chromium, but unfortunately without substitutes > yet [2]. Thanks Oleg. I am indeed running Guix the package manager on a few different distros. It's a good way for me to stay in touch with the project until I can run GuixSD again. -- Katherine
Re: Packaging a free Firefox
Hello Katherine, Katherine Cox-Buday writes: > Pjotr Prins writes: […] > As an anecdote with a data-point of one, I uninstalled GuixSD because I > suddenly needed the machine I was running it on to be my daily driver. I > had been attempting to package Firefox whenever I had a spare moment, > but I ran out of time and needed it to work as I didn't have time to > migrate all the machines I use to a libre-friendly browser (nor am I > sure I want to). I understand this, but still you could use almost all Guix stuff except Shepherd system services [1] on a foreign distribution. Guix works smoothly for me on a working computer with GNU/Linux Mint on a board, and I use GuixSD on my personal computer and laptop. Also GuixSD has the latest Chromium, but unfortunately without substitutes yet [2]. […] [1] https://www.gnu.org/software/shepherd/ [2] https://debbugs.gnu.org/cgi/bugreport.cgi?bug=28004 Oleg. signature.asc Description: PGP signature
Re: Packaging a free Firefox
Katherine Cox-Buday writes: > Pjotr Prins writes: > >>> Not packaging FF or crippling FF is a no-go! Doing so will discourage >>> users from using GuixSD and Free Software. > > As an anecdote with a data-point of one, I uninstalled GuixSD because I > suddenly needed the machine I was running it on to be my daily driver. I > had been attempting to package Firefox whenever I had a spare moment, > but I ran out of time and needed it to work as I didn't have time to > migrate all the machines I use to a libre-friendly browser (nor am I > sure I want to). I'm sorry to hear we lost you as a user, and hope eventually you can come back. I suspect that you aren't the only person whom we've lost due to this. I think that means that at least one of these three is a priority, IMO: - Getting Chromium in - Getting Firefox in (even if we remove the direct link to Mozilla's extensions page and have to rebrand to Aurora) - Getting a channels mechanism These days Guix has nearly everything I need, but this is a clear gap for many. Icecat helps a tremendous amount (and thank you thank you to Mark for all your work keeping things patched) but I do think we need to provide some other browser options. - Chris
Re: Packaging a free Firefox
Tonton writes: > I guess channels already sort of exist. have a git repo or similar with > whatever guix packages in it and point $GUIX_PACKAGE_PATH at it. Then all > packages defined in your git repo are suddenly part of your available guix > packages. I agree this is an option; however, I think there's an important distinction between the two. Having channels reifies the concept of different repositories and rallies groups of users around a single target. E.g. I've seen several people in this thread mention they had already, or were trying to, package Firefox (myself included). Had there been an official non-libre channel, this work might not have been duplicated. -- Katherine
Re: Packaging a free Firefox
Gábor Boskovits writes: > There was a bug in earlier Firefox, might that be that IceCat doesn't have > the fix for that yet? I don't know how much IceCat is delayed to Firefox. > https://stackoverflow.com/questions/24573061/uncaught-syntaxerror-in-strict-mode-code-functions-can-only-be-declared-at-top, > see the last comment. Someone wrote in that thread that updating to Firefox 52.4 solved the issue for them. If that's the case, the issue should be fixed in IceCat as well, because our IceCat package includes all relevant fixes from Firefox ESR up through 52.8. Mark
Re: Packaging a free Firefox
I guess channels already sort of exist. have a git repo or similar with whatever guix packages in it and point $GUIX_PACKAGE_PATH at it. Then all packages defined in your git repo are suddenly part of your available guix packages. On Wed, 16 May 2018 10:44:20 -0500 Katherine Cox-Buday wrote: > Pjotr Prins writes: > > >> Not packaging FF or crippling FF is a no-go! Doing so will discourage > >> users from using GuixSD and Free Software. > > As an anecdote with a data-point of one, I uninstalled GuixSD because I > suddenly needed the machine I was running it on to be my daily driver. I > had been attempting to package Firefox whenever I had a spare moment, > but I ran out of time and needed it to work as I didn't have time to > migrate all the machines I use to a libre-friendly browser (nor am I > sure I want to). > > > That is an interesting one. GNU Guix, by virtue of it being a GNU > > project needs to abide by GNU free software terms. But even among core > > project members there are variations in thought in how to compromise > > with user requirements. A package manager that does not target user > > needs is a shitty package manager. This is one reason I champion the > > concept of channels: > > > > guix channel firefox http://some-origin/guix-channels/firefox > > guix package -i firefox > > > > so we can make GNU Guix as pure as possible and leverage less pure > > concepts (such as Firefox and Conda) into something that is not > > considered part of the core project. I think it would also render > > other maintenance benefits, for example versioning of old software > > would become much easier. > > > > guix channel ruby-1.8 http://some-origin/guix-channels/ruby-1.8 > > guix package -i ruby > > > > I hope we get something like this at some point. > > So do I. I completely agree with the points made elsewhere in this > thread about joining idealism with pragmatism, and I think channels are > a good way to allow people who want/need to run less-than-libre software > to remain with and support Guix, without forcing the project to adopt > software contrary to its goals. > -- I use gpg to sign my emails. All the symbols you may see at the bottom of this mail is my cryptographic signature. It can be ignored, or used to check that it really is me sending this email. Learn more by asking me or see: https://u.fsf.org/zb or https://ssd.eff.org/ pgpNwbeAA3pSs.pgp Description: OpenPGP digital signature
Re: Packaging a free Firefox
Pjotr Prins writes: >> Not packaging FF or crippling FF is a no-go! Doing so will discourage >> users from using GuixSD and Free Software. As an anecdote with a data-point of one, I uninstalled GuixSD because I suddenly needed the machine I was running it on to be my daily driver. I had been attempting to package Firefox whenever I had a spare moment, but I ran out of time and needed it to work as I didn't have time to migrate all the machines I use to a libre-friendly browser (nor am I sure I want to). > That is an interesting one. GNU Guix, by virtue of it being a GNU > project needs to abide by GNU free software terms. But even among core > project members there are variations in thought in how to compromise > with user requirements. A package manager that does not target user > needs is a shitty package manager. This is one reason I champion the > concept of channels: > > guix channel firefox http://some-origin/guix-channels/firefox > guix package -i firefox > > so we can make GNU Guix as pure as possible and leverage less pure > concepts (such as Firefox and Conda) into something that is not > considered part of the core project. I think it would also render > other maintenance benefits, for example versioning of old software > would become much easier. > > guix channel ruby-1.8 http://some-origin/guix-channels/ruby-1.8 > guix package -i ruby > > I hope we get something like this at some point. So do I. I completely agree with the points made elsewhere in this thread about joining idealism with pragmatism, and I think channels are a good way to allow people who want/need to run less-than-libre software to remain with and support Guix, without forcing the project to adopt software contrary to its goals. -- Katherine
Re: Packaging a free Firefox
On Tue, May 15, 2018 at 10:57:39 +0200, Ludovic Courtès wrote: > Hi Pjotr, > > Pjotr Prins skribis: [...] >> I think I'll go to FF again if this persists. > > IceCat is essentially the same code as FireFox modulo branding, add-ons, > and a few trivial things. I don’t see how IceCat itself could be > blamed—the add-ons maybe, the way it is packaged in Guix perhaps, but > IceCat?… IceCat is based on an old ESR; FF has undergone many substantial changes (and rewrites of parts of the system) since then; it's much more performant and I've found it to be much more stable over the years. (I use IceCat at home and FF at work.) So when users compare IceCat to "Firefox", they're not likely performing a valid comparison, since they're going to use a modern version of Firefox. I think Rubén is working on an ESR upgrade, so maybe users' experiences will be a bit better soon. -- Mike Gerwitz Free Software Hacker+Activist | GNU Maintainer & Volunteer GPG: D6E9 B930 028A 6C38 F43B 2388 FEF6 3574 5E6F 6D05 https://mikegerwitz.com signature.asc Description: PGP signature
Re: Packaging a free Firefox
2018-05-15 10:57 GMT+02:00 Ludovic Courtès : > Hi Pjotr, > > Pjotr Prins skribis: > > > So I have been using Icecate for 10 days. It is frustrating because it > > does crash every other hour on some JS load. The error always looks like > > > > Extension error: SyntaxError: in strict mode code, functions may be > declared only at top level or immediately within another function > resource://gre/modules/ExtensionUtils.jsm -> > moz-extension://73353d04-3869-453b-8b9b-f71ceaae6e26/polyfill.js 63 > > [[Exception stack > > Current stack > > runSafeSyncWithoutClone@resource://gre/modules/ExtensionUtils.jsm:25:110 > > tryInject@resource://gre/modules/ExtensionContent.jsm:197:9 > > execute@resource://gre/modules/ExtensionContent.jsm:273:5 > > trigger@resource://gre/modules/ExtensionContent.jsm:463:11 > > DocumentManager.observe@resource://gre/modules/ > ExtensionContent.jsm:342:7 > > ]] > > > > I only have noscript and adblock plus installed and running. Any ideas? > > Did you check on the “about:home” page whether other things were > enabled? Also, is the JS error above fatal? JS is designed to keep > going in spite of errors (really!), so it could be that the thing above > doesn’t matter. > > FWIW, I’ve been using IceCat (actually mostly Conkeror, but it’s the > same thing) for a long time and I’ve rarely experienced crashes. I’m > surprised the experience is that bad for you. Is this on GuixSD? > > > I think I'll go to FF again if this persists. > > IceCat is essentially the same code as FireFox modulo branding, add-ons, > and a few trivial things. I don’t see how IceCat itself could be > blamed—the add-ons maybe, the way it is packaged in Guix perhaps, but > IceCat?… > > Ludo’. > > There was a bug in earlier Firefox, might that be that IceCat doesn't have the fix for that yet? I don't know how much IceCat is delayed to Firefox. https://stackoverflow.com/questions/24573061/uncaught-syntaxerror-in-strict-mode-code-functions-can-only-be-declared-at-top, see the last comment.
Re: Packaging a free Firefox
Hi Pjotr, Pjotr Prins skribis: > So I have been using Icecate for 10 days. It is frustrating because it > does crash every other hour on some JS load. The error always looks like > > Extension error: SyntaxError: in strict mode code, functions may be declared > only at top level or immediately within another function > resource://gre/modules/ExtensionUtils.jsm -> > moz-extension://73353d04-3869-453b-8b9b-f71ceaae6e26/polyfill.js 63 > [[Exception stack > Current stack > runSafeSyncWithoutClone@resource://gre/modules/ExtensionUtils.jsm:25:110 > tryInject@resource://gre/modules/ExtensionContent.jsm:197:9 > execute@resource://gre/modules/ExtensionContent.jsm:273:5 > trigger@resource://gre/modules/ExtensionContent.jsm:463:11 > DocumentManager.observe@resource://gre/modules/ExtensionContent.jsm:342:7 > ]] > > I only have noscript and adblock plus installed and running. Any ideas? Did you check on the “about:home” page whether other things were enabled? Also, is the JS error above fatal? JS is designed to keep going in spite of errors (really!), so it could be that the thing above doesn’t matter. FWIW, I’ve been using IceCat (actually mostly Conkeror, but it’s the same thing) for a long time and I’ve rarely experienced crashes. I’m surprised the experience is that bad for you. Is this on GuixSD? > I think I'll go to FF again if this persists. IceCat is essentially the same code as FireFox modulo branding, add-ons, and a few trivial things. I don’t see how IceCat itself could be blamed—the add-ons maybe, the way it is packaged in Guix perhaps, but IceCat?… Ludo’.
Re: Packaging a free Firefox
On Fri, May 04, 2018 at 04:24:11PM +0200, Pjotr Prins wrote: > On Thu, May 03, 2018 at 01:59:24PM -0400, Mike Gerwitz wrote: > > I use IceCat personally and FF Dev Edition at work. Until the recent > > move to WebExtensions, I used the same addons. I use NoScript and Tor > > and have no problems. But I rarely enable JS and never run proprietary > > JS, so my exposure may be different. I do not use LibreJS (because I > > don't usually run JS at all in general and it historically did not play > > well with NoScript; maybe that has changed). > > Disabling all extensions makes Icecat work much better. I'll try it as > a default now. > > Question: why do we switch on extensions by default? Sure confused my > experience. So I have been using Icecate for 10 days. It is frustrating because it does crash every other hour on some JS load. The error always looks like Extension error: SyntaxError: in strict mode code, functions may be declared only at top level or immediately within another function resource://gre/modules/ExtensionUtils.jsm -> moz-extension://73353d04-3869-453b-8b9b-f71ceaae6e26/polyfill.js 63 [[Exception stack Current stack runSafeSyncWithoutClone@resource://gre/modules/ExtensionUtils.jsm:25:110 tryInject@resource://gre/modules/ExtensionContent.jsm:197:9 execute@resource://gre/modules/ExtensionContent.jsm:273:5 trigger@resource://gre/modules/ExtensionContent.jsm:463:11 DocumentManager.observe@resource://gre/modules/ExtensionContent.jsm:342:7 ]] I only have noscript and adblock plus installed and running. Any ideas? I know I can file it as a bug, and we should if there is no idea. But I think I'll go to FF again if this persists. Pj.
Re: Packaging a free Firefox
Clément Lassieur writes: > You are right, there were tons of add-ons enabled, and disabling them > allowed me to do my credit card payment. I don't know why I never > thought about disabling them. (I wonder if it would be better to > disable them by default.) I think the answer is https://directory.fsf.org/wiki/IceCat#Philosophy.
Re: Packaging a free Firefox
On Thu, May 03, 2018 at 11:53:04AM +0200, Pjotr Prins wrote: > On Wed, May 02, 2018 at 11:06:32PM -0700, Chris Marusich wrote: > > Clément Lassieur writes: > > > > > I find Icecat very buggy, even if I compare it to a home-made Firefox > > > package that inherits Icecat (and thus is very close to Icecat). For > > > example I can't even pay with my credit card with icecat-52-guix, > > > whereas I can with firefox-home-52-guix. (It looks like a javascript > > > issue.) Also, lots of videos don't work, and it's difficult to know > > > whether it's because of technical issues or because of DRM. Using Noscript extension I find Icecat to be much more stable. Not sure what causes the crashes though, but now the experience is much like a somewhat older FF. It is probably worth pursuing Icecat and get those glitches fixed. Pj.
Re: Packaging a free Firefox
On Mon, May 07, 2018 at 06:30:44PM +0200, Ludovic Courtès wrote: > All, > > I don’t think the harsh words are warranted. Clément reported that some > of the add-ons that IceCat enables by default, which are there to > improve user privacy and autonomy, can cause web sites to behave badly. > Anyone can disable those add-ons, so I think we’re fine, aren’t we? I don't think the words were meant to be harsh. We are all in this together, right? Sorry if it came over that way. > Also, Guix follows the FSDG as part of its mission, which I think isn’t > news to anyone involved in the discussion, so it seems odd to question > that. I don't think that mission is questioned. No one expects Skype to be part of Guix ;) Pj.
Re: Packaging a free Firefox
Hartmut Goebel writes: > If you want to make the world a better place, you may decide to live > vegan. And if you expect everybody to become vegan, you will reach less > than if you try to convince people to start with eating less or no meat. This is not a good analogy to this situation, because we're not asking you to give up nonfree software. Instead, you are demanding that we include nonfree software in Guix. If you want to make an analogy to veganism here, here's a better one: What you're doing is analogous to walking into a vegan restaurant and demanding that they add meat to their menu, based on the argument that by excluding meat from their menu, they are infringing on your right to eat what you want. Mark
Re: Packaging a free Firefox
Hartmut Goebel writes: > Am 06.05.2018 um 16:05 schrieb Mike Gerwitz: >> In the case of their addon >> system, they encourage installation of non-free addons, which is against >> the Free Software Distribution Guidelines (FSDG), and is the same reason >> that Debian isn't a recommended free software distribution. >> > My aim is to empower people, not to infantilize them. > > If we disable adding add-on, we appoint ourselves as guardian for > immature users. And this IMHO is contrary to "free" (as in "free speech"). To be clear, our IceCat package allows you to install any compatible addon, regardless of its license. You are free to navigate to addons.mozilla.org and install whatever you wish. It's quite easy. However, IceCat is modified to not direct users to that site by default. That's part of our commitment as a project to not steer users toward nonfree software. I think it's rather absurd to suggest that we are somehow violating your freedom by making a commitment as a project to exclude software that doesn't meet our standards. You can do what you want with your own computer. Guix makes it unusually easy to add your own packages, or modify our existing packages, while still receiving updates from us. Can you explain more clearly how we are infringing on your freedom? Mark
Re: Packaging a free Firefox
All, I don’t think the harsh words are warranted. Clément reported that some of the add-ons that IceCat enables by default, which are there to improve user privacy and autonomy, can cause web sites to behave badly. Anyone can disable those add-ons, so I think we’re fine, aren’t we? Also, Guix follows the FSDG as part of its mission, which I think isn’t news to anyone involved in the discussion, so it seems odd to question that. Thanks, Ludo’.
Re: Packaging a free Firefox
On 07/05/18 01:36, Mike Gerwitz wrote: > On Sun, May 06, 2018 at 18:33:56 +0200, Hartmut Goebel wrote: > IceCat replaces > it with its own page that uses the free software directory, for example. > Users are free to use that directory; go to addons.mozilla.org > themselves; or install addons however else they choose. Trisquel maintain a directory of addons too:- https://trisquel.info/browser-plain Each item in the list has a link to a page which displays, among other info, the name of the license and a link to the source code.
Re: Packaging a free Firefox
On Sun, May 06, 2018 at 18:33:56 +0200, Hartmut Goebel wrote: > Am 06.05.2018 um 16:05 schrieb Mike Gerwitz: >> In the case of their addon >> system, they encourage installation of non-free addons, which is against >> the Free Software Distribution Guidelines (FSDG), and is the same reason >> that Debian isn't a recommended free software distribution. >> > My aim is to empower people, not to infantilize them. > > If we disable adding add-on, we appoint ourselves as guardian for > immature users. And this IMHO is contrary to "free" (as in "free speech"). There might be a miscommunication: I'm not suggesting that we disable addons (I use many of them), merely that we do not have the default Firefox addon page, which encourages non-free software. IceCat replaces it with its own page that uses the free software directory, for example. Users are free to use that directory; go to addons.mozilla.org themselves; or install addons however else they choose. -- Mike Gerwitz Free Software Hacker+Activist | GNU Maintainer & Volunteer GPG: D6E9 B930 028A 6C38 F43B 2388 FEF6 3574 5E6F 6D05 https://mikegerwitz.com signature.asc Description: PGP signature
Re: Packaging a free Firefox
Am 06.05.2018 um 15:58 schrieb Mike Gerwitz: > I suspect that most Guix users are more technical than average users and > would be much less bothered by a kluge for the time being. I would be bothered by such a kludge, which IMHO is of no use. -- Regards Hartmut Goebel | Hartmut Goebel | h.goe...@crazy-compilers.com | | www.crazy-compilers.com | compilers which you thought are impossible |
Re: Packaging a free Firefox
Am 06.05.2018 um 16:05 schrieb Mike Gerwitz: > In the case of their addon > system, they encourage installation of non-free addons, which is against > the Free Software Distribution Guidelines (FSDG), and is the same reason > that Debian isn't a recommended free software distribution. > My aim is to empower people, not to infantilize them. If we disable adding add-on, we appoint ourselves as guardian for immature users. And this IMHO is contrary to "free" (as in "free speech"). We might add some warning on the add-on page like: Some of the add-ons listed here are no [Free Software](link). Please check the license prior to installing. (More information »»](link) This would make people aware of the problem but still give them the freedom to decide. This is what F-droid does. -- Regards Hartmut Goebel | Hartmut Goebel | h.goe...@crazy-compilers.com | | www.crazy-compilers.com | compilers which you thought are impossible | signature.asc Description: OpenPGP digital signature
Re: Packaging a free Firefox
On Sun, May 06, 2018 at 10:05:35AM -0400, Mike Gerwitz wrote: > Packaging Firefox as-is is not an option. In the case of their addon > system, they encourage installation of non-free addons, which is against > the Free Software Distribution Guidelines (FSDG), and is the same reason > that Debian isn't a recommended free software distribution. Which is ridiculous. The Debian project goes to great lengths providing free software and is an absolute boon to free software in general. That they allow users to help package other things is pragmatic and only grows the community in the end (I agree with Hartmut). Without distributions like Debian Linux would have been much smaller. Maybe we should appreciate that and help that form our own strategy. Last thing I say about it. I appreciate absolute thinking - it is important to be critical. But we also need to be pragmatic. Pj.
Re: Packaging a free Firefox
On Sun, May 06, 2018 at 11:48:28 +0200, Hartmut Goebel wrote: > Am 06.05.2018 um 03:24 schrieb Mike Gerwitz: >> On Sat, May 05, 2018 at 19:06:27 -0300, Adonay Felipe Nogueira wrote: >>> I have noticed somepeople advocating for packaging Firefox in GNU Guix, >>> and since FF still has freedom issues, I see it as a no-go. >> A simple option for now is to package FF by disabling those features and >> _not_ providing an alternative. For example, IceCat loads a different >> addon page than FF; we could just load no addon page at all, or a static >> one saying that it's something'll we'll get to eventually. > > Not packaging FF or crippling FF is a no-go! Doing so will discourage > users from using GuixSD and Free Software. Packaging Firefox as-is is not an option. In the case of their addon system, they encourage installation of non-free addons, which is against the Free Software Distribution Guidelines (FSDG), and is the same reason that Debian isn't a recommended free software distribution. https://www.gnu.org/distros/free-system-distribution-guidelines.html -- Mike Gerwitz Free Software Hacker+Activist | GNU Maintainer & Volunteer GPG: D6E9 B930 028A 6C38 F43B 2388 FEF6 3574 5E6F 6D05 https://mikegerwitz.com signature.asc Description: PGP signature
Re: Packaging a free Firefox
On Sun, May 06, 2018 at 06:01:59 +, Nils Gillmann wrote: > Mike Gerwitz transcribed 2.2K bytes: >> On Sat, May 05, 2018 at 19:06:27 -0300, Adonay Felipe Nogueira wrote: >> > I have noticed somepeople advocating for packaging Firefox in GNU Guix, >> > and since FF still has freedom issues, I see it as a no-go. >> >> A simple option for now is to package FF by disabling those features and >> _not_ providing an alternative. For example, IceCat loads a different >> addon page than FF; we could just load no addon page at all, or a static >> one saying that it's something'll we'll get to eventually. > > For the majority of people it will be "weird" to load add-ons not via > the Mozlla Store, but if explained before usage it can work out. Users are free to still use addons.mozilla.org, of course. I do, because I know to check the license of the addon before installing, and the website does not require JS for the functions that I need. I suspect that most Guix users are more technical than average users and would be much less bothered by a kluge for the time being. But to prevent bug reports, something should certainly indicate that it's not failing to load because of a bug. > I thin with regards to Addons of Mozilla based software, we just have > to reimplement what Nix does for the Addons. I'm not familiar with what Nix does; is it similar to what Guix does with e.g. Emacs packages? I would like that. >> I have no suggestions for dealing with the trademark issue, though. > > The branding "aurora" (building without branding) is trademark free. > What remains are mentions of "Firefo" in some places. Oh, excellent. -- Mike Gerwitz Free Software Hacker+Activist | GNU Maintainer & Volunteer GPG: D6E9 B930 028A 6C38 F43B 2388 FEF6 3574 5E6F 6D05 https://mikegerwitz.com signature.asc Description: PGP signature
Re: Packaging a free Firefox
On Sun, May 06, 2018 at 11:48:28AM +0200, Hartmut Goebel wrote: > Am 06.05.2018 um 03:24 schrieb Mike Gerwitz: > > On Sat, May 05, 2018 at 19:06:27 -0300, Adonay Felipe Nogueira wrote: > >> I have noticed somepeople advocating for packaging Firefox in GNU Guix, > >> and since FF still has freedom issues, I see it as a no-go. > > A simple option for now is to package FF by disabling those features and > > _not_ providing an alternative. For example, IceCat loads a different > > addon page than FF; we could just load no addon page at all, or a static > > one saying that it's something'll we'll get to eventually. > > Not packaging FF or crippling FF is a no-go! Doing so will discourage > users from using GuixSD and Free Software. That is an interesting one. GNU Guix, by virtue of it being a GNU project needs to abide by GNU free software terms. But even among core project members there are variations in thought in how to compromise with user requirements. A package manager that does not target user needs is a shitty package manager. This is one reason I champion the concept of channels: guix channel firefox http://some-origin/guix-channels/firefox guix package -i firefox so we can make GNU Guix as pure as possible and leverage less pure concepts (such as Firefox and Conda) into something that is not considered part of the core project. I think it would also render other maintenance benefits, for example versioning of old software would become much easier. guix channel ruby-1.8 http://some-origin/guix-channels/ruby-1.8 guix package -i ruby I hope we get something like this at some point. Pj.
Re: Packaging a free Firefox
Am 06.05.2018 um 03:24 schrieb Mike Gerwitz: > On Sat, May 05, 2018 at 19:06:27 -0300, Adonay Felipe Nogueira wrote: >> I have noticed somepeople advocating for packaging Firefox in GNU Guix, >> and since FF still has freedom issues, I see it as a no-go. > A simple option for now is to package FF by disabling those features and > _not_ providing an alternative. For example, IceCat loads a different > addon page than FF; we could just load no addon page at all, or a static > one saying that it's something'll we'll get to eventually. Not packaging FF or crippling FF is a no-go! Doing so will discourage users from using GuixSD and Free Software. You will defeat your supporters, those who want to go the free-software-route. But you will not change the world, since your supporters have to carry the can, and the vendors, who are causing the problems, will be untouched. This is the same as not providing proprietary firmware in libre-linux. If you want to make the world a better place, you may decide to live vegan. And if you expect everybody to become vegan, you will reach less than if you try to convince people to start with eating less or no meat. Having strong opinions and working towards them is the one side. Convincing people is the other side. Followup-to: alt.religion.free-software, -- Regards Hartmut Goebel | Hartmut Goebel | h.goe...@crazy-compilers.com | | www.crazy-compilers.com | compilers which you thought are impossible |
Re: Packaging a free Firefox
Mike Gerwitz transcribed 2.2K bytes: > On Sat, May 05, 2018 at 19:06:27 -0300, Adonay Felipe Nogueira wrote: > > I have noticed somepeople advocating for packaging Firefox in GNU Guix, > > and since FF still has freedom issues, I see it as a no-go. > > A simple option for now is to package FF by disabling those features and > _not_ providing an alternative. For example, IceCat loads a different > addon page than FF; we could just load no addon page at all, or a static > one saying that it's something'll we'll get to eventually. For the majority of people it will be "weird" to load add-ons not via the Mozlla Store, but if explained before usage it can work out. I thin with regards to Addons of Mozilla based software, we just have to reimplement what Nix does for the Addons. > I have no suggestions for dealing with the trademark issue, though. The branding "aurora" (building without branding) is trademark free. What remains are mentions of "Firefo" in some places. > > What if, instead of making Guix's own "IceCat based on latest > > Firefox", we do get in touch with IceCat project instead so that they > > get convinced to use "latest Firefox" (and perhaps help them?) instead > > of ESR? > > We (GNU) are looking for co-maintainers for IceCat. If anyone expresses > interest with your suggestion, please have them contact > maintain...@gnu.org. > > > Another option is to package Trisquel's Abrowser. > > Isn't Abrowser more up-to-date than IceCat is? It's maintained by the > same person (Rubén), but I haven't used Trisquel on a desktop in quite > some time. > > -- > Mike Gerwitz > Free Software Hacker+Activist | GNU Maintainer & Volunteer > GPG: D6E9 B930 028A 6C38 F43B 2388 FEF6 3574 5E6F 6D05 > https://mikegerwitz.com
Re: Packaging a free Firefox
On Sat, May 05, 2018 at 19:06:27 -0300, Adonay Felipe Nogueira wrote: > I have noticed somepeople advocating for packaging Firefox in GNU Guix, > and since FF still has freedom issues, I see it as a no-go. A simple option for now is to package FF by disabling those features and _not_ providing an alternative. For example, IceCat loads a different addon page than FF; we could just load no addon page at all, or a static one saying that it's something'll we'll get to eventually. I have no suggestions for dealing with the trademark issue, though. > What if, instead of making Guix's own "IceCat based on latest > Firefox", we do get in touch with IceCat project instead so that they > get convinced to use "latest Firefox" (and perhaps help them?) instead > of ESR? We (GNU) are looking for co-maintainers for IceCat. If anyone expresses interest with your suggestion, please have them contact maintain...@gnu.org. > Another option is to package Trisquel's Abrowser. Isn't Abrowser more up-to-date than IceCat is? It's maintained by the same person (Rubén), but I haven't used Trisquel on a desktop in quite some time. -- Mike Gerwitz Free Software Hacker+Activist | GNU Maintainer & Volunteer GPG: D6E9 B930 028A 6C38 F43B 2388 FEF6 3574 5E6F 6D05 https://mikegerwitz.com signature.asc Description: PGP signature
Re: Packaging a free Firefox
2018-05-02T23:06:37+0200 Clément Lassieur wrote: > Hi, Hi Clément, > I find Icecat very buggy, even if I compare it to a home-made Firefox > package that inherits Icecat (and thus is very close to Icecat). For > example I can't even pay with my credit card with icecat-52-guix, > whereas I can with firefox-home-52-guix. (It looks like a javascript > issue.) Also, lots of videos don't work, and it's difficult to know > whether it's because of technical issues or because of DRM. I have noticed somepeople advocating for packaging Firefox in GNU Guix, and since FF still has freedom issues, I see it as a no-go. What if, instead of making Guix's own "IceCat based on latest Firefox", we do get in touch with IceCat project instead so that they get convinced to use "latest Firefox" (and perhaps help them?) instead of ESR? Another option is to package Trisquel's Abrowser. As for the JavaScript issue, it really is a matter of reaching out to the *website owners*, or changing the service provider. Really, serious business people that value end-user privacy, security and accessibility shouldn't be requiring the clients to run client-side forced autoexecutable code, specially now that we found out about Meltdown and Spectre unfixable vulnerabilities. > 5. it prevents the installation of non-free plugins, Could you please report this bug to GNUzilla project (the one responsible for IceCat)? If by "prevents" you mean "forbids" then this is definetively a bug, not a feature. Free/libre software shouldn't forbid doing that, it insltead mustn't *recommend* doing it, and must not mention these non-free functional data. -- - Formas de contato: https://libreplanet.org/wiki/User:Adfeno#vCard - Ativista do /software/ livre (não confundir com gratuito). Avaliador da liberdade de /software/ e de /sites/. - Arquivos que aceito: https://libreplanet.org/wiki/User:Adfeno#Arquivos - Contribuições à sociedade: https://libreplanet.org/wiki/User:Adfeno#Contributions - Gosta do meu trabalho? Contrate-me ou doe algo para mim! https://libreplanet.org/wiki/User:Adfeno#Suporte - Use comunicações sociais federadas padronizadas, onde o "social" permanece independente do fornecedor. #DeleteWhatsApp. Use #XMPP (https://libreplanet.org/wiki/XMPP.pt), #DeleteFacebook #DeleteInstagram #DeleteTwitter #DeleteYouTube. Use #ActivityPub via #Mastodon (https://joinmastodon.org/). - #DeleteNetflix #CancelNetflix. Evite #DRM: https://www.defectivebydesign.org/
Re: Packaging a free Firefox
On Fri, May 04, 2018 at 12:27:07PM -0400, Mike Gerwitz wrote: > As far as the extensions that come _with_ IceCat, I just don't have use > for them or use something else in place of them. That appears reasonable. Maybe we can provide flavours of Icecat in addition to the default. Pj.
Re: Packaging a free Firefox
On Fri, May 04, 2018 at 16:24:11 +0200, Pjotr Prins wrote: > On Thu, May 03, 2018 at 01:59:24PM -0400, Mike Gerwitz wrote: >> I use IceCat personally and FF Dev Edition at work. Until the recent >> move to WebExtensions, I used the same addons. I use NoScript and Tor >> and have no problems. But I rarely enable JS and never run proprietary >> JS, so my exposure may be different. I do not use LibreJS (because I >> don't usually run JS at all in general and it historically did not play >> well with NoScript; maybe that has changed). > > Disabling all extensions makes Icecat work much better. I'll try it as > a default now. I don't think I made clear with the above: I use many different addons (NoScript, Privacy Badger, HTTPS Everywhere, uBlock Origin, Self-Destructing Cookies, Foxyproxy, Tree Style Tab, and some misc ones); I didn't want to give the impression that extensions are a problem for me. As far as the extensions that come _with_ IceCat, I just don't have use for them or use something else in place of them. -- Mike Gerwitz Free Software Hacker+Activist | GNU Maintainer & Volunteer GPG: D6E9 B930 028A 6C38 F43B 2388 FEF6 3574 5E6F 6D05 https://mikegerwitz.com signature.asc Description: PGP signature
Re: Packaging a free Firefox
Pjotr Prins transcribed 650 bytes: > On Thu, May 03, 2018 at 01:59:24PM -0400, Mike Gerwitz wrote: > > I use IceCat personally and FF Dev Edition at work. Until the recent > > move to WebExtensions, I used the same addons. I use NoScript and Tor > > and have no problems. But I rarely enable JS and never run proprietary > > JS, so my exposure may be different. I do not use LibreJS (because I > > don't usually run JS at all in general and it historically did not play > > well with NoScript; maybe that has changed). > > Disabling all extensions makes Icecat work much better. I'll try it as > a default now. > > Question: why do we switch on extensions by default? Sure confused my > experience. > > Pj. I think it's because this is upstreams decision and we usually stick with what upstream does. Although you could almost call our Icecat a variant of Icecat due to more work going into tracking Mozilla and applying patches done by Mark.
Re: Packaging a free Firefox
On Thu, May 03, 2018 at 01:59:24PM -0400, Mike Gerwitz wrote: > I use IceCat personally and FF Dev Edition at work. Until the recent > move to WebExtensions, I used the same addons. I use NoScript and Tor > and have no problems. But I rarely enable JS and never run proprietary > JS, so my exposure may be different. I do not use LibreJS (because I > don't usually run JS at all in general and it historically did not play > well with NoScript; maybe that has changed). Disabling all extensions makes Icecat work much better. I'll try it as a default now. Question: why do we switch on extensions by default? Sure confused my experience. Pj.
Re: Packaging a free Firefox
Hi Chris, Chris Marusich writes: > Clément Lassieur writes: > >> I find Icecat very buggy, even if I compare it to a home-made Firefox >> package that inherits Icecat (and thus is very close to Icecat). For >> example I can't even pay with my credit card with icecat-52-guix, >> whereas I can with firefox-home-52-guix. (It looks like a javascript >> issue.) Also, lots of videos don't work, and it's difficult to know >> whether it's because of technical issues or because of DRM. > > This has not been my experience with IceCat. With two exceptions, > IceCat has performed just as well as Firefox for me for everything I > have done, including credit card payments. I sometimes watch YouTube > videos using IceCat, but I don't view many other videos, so I can't > really comment on how well IceCat handles videos. If it requires DRM, > of course, it's not going to work in IceCat, which is a good thing. > > When I use IceCat over TOR, it doesn't always work. When I use IceCat > with extensions (plugins? add-ons? I'm not sure what the right > terminology is here) like NoScript enabled, it doesn't always work. But > when I don't use TOR and I disable those add-ons, everything works just > as well as stock Firefox. If you're still having trouble after > disabling those things, can you describe the specifics of what you're > having trouble with? You are right, there were tons of add-ons enabled, and disabling them allowed me to do my credit card payment. I don't know why I never thought about disabling them. (I wonder if it would be better to disable them by default.) So... I apologize for being unfair with Icecat :-) most of what I said is wrong. The version issue remains though: having a Firefox 58 (not 52) would be great, but maybe it's not worth doing the package, I don't know. Thank you all for replying, and thanks to the Icecat mainteners for their work ;-) Clément
Re: Packaging a free Firefox
Chris Marusich writes: > 2) It used to be that IceCat would crash frequently for me. However, > once I changed my gfx.canvas.azure.backends and > gfx.content.azure.backends from "cairo" to "skia", this problem stopped > for me. I don't know if this is still an issue , since I haven't ever > switched it back to "cairo". See here for details: > > https://lists.gnu.org/archive/html/help-guix/2016-11/msg8.html FYI, I switched back to the "cairo" backend a couple of months ago, and I haven't experienced any crashes, so I disabled this workaround on our 'core-updates' branch. https://git.savannah.gnu.org/cgit/guix.git/commit/?h=core-updates&id=1293f6d8a4dfad23ec693a1f2785cdb8d09b36f6 Mark
Re: Packaging a free Firefox
On Wed, May 02, 2018 at 23:06:32 -0700, Chris Marusich wrote: > Clément Lassieur writes: > >> I find Icecat very buggy, even if I compare it to a home-made Firefox >> package that inherits Icecat (and thus is very close to Icecat). For >> example I can't even pay with my credit card with icecat-52-guix, >> whereas I can with firefox-home-52-guix. (It looks like a javascript >> issue.) Also, lots of videos don't work, and it's difficult to know >> whether it's because of technical issues or because of DRM. > > This has not been my experience with IceCat. With two exceptions, > IceCat has performed just as well as Firefox for me for everything I > have done, including credit card payments. I sometimes watch YouTube > videos using IceCat, but I don't view many other videos, so I can't > really comment on how well IceCat handles videos. If it requires DRM, > of course, it's not going to work in IceCat, which is a good thing. > > When I use IceCat over TOR, it doesn't always work. When I use IceCat > with extensions (plugins? add-ons? I'm not sure what the right > terminology is here) like NoScript enabled, it doesn't always work. But > when I don't use TOR and I disable those add-ons, everything works just > as well as stock Firefox. If you're still having trouble after > disabling those things, can you describe the specifics of what you're > having trouble with? I use IceCat personally and FF Dev Edition at work. Until the recent move to WebExtensions, I used the same addons. I use NoScript and Tor and have no problems. But I rarely enable JS and never run proprietary JS, so my exposure may be different. I do not use LibreJS (because I don't usually run JS at all in general and it historically did not play well with NoScript; maybe that has changed). > The exceptions I have experienced with IceCat: > > 1) A website failed for me because IceCat enables Referer spoofing by > default (network.http.referer.spoofSource in about:config). I had to > disable that feature to use that website. This was a frustrating problem for me for CloudFlare CAPTCHAs---it would enter an infinte direct loop. Disabling referer spoofing fixed the issue. > 2) It used to be that IceCat would crash frequently for me. However, > once I changed my gfx.canvas.azure.backends and > gfx.content.azure.backends from "cairo" to "skia", this problem stopped > for me. I don't know if this is still an issue , since I haven't ever > switched it back to "cairo". See here for details: > > https://lists.gnu.org/archive/html/help-guix/2016-11/msg8.html It will crash for me if I try e.g. Jitsi Meet; I'll have to see if anything you are describing helps. Anyway: I too would like a modern version of FF packaged for Guix. I know that David Thompson was exploring it at some point but got hung up on some Rust packaging issues that he didn't have the time to explore. I want the modern performance benefits, and I also use the browser for web development. IceCat maintenance also effectively falls on Mark Weaver backporting security patches in Guix; Rubén Rodriguez (IceCat) maintainer has a lot on his plate and IceCat does not get a lot of attention. (If anyone wants to help with IceCat maintenance, he would like the help; contact us at maintain...@gnu.org.) -- Mike Gerwitz Free Software Hacker+Activist | GNU Maintainer & Volunteer GPG: D6E9 B930 028A 6C38 F43B 2388 FEF6 3574 5E6F 6D05 https://mikegerwitz.com signature.asc Description: PGP signature
Re: Packaging a free Firefox
Hi, I agree with Pjotr and Clément, I do use mainly two programs on GuixSD, Firefox and Emacs. Packaging a custom Firefox was like the first thing I did when starting Guix. Even if we put a lot of efforts in Icecat, it it still lagging behind Firefox. Thus, having an upstream stripped Firefox seems like a good idea to me. Mathieu Pjotr Prins writes: > On Wed, May 02, 2018 at 11:06:32PM -0700, Chris Marusich wrote: >> Clément Lassieur writes: >> >> > I find Icecat very buggy, even if I compare it to a home-made Firefox >> > package that inherits Icecat (and thus is very close to Icecat). For >> > example I can't even pay with my credit card with icecat-52-guix, >> > whereas I can with firefox-home-52-guix. (It looks like a javascript >> > issue.) Also, lots of videos don't work, and it's difficult to know >> > whether it's because of technical issues or because of DRM. >> >> This has not been my experience with IceCat. With two exceptions, >> IceCat has performed just as well as Firefox for me for everything I >> have done, including credit card payments. I sometimes watch YouTube >> videos using IceCat, but I don't view many other videos, so I can't >> really comment on how well IceCat handles videos. If it requires DRM, >> of course, it's not going to work in IceCat, which is a good thing. >> >> When I use IceCat over TOR, it doesn't always work. When I use IceCat >> with extensions (plugins? add-ons? I'm not sure what the right >> terminology is here) like NoScript enabled, it doesn't always work. But >> when I don't use TOR and I disable those add-ons, everything works just >> as well as stock Firefox. If you're still having trouble after >> disabling those things, can you describe the specifics of what you're >> having trouble with? >> >> The exceptions I have experienced with IceCat: >> >> 1) A website failed for me because IceCat enables Referer spoofing by >> default (network.http.referer.spoofSource in about:config). I had to >> disable that feature to use that website. >> >> 2) It used to be that IceCat would crash frequently for me. However, >> once I changed my gfx.canvas.azure.backends and >> gfx.content.azure.backends from "cairo" to "skia", this problem stopped >> for me. I don't know if this is still an issue , since I haven't ever >> switched it back to "cairo". See here for details: >> >> https://lists.gnu.org/archive/html/help-guix/2016-11/msg8.html > > In my experience Icecat usually works. But sometimes it does not and > it is usually a JavaScript thing. It would be nice to have firefox > too. I agree with Clément that it is an important option for users and > it is still a dominant browser. Currently we only can install it as > binary blobs. Which are often broken in my setup. > > Pj.
Re: Packaging a free Firefox
On Wed, May 02, 2018 at 11:06:32PM -0700, Chris Marusich wrote: > Clément Lassieur writes: > > > I find Icecat very buggy, even if I compare it to a home-made Firefox > > package that inherits Icecat (and thus is very close to Icecat). For > > example I can't even pay with my credit card with icecat-52-guix, > > whereas I can with firefox-home-52-guix. (It looks like a javascript > > issue.) Also, lots of videos don't work, and it's difficult to know > > whether it's because of technical issues or because of DRM. > > This has not been my experience with IceCat. With two exceptions, > IceCat has performed just as well as Firefox for me for everything I > have done, including credit card payments. I sometimes watch YouTube > videos using IceCat, but I don't view many other videos, so I can't > really comment on how well IceCat handles videos. If it requires DRM, > of course, it's not going to work in IceCat, which is a good thing. > > When I use IceCat over TOR, it doesn't always work. When I use IceCat > with extensions (plugins? add-ons? I'm not sure what the right > terminology is here) like NoScript enabled, it doesn't always work. But > when I don't use TOR and I disable those add-ons, everything works just > as well as stock Firefox. If you're still having trouble after > disabling those things, can you describe the specifics of what you're > having trouble with? > > The exceptions I have experienced with IceCat: > > 1) A website failed for me because IceCat enables Referer spoofing by > default (network.http.referer.spoofSource in about:config). I had to > disable that feature to use that website. > > 2) It used to be that IceCat would crash frequently for me. However, > once I changed my gfx.canvas.azure.backends and > gfx.content.azure.backends from "cairo" to "skia", this problem stopped > for me. I don't know if this is still an issue , since I haven't ever > switched it back to "cairo". See here for details: > > https://lists.gnu.org/archive/html/help-guix/2016-11/msg8.html In my experience Icecat usually works. But sometimes it does not and it is usually a JavaScript thing. It would be nice to have firefox too. I agree with Clément that it is an important option for users and it is still a dominant browser. Currently we only can install it as binary blobs. Which are often broken in my setup. Pj.
Re: Packaging a free Firefox
Clément Lassieur writes: > I find Icecat very buggy, even if I compare it to a home-made Firefox > package that inherits Icecat (and thus is very close to Icecat). For > example I can't even pay with my credit card with icecat-52-guix, > whereas I can with firefox-home-52-guix. (It looks like a javascript > issue.) Also, lots of videos don't work, and it's difficult to know > whether it's because of technical issues or because of DRM. This has not been my experience with IceCat. With two exceptions, IceCat has performed just as well as Firefox for me for everything I have done, including credit card payments. I sometimes watch YouTube videos using IceCat, but I don't view many other videos, so I can't really comment on how well IceCat handles videos. If it requires DRM, of course, it's not going to work in IceCat, which is a good thing. When I use IceCat over TOR, it doesn't always work. When I use IceCat with extensions (plugins? add-ons? I'm not sure what the right terminology is here) like NoScript enabled, it doesn't always work. But when I don't use TOR and I disable those add-ons, everything works just as well as stock Firefox. If you're still having trouble after disabling those things, can you describe the specifics of what you're having trouble with? The exceptions I have experienced with IceCat: 1) A website failed for me because IceCat enables Referer spoofing by default (network.http.referer.spoofSource in about:config). I had to disable that feature to use that website. 2) It used to be that IceCat would crash frequently for me. However, once I changed my gfx.canvas.azure.backends and gfx.content.azure.backends from "cairo" to "skia", this problem stopped for me. I don't know if this is still an issue , since I haven't ever switched it back to "cairo". See here for details: https://lists.gnu.org/archive/html/help-guix/2016-11/msg8.html -- Chris signature.asc Description: PGP signature
Re: Packaging a free Firefox
While not directly related to Firefox, Next Browser is also a full-featured, highly-compatible webbrowser. I'll package it for Guix very soon: https://github.com/next-browser/next/issues/92 http://next-browser.com/ -- Pierre Neidhardt signature.asc Description: PGP signature
Re: Packaging a free Firefox
Nils Gillmann transcribed 2.4K bytes: > Clément Lassieur transcribed 1.5K bytes: > > > > Clément Lassieur writes: > > > > > Hi, > > > > > > I find Icecat very buggy, even if I compare it to a home-made Firefox > > > package that inherits Icecat (and thus is very close to Icecat). For > > > example I can't even pay with my credit card with icecat-52-guix, > > > whereas I can with firefox-home-52-guix. (It looks like a javascript > > > issue.) Also, lots of videos don't work, and it's difficult to know > > > whether it's because of technical issues or because of DRM. > > > > > > This may discourage people from using GuixSD. > > > > > > My understanding is that Icecat exists because of two reasons: > > > 1. a trademark/logo issue, > > > 2. the need to remove non-free code from Firefox. > > > > > > But it does more: > > > 3. it only packages the stables versions of Firefox, > > > 4. it adds add-ons, > > > 5. it prevents the installation of non-free plugins, > > > 6. probably other things that I'm not aware of. > > > > > > It seems to me that the trademark/logo issue and the non-free code > > > removal could be dealt with at the Guix packaging level. It's probably > > > just a huge bunch of substitutes to do. The package would be huge, but > > > at least we would have control on it. > > > > > > That would remove a layer of complexity, and probably reduce bugs (that > > > come from that layer). That would also allow us to have a recent > > > version of Firefox. > > > > > > And it would be way better than everyone (I exaggerate a bit) having his > > their ^ > > > home-made non-maintened full-of-security-issues Firefox. > > > > > > What do you think? > > > Clément > > > > > Among other things I've been working on Firefox. Not exactly with the > intention > of a free one per se, but at least to have it. I've been updating Aurora > Nightly > for a while. > Thing is, it get's tricky after 54.0 due to mandatory Rust. I wanted to give > the > Rust problem another try soon, if you are serious about this, I can try and > summarize > it or provide snippets. You'l be able to find the package definitions, but > they do > not apply to Guix package structure (also I need to relicense it. whatever > you'll > find AGPL3 licensed is in fact GPL3 licensed now. I am just too busy to fix > the > headers, will do it on the weekend).. if I have commited the recent changes > to the > wip version. > I seem to remember that the gnuzilla mailinglist did drop some hints about > the core > issue I had with rust. > Addition: I think constructing and maintaing a free, unbranded version of Firefox (Aurora) or even a branded one with a Guix theme is possible. What icecat does is not that complex but it requires at least more than 1 person checking the sources continuously. Furthermore we'd need a common ground of goals what changes would be applied and what changes are a no-go.
Re: Packaging a free Firefox
Clément Lassieur transcribed 1.5K bytes: > > Clément Lassieur writes: > > > Hi, > > > > I find Icecat very buggy, even if I compare it to a home-made Firefox > > package that inherits Icecat (and thus is very close to Icecat). For > > example I can't even pay with my credit card with icecat-52-guix, > > whereas I can with firefox-home-52-guix. (It looks like a javascript > > issue.) Also, lots of videos don't work, and it's difficult to know > > whether it's because of technical issues or because of DRM. > > > > This may discourage people from using GuixSD. > > > > My understanding is that Icecat exists because of two reasons: > > 1. a trademark/logo issue, > > 2. the need to remove non-free code from Firefox. > > > > But it does more: > > 3. it only packages the stables versions of Firefox, > > 4. it adds add-ons, > > 5. it prevents the installation of non-free plugins, > > 6. probably other things that I'm not aware of. > > > > It seems to me that the trademark/logo issue and the non-free code > > removal could be dealt with at the Guix packaging level. It's probably > > just a huge bunch of substitutes to do. The package would be huge, but > > at least we would have control on it. > > > > That would remove a layer of complexity, and probably reduce bugs (that > > come from that layer). That would also allow us to have a recent > > version of Firefox. > > > > And it would be way better than everyone (I exaggerate a bit) having his > their ^ > > home-made non-maintened full-of-security-issues Firefox. > > > > What do you think? > > Clément > > Among other things I've been working on Firefox. Not exactly with the intention of a free one per se, but at least to have it. I've been updating Aurora Nightly for a while. Thing is, it get's tricky after 54.0 due to mandatory Rust. I wanted to give the Rust problem another try soon, if you are serious about this, I can try and summarize it or provide snippets. You'l be able to find the package definitions, but they do not apply to Guix package structure (also I need to relicense it. whatever you'll find AGPL3 licensed is in fact GPL3 licensed now. I am just too busy to fix the headers, will do it on the weekend).. if I have commited the recent changes to the wip version. I seem to remember that the gnuzilla mailinglist did drop some hints about the core issue I had with rust.
Re: Packaging a free Firefox
Clément Lassieur writes: > Hi, > > I find Icecat very buggy, even if I compare it to a home-made Firefox > package that inherits Icecat (and thus is very close to Icecat). For > example I can't even pay with my credit card with icecat-52-guix, > whereas I can with firefox-home-52-guix. (It looks like a javascript > issue.) Also, lots of videos don't work, and it's difficult to know > whether it's because of technical issues or because of DRM. > > This may discourage people from using GuixSD. > > My understanding is that Icecat exists because of two reasons: > 1. a trademark/logo issue, > 2. the need to remove non-free code from Firefox. > > But it does more: > 3. it only packages the stables versions of Firefox, > 4. it adds add-ons, > 5. it prevents the installation of non-free plugins, > 6. probably other things that I'm not aware of. > > It seems to me that the trademark/logo issue and the non-free code > removal could be dealt with at the Guix packaging level. It's probably > just a huge bunch of substitutes to do. The package would be huge, but > at least we would have control on it. > > That would remove a layer of complexity, and probably reduce bugs (that > come from that layer). That would also allow us to have a recent > version of Firefox. > > And it would be way better than everyone (I exaggerate a bit) having his their ^ > home-made non-maintened full-of-security-issues Firefox. > > What do you think? > Clément
