[Linux-aus] contest proposal

[Russell Coker]

On Monday, 1 January 2024 13:18:40 AEDT Info via linux-aus wrote:
> #1 recommendation. As tested on 2 GB Raspberry Pi 4.
> 
> Tackle Web browsers.

Yes, browsers have been very big for quite a while.  Chrome (and presumably 
all derivatives) has recently followed the example of Firefox in freeing 
memory from unused tabs (I know someone who has over 2000 Firefox tabs on a 
system with 16G of RAM).

> Use Firefox as an example. Installing NoScript reduces all overheads by
> heaps. Gone is most of the spyware, trackware, and general junkware. Make
> Noscript style controls standard built in.

What does NoScript break?  We need documentation on this, and maybe some 
changes to defaults of OS installs.

Does Firefox have a "managed mode" like Chrome/Chromium/Edge do so you can set 
a file in /etc to force install of extensions without the user being bothered?

Building this in to web browsers would be worthy of a trophy.

> Firefox writes millions of little status updates to disk. The latest Firefox
> is unusable on a microSD card as a result. Switching to an SSD makes it
> just usable. There is a setting to reduce writes but it is hidden. Make it
> a standard click setting and the default for anything not running from
> NVMe.

Sounds like a great idea, could we do this at package install time?  Could we 
have a distribution package named optimise-slow-storage to change the config 
of Firefox etc in this regard?

> Ok, no need for $20. Buy me a coffee. They are almost $20 now. :-)

;)

> #2 Replacing some utilities with C or Rust versions would help. I use a C
> framework style library to make the replacement easier.

Are there any frequently used utilities in slower language that are 
bottlenecks?

Also we should just stop using some of the older programs.  gzip for example 
makes no sense nowadays, for almost any data you have you can find another 
compression algorithm that is faster and better, a lot faster, or a lot 
better.

> #3 Take the junk out of GTK to make it perform. That would make many program
> upgrades easy.

Sounds like a good thing to do.  I don't know enough about GTK to know if it's 
actually bad or just has the usual level of overhead due to developers not 
needing to optimise for RAM in most cases.  But going through the main large 
software stacks and looking for commonly used code that can be slightly 
reduced could give some real benefits.  If you have 1000 graphical controls 
and save a few words on each that could potentially improve cache efficiency 
on some critical paths.

> My 16 GB machine easily handles a file cache for my 2 TB disks. Some of my 4
> TB disks blow out the cache. 64 GB would be nice.

What cache are you using?

-- 
My Main Blog         http://etbe.coker.com.au/
My Documents Blog    http://doc.coker.com.au/