[gentoo-user] Re: Firefox and addons no longer supported question

[Martin Vaeth]

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: [TOT: Total offtopic]

[taii...@gmx.com]

I have one from almost 10 years ago, whats the difference :[? how can
you tell?

I still like it though >:[


0xDF372A17.asc
Description: application/pgp-keys

Re: [gentoo-user] bash scrip prompt after bootstrap

[thelma]

On 03/30/2018 11:10 AM, Bas Zoutendijk wrote:
> On Fri 30 Mar 2018 at 10:33:45 -0600, the...@sys-concept.com wrote:
>> I'm using a scrip to log-in/boot strap the system over NFS
>>
>> -
>> #!/bin/sh
>>
>> HOST=${0##*/}
>> HOST=${HOST#*-}
>> ROOT=/mnt/${HOST}
>> ...
>> exec chroot '${ROOT}' /bin/bash -l
>> ---
>>
>> When I'm presented with bash prompt, it is the same as the one I logged
>> IN from.  So to eliminate the confusion I would like to change (add to)
>> the bash prompt the "HOST' name I log-in to.
>>
>> When I log-in I'm presented with: "syscon3 #"
>> I would like it to be: ROOT+HOST
>> eg.: syscon3-eden
> 
>   To change the prompt you want to set $PS1.  For example:
> 
> echo 'export PS1="some string"; exec  /bin/bash -i
> 
> This command tells the Bash inside the chroot to first execute
> 
> export PS1="some string"
> 
> and then to  continue as a regular log-in  shell.  The special syntax of
> the $PS1 string in described in the  Bash man page.  If you just want to
> prepend a string, you do not even have to bother with crafting a syntax:
> 
> echo 'export PS1="(chroot '$HOST') $PS1"; exec  $ROOT /bin/bash -i
> 
>   Sincerely,
> 
>  Bas

The above syntax produced an error: 

chroot-eden: line 30: syntax error near unexpected token `('
chroot-eden: line 30: `echo 'export PS1="(chroot '$HOST') $PS1"; exec 

[gentoo-user] Re: [TOT: Total offtopic]

[Ian Zimmerman]

On 2018-04-02 04:14, tu...@posteo.de wrote:

> Do you have experience in removing the steel back plate from the
> keyboard and later add it back with screws fixing the whole thing
> instead of the rivets, which needs to be removed for this?

No, unfortunately I cannot help.  I've had mine for about 2 years now,
and other than cleaning the keys, it never needed servicing.

-- 
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: [TOT: Total offtopic]

[tuxic]

On 04/01 04:24, Ian Zimmerman wrote:
> On 2018-04-01 12:04, taii...@gmx.com wrote:
> 
> > If you are unable to fix it yourself (but I think you can :D) Unicomp
> > offers parts and repairs for Model M's (along with their kentucky usa
> > made Model M's - they use the original tooling)
> 
> I have owned Unicomp keyboards, and those made after a certain time, I
> think about 7 years ago, are _nothing like_ the real thing.  And I can
> tell the difference because I'm typing on the real thing now, having
> found one in a yard sale for free :-)
 
Lucky you! :)
Do you have experience in removing the steel back plate from the
keyboard and later add it back with screws fixing the whole thing
instead of the rivets, which needs to be removed for this?

It is very very sad, that these wonderful keyboards are nor longer
built with the same quality and feel of use. They are so great!

There are some things in technology (ad not only there) that were
done right just with the first attempt. Sweet spots in time they are.


Cheers
Meino




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

[Bill Kenworthy]

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

[Ian Zimmerman]

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

[Michael King]

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.

[gentoo-user] Re: [TOT: Total offtopic]

[Ian Zimmerman]

On 2018-04-01 12:04, taii...@gmx.com wrote:

> If you are unable to fix it yourself (but I think you can :D) Unicomp
> offers parts and repairs for Model M's (along with their kentucky usa
> made Model M's - they use the original tooling)

I have owned Unicomp keyboards, and those made after a certain time, I
think about 7 years ago, are _nothing like_ the real thing.  And I can
tell the difference because I'm typing on the real thing now, having
found one in a yard sale for free :-)

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

[Dale]

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

[Ian Zimmerman]

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

[Martin Vaeth]

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.

Re: [gentoo-user] [TOT: Total offtopic]

[taii...@gmx.com]

If you are unable to fix it yourself (but I think you can :D) Unicomp
offers parts and repairs for Model M's (along with their kentucky usa
made Model M's - they use the original tooling)


0xDF372A17.asc
Description: application/pgp-keys

Re: [gentoo-user] Firefox and addons no longer supported question

[taii...@gmx.com]

I am sticking with ice-cat aka firefox 52 stable long term support but I
do not know what I shall do when the long terms term is up.maybe
switch to waterfox and hope their dev team is skilled enough to make a
quality product (of course anyone with the skills should assist)

Mozilla is really bad these days they have became almost like microsoft
making changes that no one wants and stealthily forcing
advertising/tracking on people - there really needs to be a professional
fork similar to the devuan/debian split over the evil SystemD. (How come
almost every distro adapted it suddenly overnight? entirely not
suspicious at all)

Damn everything good these days is declared "legacy" and thrown away,
soon a modern laptop won't have any ports at all and will be entirely
wireless like the macbook wheel parody.


0xDF372A17.asc
Description: application/pgp-keys

[gentoo-user] Re: Firefox and addons no longer supported question

[Ian Zimmerman]

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

[Martin Vaeth]

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.