@gabrielesvelto@fosstodon.org

Gabriele Svelto [moved] @gabrielesvelto@fosstodon.org

· 16mo ago

I moved all the articles I saved in Pocket to a self-hosted @readeck@mastodon.online installation and I'm really satisfied with the result. Readeck has the most useful functionality Pocket lost in the last few years and is very pleasant to use.

If I find some free time I'll whip my #Gentoo ebuild into shape and contribute it to the guru package repository.

fosstodon.org

28

1

6

0

Gabriele Svelto [moved] @gabrielesvelto@fosstodon.org

· 30mo ago

Rewatching Mary Poppins with my kids and I feel rather seen

21

0

4

0

Gabriele Svelto [moved] @gabrielesvelto@fosstodon.org

· 43mo ago

Last week we fixed a 14 year old bug in #Firefox. It was a small thing, just a UI glitch in the crash reporter client, but it always feel good to close bugs that old.

Plus I didn't fix it myself, I walked a new contributor through her first patch. It's always nice when people want to help and I'm always delighted to see how happy they are about landing their very first patch in a #FOSS project.

fosstodon.org

Fosstodon

35

6

13

0

Gabriele Svelto [moved] @gabrielesvelto@fosstodon.org

· 28mo ago

Replying to

@mhoye ugh, that's one nasty footgun and "RTFM" is a really shitty response when the reporter politely and extensively explained that the description in the fine manual is quite confusing.

13

8

2

0

Gabriele Svelto [moved] @gabrielesvelto@fosstodon.org

· 28mo ago

Replying to

@mhoye I can relate to that. The old joke of the year of "Linux on the desktop" has devolved into how long until Linux on the desktop is gone because all the paid-for development is for enterprise-centric use-cases.

7

2

0

Gabriele Svelto [moved] @gabrielesvelto@fosstodon.org

· 19mo ago

Replying to

@OchmennoPodcast FYI @ChrisO_wiki is in the fedi and posts interesting stuff on the Russian invasion of Ukraine, though he posts a little less frequently on here than in other platforms. Go give him a follow, it's worth it

3

1

0

Gabriele Svelto [moved] @gabrielesvelto@fosstodon.org

· 32mo ago

Replying to

@nileane@nileane.fr "you can scrub as much harmful speech from your feed as you want, but only after having been thoroughly traumatized by it"

4

0

Gabriele Svelto [moved] @gabrielesvelto@fosstodon.org

· 47mo ago

Replying to

Google developers have noticed my blog post and are trying to retry failed allocations in #Chrome too: https://chromium-review.googlesource.com/c/chromium/src/+/4051183 The code is pretty much the same as ours but they check for two more failures: ERROR_COMMITMENT_MINIMUM and ERROR_PAGEFILE_QUOTA. I'm confident those are not needed because they appear in Microsoft documentation but never showed up in Firefox crash data. As they say: do as Microsoft does not as Microsoft says.

chromium-review.googlesource.com

Gerrit Code Review

6

0

Gabriele Svelto [moved] @gabrielesvelto@fosstodon.org

· 35mo ago

Replying to

@CatherineFlick@mastodon.me.uk but somehow trains still go chuff chuff

2

0

2

0

Gabriele Svelto [moved] @gabrielesvelto@fosstodon.org

· 30mo ago

Replying to

@BGOllie@mstdn.social fantastic 👏

1

0

Gabriele Svelto [moved] @gabrielesvelto@fosstodon.org

· 31mo ago

Replying to

@brendangregg@aus.social you might want to check the framehop and wholesym Rust crates developed by my colleague @mstange@mastodon.social They've been written to provide very high quality stack traces while also offering very high performance, so that they can be used during online profiling: https://crates.io/crates/framehop https://crates.io/crates/wholesym

crates.io

1

0

Gabriele Svelto [moved] @gabrielesvelto@fosstodon.org

· 31mo ago

