I guess the way of thinking about crashes/bugs has changed.
It used to be, garbage in, garbage out. "Sure, it crashed because you gave it a corrupted file; don't do that".
Then it was about making software robust. "Let's try not to crash with corrupted files".
Then it was about making software secure. "Files may actually be malicious, from the internet".
People these days basically make it a sport of finding vulnerabilities based on random memory safety bugs.
Interactive version of Euclid's Elements - Byrne's Euclid: https://www.c82.net/euclid/
Making Of: https://www.c82.net/blog/?id=79
This explanation of the the CVE in Skia's rasterizer is fascinating: https://googleprojectzero.blogspot.com/2019/02/the-curious-case-of-convexity-confusion.html
At first sight this sounds like a terrible idea, but in fact there's peer reviewed research on measuring the security-usability tradeoff in correcting password typos, and it turns out it makes a lot of sense to do this. https://www.cs.cornell.edu/~rahul/papers/pwtypos.pdf
Screenshot HT @amunchbach
Brasero, a CD/DVD writer app, is unmaintained but still widely used. Would you like to maintain it? https://gitlab.gnome.org/GNOME/brasero
Librsvg's GObject boilerplate is in #rustlang now - https://people.gnome.org/~federico/blog/librsvg-gobject-in-rust.html
This is rather momentous... librsvg no longer has GObject boilerplate in C; it's all in #rustlang now - https://gitlab.gnome.org/federico/librsvg/blob/subclass/rsvg_internals/src/c_api.rs
This branch is not merged into master yet, because it needs glib-rs to have a new release with @slomo's subclassing code.
Anti-pattern: tolerating bad behvior from people who make important contributions to a project.
It has a tendency to drive away other contributors,, even before their first contribution. Or long-time contributors.
If you let such a situation happen, it can be quite painful to fix it.
I'm partly to blame for Debian being in this situation. I joined Debian as a deveoper in 1996, and have only in recent years realised that we let it become a toxic environment.
If you really want to help Firefox succeed, file a bug on https://webcompat.com/ when you find a broken website. Don't just switch back to Chrome; let Mozilla know there's a problem so they can try to fix it.
When browsers lose market share, they fall into the "compatibility death spiral." Sites don't bother to test, they break, and users flee to the browser that "just works." Mozilla is fighting this battle every day, and it just got harder.
My GUADEC 2018 presentation - how did I forget to post this?
Patterns of refactoring C to Rust - the case of librsvg. https://people.gnome.org/~federico/blog/guadec-2018-presentation.html
EFF is resigning from the w3c over DRM and the Encrypted Media Extensions standardization process. This was probably inevitable once w3c leadership abandoned consensus in this arena, but it's still such a bummer to see https://www.eff.org/deeplinks/2017/09/open-letter-w3c-director-ceo-team-and-membership
How glib-rs works, part 3: Boxed types - https://people.gnome.org/~federico/blog/how-glib-rs-works-part-3.html
I had missed Gicmo's blog post on Emacs and the Rust Language Server: https://christian.kellner.me/2017/05/31/language-server-protocol-lsp-rust-and-emacs/
Interesting that https://github.com/KDE/rust-qt-binding-generator - the Rust Qt binding generator - has you write an API definition in JSON (not unlike .gir), and then it spits .rs files, into one of which you write your implementation, and the rest is boilerplate.
Then, the compiled Rust can be used from C++.
Gnome-class has a different approach - using procedural macros to extend the Rust syntax, to generate GObject ABI.
We could then generate .gir from that, or directly from the procedural macros.
On the internet, everyone knows you're a cat — and that's totally okay.