[gentoo-user] Re: Firefox and addons no longer supported question
On 2018-04-04 19:12, Wol's lists wrote: > Different horses, different courses. I believe the indent was dropped > to save a keystroke, so why the double-space is there (requiring an > extra keystroke) I don't know. > > And why use secretarial style when you're typesetting? One is for > letters, the other is typically for books ... that's the trouble with > all this Artificial Stupidity - it blindly enforces rules that are > irrelevant (or even wrong!!!) for the current scenario. I follow the double space rule when writing, and I find it helpful when text I'm reading (in fixed-size font - which is of course how I read email) is written that way. I didn't know it was "secretarial" - that's definitely a major drawback! ;-) -- Please don't Cc: me privately on mailing lists and Usenet, if you also post the followup to the list or newsgroup. To reply privately _only_ on Usenet and on broken lists which rewrite From, fetch the TXT record for no-use.mooo.com.
Re: [gentoo-user] Re: Firefox and addons no longer supported question
On 02/04/18 21:50, Philip Webb wrote: 180402 Dale wrote: After each period at the end of a sentence, I put in two spaces, not one. Something I was taught years ago somewhere and still do. I only put one after a comma tho. That is correct professional secretarial style, which I always follow too. I was taught to always start every paragraph with an indent. Which I believe is against "professional secretarial style". Different horses, different courses. I believe the indent was dropped to save a keystroke, so why the double-space is there (requiring an extra keystroke) I don't know. And why use secretarial style when you're typesetting? One is for letters, the other is typically for books ... that's the trouble with all this Artificial Stupidity - it blindly enforces rules that are irrelevant (or even wrong!!!) for the current scenario. Cheers, Wol
Re: [gentoo-user] Re: Firefox and addons no longer supported question
On Mon, Apr 02, 2018 at 08:21:17AM -0700, Ian Zimmerman wrote
> On 2018-04-02 03:59, Dale wrote:
>
> > That last bit should read can NOT win. Brain didn't quite make it all
> > the way to keyboard. lol
>
> I read it as beautifully subtle sarcasm, so it worked fine as it was.
>
> BTW, your mails are full of strange space characters - I didn't
> investigate if they're some Unicode spaces or the Windows codepage
> variety. Can you turn that off?
I checked with mc (Midnight Commander) using hex mode view. In that
message from Dale, occurences of "{SPACE}{SPACE}" are encoded as hex
"A0 20". I.e. the first of 2 spaces has the high bit set.
--
Walter Dnes
I don't run "desktop environments"; I run useful applications
Re: [gentoo-user] Re: Firefox and addons no longer supported question
Am Dienstag, 3. April 2018, 11:02:32 CEST schrieb Neil Bothwick:
> On Tue, 03 Apr 2018 09:28:40 +0100, Peter Humphrey wrote:
> > > > After each period at the end of a sentence, I put in two spaces,
> > > > not one. Something I was taught years ago somewhere and still do.
> > > > I only put one after a comma tho.
> > >
> > > That is correct professional secretarial style, which I always follow
> > > too.
> >
> > Correct? In what sense? I've only encountered the practice in American
> > writers (and now Canadian?), so it seems to be a regional preference.
>
> It was done in the UK too. It dates back to the days of typewriters with
> monospaced text, to make sentence breaks clearer. It's an anachronism
> nowadays, but a habit that is hard to break if you were brought up that
> way.
There's also support for it in text editors, e.g., Vim has an option (append
'J' to cpoptions) that makes it treat only punctuation followed by two spaces
as a sentence delimiter, so that using '(' and ')' to move between sentences
skips abbreviations, which I find very practical (and which is basically why I
started following this convention in the first place). Emacs behaves this way
by default, but you can override it by setting 'sentence-end-double-space' to
nil, according to the Emacs manual.
HTH
--
Marc Joliet
--
"People who think they know everything really annoy those of us who know we
don't" - Bjarne Stroustrup
Re: [gentoo-user] Re: Firefox and addons no longer supported question
On Tue, 03 Apr 2018 09:28:40 +0100, Peter Humphrey wrote: > > > After each period at the end of a sentence, I put in two spaces, > > > not one. Something I was taught years ago somewhere and still do. > > > I only put one after a comma tho. > > > > That is correct professional secretarial style, which I always follow > > too. > > Correct? In what sense? I've only encountered the practice in American > writers (and now Canadian?), so it seems to be a regional preference. It was done in the UK too. It dates back to the days of typewriters with monospaced text, to make sentence breaks clearer. It's an anachronism nowadays, but a habit that is hard to break if you were brought up that way. -- Neil Bothwick PC DOS Error #04: Out of disk space. Delete Windows? (Y)es (H)ell yes! pgp5GRulE5rWZ.pgp Description: OpenPGP digital signature
Re: [gentoo-user] Re: Firefox and addons no longer supported question
On Monday, 2 April 2018 21:50:30 BST Philip Webb wrote: > 180402 Dale wrote: > > After each period at the end of a sentence, I put in two spaces, not one. > > Something I was taught years ago somewhere and still do. > > I only put one after a comma tho. > > That is correct professional secretarial style, which I always follow too. Correct? In what sense? I've only encountered the practice in American writers (and now Canadian?), so it seems to be a regional preference. > > Could that be triggering something ? > > I'm using Seamonkey set to send plain text to anything Gentoo related. > > IIRC HTML defaults to collapse double spaces to single ; > word-processors do so too, if you don't tell them not to. KMail also has an option to collapse double spaces to one. -- Regards, Peter.
Re: [gentoo-user] Re: Firefox and addons no longer supported question
Philip Webb wrote: > 180402 Dale wrote: >> After each period at the end of a sentence, I put in two spaces, not one. >> Something I was taught years ago somewhere and still do. >> I only put one after a comma tho. > That is correct professional secretarial style, which I always follow too. > >> Could that be triggering something ? >> I'm using Seamonkey set to send plain text to anything Gentoo related. > IIRC HTML defaults to collapse double spaces to single ; > word-processors do so too, if you don't tell them not to. > When I get my copy back, it still contains two spaces after each sentence. It seems Seamonkey at least is working as it should in that regard. I'm not sure what others are seeing or should be seeing tho, other than what I sent of course. ;-) Dale :-) :-)
Re: [gentoo-user] Re: Firefox and addons no longer supported question
180402 Dale wrote: > After each period at the end of a sentence, I put in two spaces, not one. > Something I was taught years ago somewhere and still do. > I only put one after a comma tho. That is correct professional secretarial style, which I always follow too. > Could that be triggering something ? > I'm using Seamonkey set to send plain text to anything Gentoo related. IIRC HTML defaults to collapse double spaces to single ; word-processors do so too, if you don't tell them not to. -- ,, SUPPORT ___//___, Philip Webb ELECTRIC /] [] [] [] [] []| Cities Centre, University of Toronto TRANSIT`-O--O---' purslowatchassdotutorontodotca
Re: [gentoo-user] Re: Firefox and addons no longer supported question
Martin Vaeth wrote: > Daniel Frey wrote: >> On 04/02/18 08:21, Ian Zimmerman wrote: >>> BTW, your mails are full of strange space characters >> I don't see any extra spaces in Dale's message > After every "." there is a non-breakable space inserted. > I guess this is an attempt of some editor to non-french-space > ASCII texts. > > > I wonder, after each period at the end of a sentence, I put in two spaces, not one. Something I was taught years ago somewhere and still do. I only put one after a comma tho. Could that be triggering something? I'm using Seamonkey which is set to send plain text to anything Gentoo related. Other than that, it's set the way it is. I'm not sure if I can change anything else on it. Dale :-) :-)
Re: [gentoo-user] Re: Firefox and addons no longer supported question
180402 Ian Zimmerman wrote: > On 2018-04-02 08:26, Daniel Frey wrote: >> I don't see any extra spaces in Dale's message, you should also >> probably check your local configuration. > They render fine for me in mutt/neomutt, too. Same here. > I can only see the strange spaces in my editor (emacs 24) > when I start replying to him and quote his material. No problem with Vim. -- ,, SUPPORT ___//___, Philip Webb ELECTRIC /] [] [] [] [] []| Cities Centre, University of Toronto TRANSIT`-O--O---' purslowatchassdotutorontodotca
[gentoo-user] Re: Firefox and addons no longer supported question
Daniel Frey wrote: > On 04/02/18 08:21, Ian Zimmerman wrote: >> >> BTW, your mails are full of strange space characters > > I don't see any extra spaces in Dale's message After every "." there is a non-breakable space inserted. I guess this is an attempt of some editor to non-french-space ASCII texts.
[gentoo-user] Re: Firefox and addons no longer supported question
On 2018-04-02 08:26, Daniel Frey wrote: > I don't see any extra spaces in Dale's message, you should also > probably check your local configuration. They render fine for me in mutt/neomutt, too. I can only see the strange spaces in my editor (emacs 24) when I start replying to him and quote his material. I already have elisp code to massage the quotes so I'm not going to be insistent about it. -- Please don't Cc: me privately on mailing lists and Usenet, if you also post the followup to the list or newsgroup. To reply privately _only_ on Usenet and on broken lists which rewrite From, fetch the TXT record for no-use.mooo.com.
Re: [gentoo-user] Re: Firefox and addons no longer supported question
On 04/02/18 08:21, Ian Zimmerman wrote: > On 2018-04-02 03:59, Dale wrote: > >> That last bit should read can NOT win. Brain didn't quite make it all >> the way to keyboard. lol > > I read it as beautifully subtle sarcasm, so it worked fine as it was. > > BTW, your mails are full of strange space characters - I didn't > investigate if they're some Unicode spaces or the Windows codepage > variety. Can you turn that off? > > ;-) > I don't see any extra spaces in Dale's message, you should also probably check your local configuration. Dan
[gentoo-user] Re: Firefox and addons no longer supported question
On 2018-04-02 03:59, Dale wrote: > That last bit should read can NOT win. Brain didn't quite make it all > the way to keyboard. lol I read it as beautifully subtle sarcasm, so it worked fine as it was. BTW, your mails are full of strange space characters - I didn't investigate if they're some Unicode spaces or the Windows codepage variety. Can you turn that off? ;-) -- Please don't Cc: me privately on mailing lists and Usenet, if you also post the followup to the list or newsgroup. To reply privately _only_ on Usenet and on broken lists which rewrite From, fetch the TXT record for no-use.mooo.com.
[gentoo-user] Re: Firefox and addons no longer supported question
Bill Kenworthy wrote: > On 02/04/18 13:41, Martin Vaeth wrote: >> Bill Kenworthy wrote: >>> I use the palemoon overlay. >> There is also the octopus overlay. >> Anyway, both can only react to upstream. >> >>> builds fine with gcc-6.4 >> Yes, but it has random crashes which do not occur with gcc-5, >> and as somebody familiar with the code posted somewhere, >> the reasons are quite some assumptions in assembler code >> which should not have been made. (I simply repeated these >> claims without checking them.) >> >> Upstream knows about it and therefore officially does not > > Pretty stable for me - ymmv. Yes. I also used to compile it with gcc-6. It segfaulted only occassionally unless you visit "wrong" pages. But it is not the user experience why I mentioned this but the underlying problem these instabilities indicate. (And BTW, with gcc-7 I never succeeded to compile; I had patched some dozen problems, but eventually decided it is too much work.)
[gentoo-user] Re: Firefox and addons no longer supported question
Walter Dnes wrote: > Mind you, the Pale Moon team may not > have the staffing level required to write a new compiler, maintain a > politically correct "community", integrate real-time-chat into the > browser, integrate "Pocket" into the browser, rewrite the GUI every so > often, yada, yada, yada. Why do you mention only some irrelevant points here, ignoring the crucial ones (on top of them: security) which I was talking about? The only relevant thing of those you mention is "new compiler": It is really security relevant to have bindings to current C++ libraries, especially if the other libraries use them. (Reasons: bugfixes and unpredictable side effects.) And if you mean rust: I expect that this will give (and probably already gave) an enormous security boost to firefox. >> The decision to stick with legacy extension api completely excludes >> that there is some convergence of the fork in the future. > > As an end-user, I think you're missing the whole point of Pale Moon. > If I really wanted a Chrome-like browser, I'd use Chrome in the first > place. I, and a lot of other people, switched to Pale Moon precisely > because we *DO NOT WANT* what Firefox has become. To quote an old > meme... I didn't leave Firefox... Firefox left me. Again, I was not talking about relatively irrelevant things like user experience here. As I said, I also liked palemoon in the beginning. It simply turned out an unrealistic project so that I found myself forced to decide to not use it anymore due to security considerations. >> Also the refusal to implement webextension apis (which is consequent, >> since it is hardly possible to maintain 2 more and more diverging >> apis) has the side effect that only obsolete versions of the actively >> maintained extensions like noscript and ublock-origin can be used. > > Wrong. No, correct: Current noscript and ublock-origin cannot be used and never will usable with palemoon again. > Pale Moon has its own XUL extension ecosystem at > https://addons.palemoon.org/extensions/ Sure, they have to. This doesn't mean that this is worth something: > Noscript equivalents... > * https://addons.palemoon.org/addon/noscript/ This is not "equivalent" but the legacy noscript itself which I had mentioned. As I said, _currently_ this is still maintained (in the sense that most severe bugs are fixed) because of the tor browser. Upstream's main activity is clearly the web extension. BTW, this is nothing new: For a long time one had to use 2-years old versions of noscript, because important new APIs current noscript needed had not been implemented yet. Eventually the new API was pulled from firefox upstream, so that currently at least the most recent (obsolete) version of noscript can be used. In future, you cannot expect such a thing to ever happen again. > * https://addons.mozilla.org/firefox/addon/yesscript/ ... and another legacy extension whose maintainance apparently stopped 2 years ago.
Re: [gentoo-user] Re: Firefox and addons no longer supported question
On 02/04/18 13:41, Martin Vaeth wrote: > Bill Kenworthy wrote: >> I use the palemoon overlay. > There is also the octopus overlay. > Anyway, both can only react to upstream. > >> builds fine with gcc-6.4 > Yes, but it has random crashes which do not occur with gcc-5, > and as somebody familiar with the code posted somewhere, > the reasons are quite some assumptions in assembler code > which should not have been made. (I simply repeated these > claims without checking them.) > > Upstream knows about it and therefore officially does not Pretty stable for me - ymmv. What is annoying is sometimes complex pages do not load properly (e.g., job application sites which seem to have a lot of JavaScript running in the background.- possibly due to add blocking while FF when it works is vanilla) BillK
Re: [gentoo-user] Re: Firefox and addons no longer supported question
On Mon, Apr 02, 2018 at 05:41:03AM +, Martin Vaeth wrote
I don't speak officially for Pale Moon. See
https://forum.palemoon.org/viewtopic.php?f=4&t=7818 for the official
word about the manpower situation. Mind you, the Pale Moon team may not
have the staffing level required to write a new compiler, maintain a
politically correct "community", integrate real-time-chat into the
browser, integrate "Pocket" into the browser, rewrite the GUI every so
often, yada, yada, yada. BTW, Firefox's share of the mobile market is
0.53% as per netmarketshare.com
https://netmarketshare.com/?options={%22filter%22%3A{%22%24and%22%3A[{%22deviceType%22%3A{%22%24in%22%3A[%22Mobile%22]}}]}%2C%22dateLabel%22%3A%22Trend%22%2C%22attributes%22%3A%22share%22%2C%22group%22%3A%22browser%22%2C%22sort%22%3A{%22share%22%3A-1}%2C%22id%22%3A%22browsersDesktop%22%2C%22dateInterval%22%3A%22Monthly%22%2C%22dateStart%22%3A%222017-03%22%2C%22dateEnd%22%3A%222018-02%22%2C%22segments%22%3A%22-1000%22%2C%22pageLength%22%3A10}
So why bother?
As far as features are concerned, again go to the official website
http://www.palemoon.org/technical.shtml
> The decision to stick with legacy extension api completely excludes
> that there is some convergence of the fork in the future.
As an end-user, I think you're missing the whole point of Pale Moon.
If I really wanted a Chrome-like browser, I'd use Chrome in the first
place. I, and a lot of other people, switched to Pale Moon precisely
because we *DO NOT WANT* what Firefox has become. To quote an old
meme... I didn't leave Firefox... Firefox left me.
> Also the refusal to implement webextension apis (which is consequent,
> since it is hardly possible to maintain 2 more and more diverging
> apis) has the side effect that only obsolete versions of the actively
> maintained extensions like noscript and ublock-origin can be used.
Wrong. Pale Moon has its own XUL extension ecosystem at
https://addons.palemoon.org/extensions/ Since they're written
specifically for Pale Moon, the compatability headaches of using Firefox
extensions do not exist.
Noscript equivalents...
* https://addons.palemoon.org/addon/noscript/
* https://addons.mozilla.org/firefox/addon/yesscript/
Adblockers...
* https://addons.palemoon.org/addon/abprime/
* https://addons.palemoon.org/addon/adblock-latitude/
--
Walter Dnes
I don't run "desktop environments"; I run useful applications
Re: [gentoo-user] Re: Firefox and addons no longer supported question
tu...@posteo.de wrote: > On 04/02 05:41, Martin Vaeth wrote: >> Bill Kenworthy wrote: >>> I use the palemoon overlay. >> There is also the octopus overlay. >> Anyway, both can only react to upstream. >> >>> builds fine with gcc-6.4 >> Yes, but it has random crashes which do not occur with gcc-5, >> and as somebody familiar with the code posted somewhere, >> the reasons are quite some assumptions in assembler code >> which should not have been made. (I simply repeated these >> claims without checking them.) >> >> Upstream knows about it and therefore officially does not >> support building with gcc-6. Since firefox upstream has fixed >> all these things ages ago, and palemoon is not able to identify >> or pull the corresponding patches this shows IMHO that it >> has already diverged to a degree that it cannot be reasonably >> maintained with the resources they have, and I doubt that >> security issues are closed (or worse: recognized) timely: >> In contrast to crashes (even Heisenbug crashes), security >> issues cannot be "detected" if there is no expert regularly >> checking the code very carfully. >> >> The decision to stick with legacy extension api completely >> excludes that there is some convergence of the fork in the >> future. >> >> Also the refusal to implement webextension apis (which is >> consequent, since it is hardly possible to maintain 2 >> more and more diverging apis) has the side effect that >> only obsolete versions of the actively maintained extensions >> like noscript and ublock-origin can be used. In the moment, >> the legacy version of noscript is still maintained, but only >> because of the tor browser. I suppose eventually this will change. >> >> I also do not know much about waterfox, but if one goal ist >> to keep legacy extensions, I am afraid it will go the palemoon >> way, too: >> It seems currently that mozilla, google, and apple are the only >> oranganizations with enough resources to maintain full browsers, >> and any forks of their browsers which diverge more than a patchset >> of essentially fixed size are doomed to fail for this very reason. >> >> > > ...and if after all that (at least) firefox gets so bulky and has such > a hugh memory footprint that (on a multitasking OS) no other > reasonable "powerful" application will multitask with it (or your > machine goes swapping) and if mozilla itsself walks down an at least > questionable way...then... > What? > > In the moment I cannot use firefox - regardless how > advanced/secure/modern/or what it is. It does not fit into > my working environment - it is to huge. > > Cheers > Meino > I have to agree. I use different Firefox profiles for different things. One reason, I can be logged into same website but as different users at the same time. Another reason, when one profile becomes a memory hog, I can restart it but not disturb the others. Another reason, I can customize each profile based on what I do with it. I notice in the last year or so that Firefox regularly uses over 1GB of ram in most all of my profiles. Sometimes it can approach 2GBs. I've tried going to about:memory and clicking the free up memory button but it does little good. It may free up some but generally not enough to matter. Closing and restarting Firefox does work tho. I have one profile that I use for things such as financial sites and ordering online. I use addons like noscript, adblock and such which sort of helps prevent tracking and such. I also use the https addon with it as well. I sort of wish Firefox would shrink back down on its size and let us install addons for features we want and be able to do that for each profile. For example, I have one profile that I use to download videos with. It has download helper installed on it but I don't install it on the other profiles. On one profile, I have a screenshot tool installed. I use it to document some admin/mod stuff I do on a website. I don't need a screenshot tool on other profiles tho. Basically, it would be nice if more things were that way because we can chose what features we want for each profile based on what we do with it. Even USE flags won't work with this because if it is done with USE flags, it applies to all profiles. Even if a person only has one profile, they just install what features they want instead of a whole bunch of stuff that may never be used or even wanted. While I like progress on some things, others, I wish progress had more options. Sometimes, I don't want a bloated monster of a program. If anything, I may want to add things that improve security but has no other "features" included. Then on others, I may not care much about security but want features. Having a bare program and the ability to add features, that allows everyone to have what they want. They can pick a huge bloated program or a bare metal barely gets the job done program. Just thinking out loud. ;-) Dale :-) :-)
Re: [gentoo-user] Re: Firefox and addons no longer supported question
On 04/02 08:23, Martin Vaeth wrote: > tu...@posteo.de wrote: > > On 04/02 05:41, Martin Vaeth wrote: > >> It seems currently that mozilla, google, and apple are the only > >> oranganizations with enough resources to maintain full browsers, > >> and any forks of their browsers which diverge more than a patchset > >> of essentially fixed size are doomed to fail for this very reason. > > > > ...and if after all that (at least) firefox gets so bulky and has such > > a hugh memory footprint that (on a multitasking OS) no other > > reasonable "powerful" application will multitask with it (or your > > machine goes swapping) and if mozilla itsself walks down an at least > > questionable way...then... > > What? > > It's the way it is whether you like it or not. > > > In the moment I cannot use firefox - regardless how > > advanced/secure/modern/or what it is. It does not fit into > > my working environment - it is to huge. > > The memory footprint of the main system with firefox is here > about 1GB. So if you have another memory hungry application running > (like emerging gcc in the background) you will need at least 2GB. > I guess 2GB RAM is about the limit to have a usable system, nowadays. > Working with 2GB and a dual core is possible with current gentoo > and firefox without too many restrictions, but of course it is much > more fun with 8GB and i3, which is probably about the smallest > desktop machine which you get nowadays (if you buy a new one). > > I found an interesting thread here: https://www.reddit.com/r/firefox/comments/7zfopp/howto_geek_recommends_against_using_waterfox_pale/ Cheers Meino
[gentoo-user] Re: Firefox and addons no longer supported question
tu...@posteo.de wrote: > On 04/02 05:41, Martin Vaeth wrote: >> It seems currently that mozilla, google, and apple are the only >> oranganizations with enough resources to maintain full browsers, >> and any forks of their browsers which diverge more than a patchset >> of essentially fixed size are doomed to fail for this very reason. > > ...and if after all that (at least) firefox gets so bulky and has such > a hugh memory footprint that (on a multitasking OS) no other > reasonable "powerful" application will multitask with it (or your > machine goes swapping) and if mozilla itsself walks down an at least > questionable way...then... > What? It's the way it is whether you like it or not. > In the moment I cannot use firefox - regardless how > advanced/secure/modern/or what it is. It does not fit into > my working environment - it is to huge. The memory footprint of the main system with firefox is here about 1GB. So if you have another memory hungry application running (like emerging gcc in the background) you will need at least 2GB. I guess 2GB RAM is about the limit to have a usable system, nowadays. Working with 2GB and a dual core is possible with current gentoo and firefox without too many restrictions, but of course it is much more fun with 8GB and i3, which is probably about the smallest desktop machine which you get nowadays (if you buy a new one).
Re: [gentoo-user] Re: Firefox and addons no longer supported question
On 04/02 05:41, Martin Vaeth wrote: > Bill Kenworthy wrote: > > I use the palemoon overlay. > > There is also the octopus overlay. > Anyway, both can only react to upstream. > > > builds fine with gcc-6.4 > > Yes, but it has random crashes which do not occur with gcc-5, > and as somebody familiar with the code posted somewhere, > the reasons are quite some assumptions in assembler code > which should not have been made. (I simply repeated these > claims without checking them.) > > Upstream knows about it and therefore officially does not > support building with gcc-6. Since firefox upstream has fixed > all these things ages ago, and palemoon is not able to identify > or pull the corresponding patches this shows IMHO that it > has already diverged to a degree that it cannot be reasonably > maintained with the resources they have, and I doubt that > security issues are closed (or worse: recognized) timely: > In contrast to crashes (even Heisenbug crashes), security > issues cannot be "detected" if there is no expert regularly > checking the code very carfully. > > The decision to stick with legacy extension api completely > excludes that there is some convergence of the fork in the > future. > > Also the refusal to implement webextension apis (which is > consequent, since it is hardly possible to maintain 2 > more and more diverging apis) has the side effect that > only obsolete versions of the actively maintained extensions > like noscript and ublock-origin can be used. In the moment, > the legacy version of noscript is still maintained, but only > because of the tor browser. I suppose eventually this will change. > > I also do not know much about waterfox, but if one goal ist > to keep legacy extensions, I am afraid it will go the palemoon > way, too: > It seems currently that mozilla, google, and apple are the only > oranganizations with enough resources to maintain full browsers, > and any forks of their browsers which diverge more than a patchset > of essentially fixed size are doomed to fail for this very reason. > > ...and if after all that (at least) firefox gets so bulky and has such a hugh memory footprint that (on a multitasking OS) no other reasonable "powerful" application will multitask with it (or your machine goes swapping) and if mozilla itsself walks down an at least questionable way...then... What? In the moment I cannot use firefox - regardless how advanced/secure/modern/or what it is. It does not fit into my working environment - it is to huge. Cheers Meino
[gentoo-user] Re: Firefox and addons no longer supported question
Bill Kenworthy wrote: > I use the palemoon overlay. There is also the octopus overlay. Anyway, both can only react to upstream. > builds fine with gcc-6.4 Yes, but it has random crashes which do not occur with gcc-5, and as somebody familiar with the code posted somewhere, the reasons are quite some assumptions in assembler code which should not have been made. (I simply repeated these claims without checking them.) Upstream knows about it and therefore officially does not support building with gcc-6. Since firefox upstream has fixed all these things ages ago, and palemoon is not able to identify or pull the corresponding patches this shows IMHO that it has already diverged to a degree that it cannot be reasonably maintained with the resources they have, and I doubt that security issues are closed (or worse: recognized) timely: In contrast to crashes (even Heisenbug crashes), security issues cannot be "detected" if there is no expert regularly checking the code very carfully. The decision to stick with legacy extension api completely excludes that there is some convergence of the fork in the future. Also the refusal to implement webextension apis (which is consequent, since it is hardly possible to maintain 2 more and more diverging apis) has the side effect that only obsolete versions of the actively maintained extensions like noscript and ublock-origin can be used. In the moment, the legacy version of noscript is still maintained, but only because of the tor browser. I suppose eventually this will change. I also do not know much about waterfox, but if one goal ist to keep legacy extensions, I am afraid it will go the palemoon way, too: It seems currently that mozilla, google, and apple are the only oranganizations with enough resources to maintain full browsers, and any forks of their browsers which diverge more than a patchset of essentially fixed size are doomed to fail for this very reason.
Re: [gentoo-user] Re: Firefox and addons no longer supported question
On 02/04/18 08:28, Ian Zimmerman wrote: > On 2018-04-01 18:22, Dale wrote: > >> Just for giggles, I tried to re-emerge palemoon. This is part of the >> output I got. >> >> * Supported GCC versions: 4.7, 4.9 >> * Selected GCC version: 6.4 > I no longer use the overlay; I have my own private ebuild series. I > tried to remove the old gcc dependency, but as Martin says it doesn't > work; the build just crashes at a later point. > > Luckily gcc is slotted so I can keep the old version around just for > this purpose. > I use the palemoon overlay. builds fine with gcc-6.4 etc: PALEMOON_ENABLE_UNSUPPORTED_COMPILERS=1 emerge palemoon and rattus ~ # equery l palemoon * Searching for palemoon ... [I-O] [ ] www-client/palemoon-27.8.2:0 rattus ~ # BillK
[gentoo-user] Re: Firefox and addons no longer supported question
On 2018-04-01 18:22, Dale wrote: > Just for giggles, I tried to re-emerge palemoon. This is part of the > output I got. > > * Supported GCC versions: 4.7, 4.9 > * Selected GCC version: 6.4 I no longer use the overlay; I have my own private ebuild series. I tried to remove the old gcc dependency, but as Martin says it doesn't work; the build just crashes at a later point. Luckily gcc is slotted so I can keep the old version around just for this purpose. -- Please don't Cc: me privately on mailing lists and Usenet, if you also post the followup to the list or newsgroup. To reply privately _only_ on Usenet and on broken lists which rewrite From, fetch the TXT record for no-use.mooo.com.
Re: [gentoo-user] Re: Firefox and addons no longer supported question
I've been using Palemoon, built with gcc/6.40-r1, for about a month now with only two crashes that I can think of. Otherwise it has been doing everything I need in a browser and I'm very happy with it. I still keep Firefox around, but rarely fire it up anymore. I am curious, however, what the Palemoon devs will do once support for gcc/6.4.0 is dropped, as it straight-up won't let me build Palemoon with anything newer. I guess a person could just use the pre-built binaries from the "palemoon" overlay, but I've been building it from source from the "octopus" overlay. On 04/01/2018 05:26 PM, Ian Zimmerman wrote: On 2018-04-01 16:29, Martin Vaeth wrote: An alarm sign for me was that palemoon was eventually dropped for android after being practically unmaintained (i.e. with known open security holes) for months/years. A similar alarm sign concerning linux is that they were not able to pull the fixes for the assembler code which relied on undocumented behaviour of <=gcc-5, even months after gcc-7 was out. Even if these problems are not marked as "security" issues, they can easily be some. WTH is even assembly code _doing_ in a browser?? That is insane. now that I know this is the reason why palemoon needs gcc 4, I will definitely look into it more closely. Experience shows that it is not possible to "hide": Sooner or later a website you do have to use for some reason will require such a feature. Eventually the number of these websites increases. And then you are at a dead end. Nowadays, it has already "practically" become impossible to use exclusively lynx or (e)links; in a while it will be impossible to use a browser which does not support certain new "features". You know the economist Keynes quote about "the long run". Applies quite well here.
Re: [gentoo-user] Re: Firefox and addons no longer supported question
Ian Zimmerman wrote: > On 2018-04-01 16:29, Martin Vaeth wrote: > >> An alarm sign for me was that palemoon was eventually dropped for >> android after being practically unmaintained (i.e. with known open >> security holes) for months/years. A similar alarm sign concerning >> linux is that they were not able to pull the fixes for the assembler >> code which relied on undocumented behaviour of <=gcc-5, even months >> after gcc-7 was out. Even if these problems are not marked as >> "security" issues, they can easily be some. > WTH is even assembly code _doing_ in a browser?? That is insane. > > now that I know this is the reason why palemoon needs gcc 4, I will > definitely look into it more closely. > > Just for giggles, I tried to re-emerge palemoon. This is part of the output I got. >>> Running pre-merge checks for www-client/palemoon-27.8.3 * Checking for at least 7 GiB disk space at "/var/tmp/portage/www-client/palemoon-27.8.3/temp" ... [ ok ] * Checking compiler profile... * Building Pale Moon with a compiler other than a supported gcc version * may result in an unstable build. * You can use gcc-config to change your compiler profile, just remember * to change it back afterwards. * You need to have the appropriate versions of gcc installed for them * to be shown in gcc-config. * Alternatively, you can set the PALEMOON_ENABLE_UNSUPPORTED_COMPILERS * environment variable to 1 either by exporting it from the current shell * or by adding it to your make.conf file. * Be aware though that building Pale Moon with an unsupported compiler * means that the official support channels may refuse to offer any * kind of help in case the build fails or the browser behaves incorrectly. * Supported GCC versions: 4.7, 4.9 * Selected GCC version: 6.4 * ERROR: www-client/palemoon-27.8.3::palemoon failed (pretend phase): * (no error message) * * Call stack: * ebuild.sh, line 124: Called pkg_pretend * ebuild.sh, line 357: Called palemoon-4_pkg_pretend * palemoon-4.eclass, line 22: Called die * The specific snippet of code: * die * * If you need support, post the output of `emerge --info '=www-client/palemoon-27.8.3::palemoon'`, * the complete build log and the output of `emerge -pqv '=www-client/palemoon-27.8.3::palemoon'`. * The complete build log is located at '/var/log/portage/www-client:palemoon-27.8.3:20180401-230351.log'. * For convenience, a symlink to the build log is located at '/var/tmp/portage/www-client/palemoon-27.8.3/temp/build.log'. * The ebuild environment file is located at '/var/tmp/portage/www-client/palemoon-27.8.3/temp/die.env'. * Working directory: '/var/tmp/portage/www-client/palemoon-27.8.3/homedir' * S: '/var/tmp/portage/www-client/palemoon-27.8.3/work/palemoon-27.8.3' That is from the overlay palemoon and the latest version of it. So, it still depends on a old version of gcc which considering the age of it, is sort of odd. Why has that not been updated? Is it updatable or is it going to require some serious time consuming effort to do so and there are not enough people to do it? The overlay I might add, has the latest version of Palemoon according to the website. It's not the overlay that is running behind, it's palemoon itself. I admit, I wish things didn't have to update so often at times BUT for some things, it just has to be that way. I don't worry about security issues with something like Kwrite or Okular but I do worry about it with things like web browsers that I use to make purchases or check on financial websites such as banks etc. I want those to be secure as possible even if it means updating each week. This is interesting. Others who use palemoon may at least want to be aware of it. Dale :-) :-)
[gentoo-user] Re: Firefox and addons no longer supported question
On 2018-04-01 16:29, Martin Vaeth wrote: > An alarm sign for me was that palemoon was eventually dropped for > android after being practically unmaintained (i.e. with known open > security holes) for months/years. A similar alarm sign concerning > linux is that they were not able to pull the fixes for the assembler > code which relied on undocumented behaviour of <=gcc-5, even months > after gcc-7 was out. Even if these problems are not marked as > "security" issues, they can easily be some. WTH is even assembly code _doing_ in a browser?? That is insane. now that I know this is the reason why palemoon needs gcc 4, I will definitely look into it more closely. > Experience shows that it is not possible to "hide": > Sooner or later a website you do have to use for some reason > will require such a feature. Eventually the number of these > websites increases. And then you are at a dead end. > Nowadays, it has already "practically" become impossible to > use exclusively lynx or (e)links; in a while it will be impossible > to use a browser which does not support certain new "features". You know the economist Keynes quote about "the long run". Applies quite well here. -- Please don't Cc: me privately on mailing lists and Usenet, if you also post the followup to the list or newsgroup. To reply privately _only_ on Usenet and on broken lists which rewrite From, fetch the TXT record for no-use.mooo.com.
[gentoo-user] Re: Firefox and addons no longer supported question
Ian Zimmerman wrote:
> On 2018-04-01 09:15, Martin Vaeth wrote:
>
>> noscript, ublock-origin, and https-everywhere (maybe for privacy also
>> coupled with decentraleyes, duckduckgo{-privacy-esesntials},
>> canvasblocker, skip-redirect)
I had forgottten to mention: These WebExtensions (and some more)
can be installed system-wide with portage using the mv overlay. ;)
> Didn't know ublock was available as a webext.
This was one of the first extensions which had been rewritten.
It is even available for chromium. This (partial) browser independence
is another advantage of WebExtensions.
However, noscript uses some more advanced APIs which were
introduced more recently (and so far only in firefox but not chromium).
I do not know the details, but if I understood correctly, ublock-origin
can come "too late" in certain cases which could be fixed only by these
new APIs: This was the reason, that the WebExtension variant of noscript
had been delayed until firefox-57 came out. I have no idea whether current
versions of ublock-origin were able to fix these issues.
I have a bit experience with WebExtensions in general and must say I like
the concept: It gives enough power to program such protection extensions
and simultaneously makes it impossible to do malevolent things, unless
the extension requests corresponding permissions.
Legacy extensions, in contrast, could easily misuse their power and
break things (possibly even unintentional in case one of the frequent
API changes was happening).
Thus, the restriction of APIs indeed has a certain positive effect.
> I have been looking at them since I adopted palemoon mid-yesteryear.
An alarm sign for me was that palemoon was eventually dropped for
android after being practically unmaintained (i.e. with known open
security holes) for months/years. A similar alarm sign concerning
linux is that they were not able to pull the fixes for the assembler
code which relied on undocumented behaviour of <=gcc-5, even months
after gcc-7 was out. Even if these problems are not marked as
"security" issues, they can easily be some.
All in all, despite first I considered palemoon as a good idea,
I have removed it since some months for these security considerations.
> seems to me almost all are in new code added to FF after the fork, and
> moreover in code handling new web "features" which I never use.
Experience shows that it is not possible to "hide":
Sooner or later a website you do have to use for some reason
will require such a feature. Eventually the number of these
websites increases. And then you are at a dead end.
Nowadays, it has already "practically" become impossible to
use exclusively lynx or (e)links; in a while it will be impossible
to use a browser which does not support certain new "features".
> bundled version of freetype
I cannot comment much on this, but palemoon had a lot of bugs
if you unbundle libraries. In any case, this is more an ebuild
thing than an upstream thing: Unfortunately, unbundling is
supported by neither upstream.
[gentoo-user] Re: Firefox and addons no longer supported question
On 2018-04-01 09:15, Martin Vaeth wrote:
> If you speak about defenses like noscript, there are safer variants
> available. I guess the usage of the already mentioned user.js (of
> course adapted to your needs) together with current Webextensions
> noscript, ublock-origin, and https-everywhere (maybe for privacy also
> coupled with decentraleyes, duckduckgo{-privacy-esesntials},
> canvasblocker, skip-redirect) does protect you more than using old
> versions of these packages.
I'll look at these things. Didn't know ublock was available as a webext.
> Not to speak about freshly found security holes.
I have been looking at them since I adopted palemoon mid-yesteryear. It
seems to me almost all are in new code added to FF after the fork, and
moreover in code handling new web "features" which I never use.
> > This is a tangent from the thread topic, but there is another
> > inconvenience of modern FF that keeps me from re-adopting it: font
> > rendering.
>
> I do not have experience with this, but there is also a lot
> customizable in user.js (i.e. about:config). I guess you have
> to switch off (or on) some hardware acceleration. There is also
> a rich "themes" API which might contain relevant options.
Of course I'm no expert either (if I were, I would invest the effort to
make it work for me), but IMO this is not in FF proper but in the
bundled version of freetype - which cannot be unbundled via USE. So
it's all about this:
https://www.freetype.org/freetype2/docs/subpixel-hinting.html
and the reasons I can make it work with palemoon:
1. palemoon doesn't bundle freetype
2. I froze my freetype at 2.7.1, the last version where it can still be
disabled
--
Please don't Cc: me privately on mailing lists and Usenet,
if you also post the followup to the list or newsgroup.
To reply privately _only_ on Usenet and on broken lists
which rewrite From, fetch the TXT record for no-use.mooo.com.
[gentoo-user] Re: Firefox and addons no longer supported question
Ian Zimmerman wrote:
> On 2018-03-31 08:18, Martin Vaeth wrote:
>
>> As usual, there is the balance
>> "convenience" (old plugins) <-> "security".
>> In the beginning (say, until firefox-52 is no longer supported
>> upstream), there is a certain choice. But after that staying on the
>> "convenience" side is not sane anymore.
>
> There are probably few people more familiar with this tradeoff than
> myself :P. But the browser case is a bit different, because the
> "convenience" features (in my case, at least) themselves have to do with
> security. Using the latest official Mozilla browser means trusting
> their built-in defenses are as good as my current plugin based ones.
> And I have doubts about that.
If you speak about defenses like noscript, there are safer variants
available. I guess the usage of the already mentioned user.js
(of course adapted to your needs) together with current Webextensions
noscript, ublock-origin, and https-everywhere (maybe for privacy
also coupled with decentraleyes, duckduckgo{-privacy-esesntials},
canvasblocker, skip-redirect) does protect you more than using
old versions of these packages.
Not to speak about freshly found security holes.
> This is a tangent from the thread topic, but there is another
> inconvenience of modern FF that keeps me from re-adopting it: font
> rendering.
I do not have experience with this, but there is also a lot
customizable in user.js (i.e. about:config). I guess you have
to switch off (or on) some hardware acceleration. There is also
a rich "themes" API which might contain relevant options.
However, as mentioned, I have no experience with all this.
[gentoo-user] Re: Firefox and addons no longer supported question
On 2018-03-31 08:18, Martin Vaeth wrote: > As usual, there is the balance > "convenience" (old plugins) <-> "security". > In the beginning (say, until firefox-52 is no longer supported > upstream), there is a certain choice. But after that staying on the > "convenience" side is not sane anymore. There are probably few people more familiar with this tradeoff than myself :P. But the browser case is a bit different, because the "convenience" features (in my case, at least) themselves have to do with security. Using the latest official Mozilla browser means trusting their built-in defenses are as good as my current plugin based ones. And I have doubts about that. This is a tangent from the thread topic, but there is another inconvenience of modern FF that keeps me from re-adopting it: font rendering. You will pry my beautiful thin DejaVu Sans from my dead body, and give my dead body blurry webfonts in return. -- Please don't Cc: me privately on mailing lists and Usenet, if you also post the followup to the list or newsgroup. To reply privately _only_ on Usenet and on broken lists which rewrite From, fetch the TXT record for no-use.mooo.com.
[gentoo-user] Re: Firefox and addons no longer supported question
tu...@posteo.de wrote: > > There two reasons for which I have switched to waterfox: Privacy and > memory. > > About:config and search for "telemetry" Telemetry can be switched off. > Or check how many URLS are configured under about:config. It is in "about:config", so they can be switched off. However, for some it is wise not to: There is a balance between security and privacy - e.g. ask a public server for known malware sites at obvious cost of privacy. You might want to have a look at the customization from e.g. https://github.com/ghacksuserjs/ghacks-user.js
Re: [gentoo-user] Re: Firefox and addons no longer supported question
On 03/31 12:17, Arve Barsnes wrote: > On 31 March 2018 at 10:18, Martin Vaeth wrote: > > Exceptions are only certain well-defined APIs which will presumably > > not change dramatically in future versions. > > For instance, there is a tab API, but essentially it is limited > > to basic things like searching/activating/closing/opening tabs etc: > > https://developer.mozilla.org/en-US/Add-ons/WebExtensions/Working_with_the_Tabs_API > > So no WebExtension will ever be able to offer tab functionality which > > goes beyond that. > > Take a look at their bugzilla for bugs tracking a lot of new > functionality in the extension APIs that will come in future releases. > Especially around tabs, as many popular extensions did stuff with > tabs. > > Personally I upgraded despite losing some stuff, but I think most of > it will return in some form at some point. > Firefox is eaten my RAM (8GB) . An application, which does not co-operate with other applications due to its memory footprint does not co-operate with other application due to its memory footprint regardless how advance it is. There two reasons for which I have switched to waterfox: Privacy and memory. About:config and search for "telemetry" Or check how many URLS are configured under about:config. Why need the browser need to know them in beforehand? Cheers Meino
Re: [gentoo-user] Re: Firefox and addons no longer supported question
On 31 March 2018 at 10:18, Martin Vaeth wrote: > Exceptions are only certain well-defined APIs which will presumably > not change dramatically in future versions. > For instance, there is a tab API, but essentially it is limited > to basic things like searching/activating/closing/opening tabs etc: > https://developer.mozilla.org/en-US/Add-ons/WebExtensions/Working_with_the_Tabs_API > So no WebExtension will ever be able to offer tab functionality which > goes beyond that. Take a look at their bugzilla for bugs tracking a lot of new functionality in the extension APIs that will come in future releases. Especially around tabs, as many popular extensions did stuff with tabs. Personally I upgraded despite losing some stuff, but I think most of it will return in some form at some point.
[gentoo-user] Re: Firefox and addons no longer supported question
Dale wrote: > > I been holding off on upgrading Firefox. Basically, it breaks addons > that I just can't go without. Tab groups and some other tab utilities > are among them. Basically the situation is the following: >=firefox-57 support so-called WebExtensions which intentionally are less powerful (hence safer) than legacy extensions. For security and compatibility reasons, it will *never* be the case anymore that WebExtensions are able to change browser behaviour. Exceptions are only certain well-defined APIs which will presumably not change dramatically in future versions. For instance, there is a tab API, but essentially it is limited to basic things like searching/activating/closing/opening tabs etc: https://developer.mozilla.org/en-US/Add-ons/WebExtensions/Working_with_the_Tabs_API So no WebExtension will ever be able to offer tab functionality which goes beyond that. Essentially, there is no other choice than to live with it: Stable firefox-52 and maybe some firefox forks (palemoon, waterfox, tox-browser) support legacy extensions for a while. However, if they support them for a longer period and do not have similar resources than mozilla, I would not trust them anymore, because it means that they diverged from upstream too much to fix all security issues by pulling. (Not to speak about security issues existing in the legacy extension code which will never be fixed by upstream, anyway). As usual, there is the balance "convenience" (old plugins) <-> "security". In the beginning (say, until firefox-52 is no longer supported upstream), there is a certain choice. But after that staying on the "convenience" side is not sane anymore.