Replying to

@brendangregg@aus.social we've spent considerable resources in terms of engineering at Mozilla to deal with the issue of stack traces, both for stability (crash reporting & diagnostics) and performance (profiling). Frame pointers are hugely helpful when present, but we also have to live without them since extensive inlining in C++/Rust code means they're just not enough.

1

2

0

Gabriele Svelto [moved] @gabrielesvelto@fosstodon.org

· 47mo ago

Replying to

@itamarst on Linux we use the oom_score_adj values of each process to direct the OOM killer towards the ones we want reaped first, see this bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1771712 Fun story: the original code to implement this was written for Firefox OS and I pulled it from the KaiOS branch which is a fork of Firefox OS but based on recent Firefox versions.

bugzilla.mozilla.org

1771712 - Set oom_score_adj in SetProcessPriority() on Linux to make it less likely for the main process to be killed under memory pressure

RESOLVED (gsvelto) in Core - Hardware Abstraction Layer (HAL). Last updated 2026-09-08.

2

3

0

Gabriele Svelto [moved] @gabrielesvelto@fosstodon.org

· 47mo ago

Replying to

@DePanther @cabanier I honestly don't know, you might try and ask on the Firefox on iOS channel on our Matrix server https://matrix.to/#/#fx-ios:mozilla.org

matrix.to

You're invited to talk on Matrix

1

0

Gabriele Svelto [moved] @gabrielesvelto@fosstodon.org

· 47mo ago

Replying to

@cabanier no, on Android we already have some dedicated machinery that tries to prevent visible processes from dying in front of the user when the phone is running out of memory. However Android's memory killer is a lot more aggressive than Linux and we only have marginal control over what it does. Part of the reason is that phones have no swap space and thus the kernel cannot overcommit, which is quite the issue for something that was designed for it.

1

2

1

0

Gabriele Svelto [moved] @gabrielesvelto@fosstodon.org

· 47mo ago

Replying to

@wanderview that is quite appropriate!

1

0

Gabriele Svelto [moved] @gabrielesvelto@fosstodon.org

· 47mo ago

Replying to

@plwt I'm happy you liked it! I feel that the ins and outs of Windows memory management are not very well known in the broader #FOSS community

1

0

Gabriele Svelto [moved] @gabrielesvelto@fosstodon.org

· 47mo ago

Replying to

@robryk that's a very good question! It provided small benefits compared to this, so we're repurposing it: we want to unload tabs when we're low on physical memory to prevent swapping. This way we'll have two distinct mechanisms, one to prevent crashes and one to improve responsiveness by avoiding swapping.

0

2

0

Gabriele Svelto [moved] @gabrielesvelto@fosstodon.org

· 47mo ago

Replying to

@robryk on Linux we don't look at system memory usage mostly because it's impossible to do in a reliable way. We're entirely in the hands of the OOM killer. To be precise we tried detecting global low-memory situations... and failed. Going forward this detection will only be based on Firefox own processes' dying and thus necessarily local to whatever cgroup it's been assigned to.

0

Gabriele Svelto [moved] @gabrielesvelto@fosstodon.org

· 47mo ago

Replying to

@itamarst you read my mind: yes we want to use that. Specifically we have pre-allocated child processes which are the first to die. They're empty processes we keep around to speed up loading a new page; the idea is to detect when they die and take that as a sign of memory running low. The problem is that we currently don't have a way to tell if a process was reaped by the OOM killer but @xlerb is working on it so... soon, probably!

0

1

0

Gabriele Svelto [moved] @gabrielesvelto@fosstodon.org

· 43mo ago

Replying to

@nnethercote@mas.to @flod@mozilla.social it is shocking, isn't it?

0

1

0

Gabriele Svelto [moved] @gabrielesvelto@fosstodon.org

· 18mo ago

Replying to

@nocontexttrek@mastodon.social this is our yearly reminder that transphobes have no honor

0