Re: IceWeasel-UXP and IceDove-UXP

[Jesse Gibbons]

On Sun, 21 Jul 2019 08:07:16 +0000
N <address@hidden> wrote:


> As I wrote on IRC, I'm sceptic about the -uxp projects in hyperbola.
> They can be imported here and be watched in the long-term.
> 
> There are a couple of problems to looks at:
> 
> - The committer list of uxp upstream and its hostile way to approach
>   brand defense (been there, dealt with it off-list, but was lucky
> enough to read the complete license exeptions before contacting them.
I'll keep that in mind.

> look at freebsd who got shouted at in github for even daring to have
> a public work-in-progress package and then asking).
I'm having a bit of difficulty finding what you're talking about here.
What are some keywords to search? I've tried "freebsd controversy" and
"freebsd github" and "freebsd trademark" and variants, but I have not
found anything like that.
> 
> - The people who work on it in Hyperbola are far less than for example
>   people paid to do the work in Firefox (or Thunderbird, though I'm
> not sure if TB is paid for). Money matters, and I can fully
> understand why so few people with so few patches work on the 2
> projects in hyperbola.
It looks like the developers at hyperbola are committing frequently to
their icedove-uxp git repo.
https://git.hyperbola.info:50100/software/icedove-uxp.git/log/
> 
> Which leads me to:
> 
> - My experience in Guix about packaging and accepted packages is that
> it is not only about licensing and ensuring software freedom beyond
> what upstream intended to, but also about ensuring user security (see
> the countless hours invested by our Icecat maintainer in backporting
>   patches from Firefox, etc). Given that Hyperbola is an Operating
> System, do they hold their own software accountable to the same
> standards they check external CVEs (etc) for?
>   With Mozilla and downstreams of Mozilla, we get at least the
> dedication to checking for bugs and ensuring they get fixed.
Another issue worth checking out.
> 
> - Decisions in Hyperbola I read which argue for why this was done are
>   questionable from my personal point of view. It is easy to fall into
>   the "Rust is bloat" trap. To mention it as one of the main arguments
>   why this fork exists is odd.

guix says Rust is over 200MB (which du says nearly all of it is the
lib/rustlib directory where rust is installed), and mozilla apps worked
fine before they had rust, so although I haven't run any benchmarks, I
do not think calling it bloat based on its size is inaccurate.

Since bloat takes up a large amount of resources, be it RAM or CPU, it
is good to cut out the bloat if it can make an app smaller and faster.
Thus, if rust is bloat, it is probably good to remove it.

As for it being a main argument for the uxp packages to exist, it is a
good idea to have a browser that uses less resources than the
alternatives. I do not find it an odd argument at all.

If you could provide a cogent argument for keeping rust (i.e. for
security reasons) I would be interested in looking into it. If you
think rust is not bloat, I would be interested in your arguments to
that end as well.
> 
> 
> Closing note: please decide to post to one list, not 2 or more :)
>