Changing to Chromium

[tkaiser]

Just as a reference. It seems we can install Chrome Extensions by default (longsleep pointed me to this and that), would be interesting for both youtube-mpv and 'Remove Google Redirection'.

[tkaiser]

Based on a quick discussion with @Xaliustoday I think we should overthink Chromium (non) sandboxing. Currently we use --no-sandbox which removes several layers of protection: https://chromium.googlesource.com/chromium/src/+/lkcr/docs/linux_sandboxing.md

 

With enabled sandboxing we run in troubles on arm64 platforms since for whatever reasons there Seccomp-BPF doesn't work. Potential workaround: Disabling this similar to this commit for A64 legacy: https://github.com/ayufan-pine64/linux-pine64/commit/7a78cc22d6a4b79feedc821c9514da59dc3f19de

 

In the end chrome://sandbox should show the first 3 in green and the last 2 in red only:

 

Any objections against removing '--no-sandbox' from default settings affecting arm64 kernel configs for Pine64 and ODROID-C2 currently?

[Igor]

Firefox 54 finally goes multi-process, eight years after work began

https://arstechnica.co.uk/information-technology/2017/06/firefox-multiple-content-processes

[tkaiser]

1 hour ago, Igor said:

Firefox 54 finally goes multi-process, eight years after work began

And Armbian released 5.30 yesterday and ships with Chromium with sandboxing completely disabled (bad) even if we knew better, see my post above from 6 days ago that got ignored. 

 

Is it really necessary to mark @Igorand @zador.blood.stainedin every post where I need an opinion since removing '--no-sandbox' switch from chromium config would require

• changes to a few kernel configs
• tests with Chromium later

To be honest: To me the whole 5.30 release came as a surprise especially since a few open issues exist(ed).

[tkaiser]

On 9.6.2017 at 4:57 PM, tkaiser said:

Any objections against removing '--no-sandbox' from default settings affecting arm64 kernel configs for Pine64 and ODROID-C2 currently?

 

Thank you for all the answers.

[Igor]

2 hours ago, tkaiser said:

Thank you for all the answers.

 

Patience. My response time is currently close to one month and going faster, working more than possible, means risking burn out / mental breakdown, which leads to no response at all for longer period of time. This bug affect all humans and workarounds make things only worse.

[rocketpenguin]

Qupzilla is a pretty good browser which is multi-threaded. It's also faster than both Firefox and Chrome, and can run JS bloatware like Google Docs etc. I think it strikes a good balance between features and speed for "normal people".

[Xalius]

While I am pretty content now with the performance of Chromium after all the tweaks that were applied, I never heard of qupzilla before and am testdriving that on my Pinebook atm. It seems a bit more capable compared to the other lightweight options like Midori.

[tkaiser]

3 hours ago, Igor said:

Patience

Nope, I was aware that 'sometimes in the future' there will be a new Armbian major release exchanging Firefox with Chromium. To my surprise it 'happened' few days ago, now we're at 5.30 and ship with a new default browser on new desktop images and a default config that is slightly more insecure than 'needed'.

 

I was asking for opinions since our current 'style' of development (anyone with commit rights to Armbian repo does whatever he wants) is not that great IMO. I was waiting for something like 'yes, let's do it this or that way' to start working on it (changing kernel configs for the affected arm64 platforms, then testing). But then 5.30 happened without any announcement so there was not even an opportunity to check open issues that need to be fixed prior to release.

[giri@nwrk.biz]

On 14. Mai 2017 at 4:16 PM, hojnikb said:

 

is midori even working stable on arm ?

 

 

Jup, tested it on RPI, OPiZ and some time ago in an chroot on an older armhf tablet.

I use midori on a regular basis. You cannot replace midori with firefox or chromium. Major websites do not render well, or simply won't work.

Since a few weeks logging into my google account simply does not work with midori. I have tested many of these "lightweight" browsers. Midori beats them all, but is far away from replacing Firefox or Chromium.

 

On 17. Juni 2017 at 2:04 PM, rocketpenguin said:

Qupzilla is a pretty good browser which is multi-threaded.

 

Looks nice, I have to test this one and maybe it will replace midori in my package list.

[tkaiser]

Just for the record: tested latest Pinebook image and Profile-sync-daemon still isn't enabled automatically:

tk@pinebook:~$ psd preview
Profile-sync-daemon v6.31 on Ubuntu 16.04.3 LTS

 Systemd service is currently inactive.
 Systemd resync-timer is currently inactive.
 Overlayfs v22 is currently active.

Psd will manage the following per /home/tk/.config/psd/psd.conf:

tk@pinebook:~$ systemctl --user enable psd
Created symlink from /home/tk/.config/systemd/user/default.target.wants/psd.service to /usr/lib/systemd/user/psd.service.
tk@pinebook:~$ systemctl --user start psd
tk@pinebook:~$ psd preview
Profile-sync-daemon v6.31 on Ubuntu 16.04.3 LTS

 Systemd service is currently active.
 Systemd resync-timer is currently active.
 Overlayfs v22 is currently active.

Psd will manage the following per /home/tk/.config/psd/.psd.conf:

Anyone able to confirm?

[zador.blood.stained]

Running "systemctl --user enable ..." using su won't work according to my tests, so psd activation needs to be reworked into a separate login script.

[tkaiser]

1 hour ago, zador.blood.stained said:

so psd activation needs to be reworked into a separate login script.

Adding 'systemctl --user start psd 2>/dev/null' to a profile file that gets copied from skeleton dir at user creation?

[zador.blood.stained]

... or just a new file in /etc/profile.d/ that runs the code once if a special file is present in the home directory.