But why was it crashing? Linux automatically extends the stack and we had reserved more than enough space, something that we confirmed by looking at the memory map of the affected processes.
Well it turns out that the Linux kernel used to have a check that prevented stack accesses that were too far from the stack pointer. Specifically accesses 64KiB + 256 bytes away would crash instead of extending the stack.
On Monday morning we (Mozilla) detected a very large crash spike affecting #Firefox users on Linux, specifically on an older version of a Debian-based distribution.
It turned out to be an interesting bug involving the #Linux kernel and #Google JavaScript code so let me tell you about it.
The crash started apparently out-of-the-blue, hitting thousands of Argentinian users on a Debian-based distro called Huayra, and specifically on version 5 which was based on Debian 10.
Everybody seemed to crash while searching for images on Google. All versions of Firefox - even very old ones - were affected suggesting that the change didn't happen on our side, but on Google's. 2/6
A colleague analyzed Firefox' behavior at the point of crash and realized that it happened during stack probing. The JIT touched the area that would hold the variables for the next JavaScript call and somehow hit an overflow.
This is where things got weird, Google's code was allocating 20000 variables in a single frame. Ouch, that's probably some machine-generated code which went out of hand. Think twice before using ChatGPT to write code. 3/6
Wherever I look I can see news about a few very rich individuals being stranded on a submarine that was supposed to take them on a tour of the Titanic. The effort put in place to rescue them appears huge in scope.
Last week over six hundred people died in a #shripweck off the coasts of #Greece and nobody cared. Nobody even bothered to start a rescue operation until it was too late.
Stop pretending people are equal, I hate this hypocrisy.
Silvio Berlusconi just died. During his life he caused immense damage to both Italy and the EU.
For decades he used his media empire to propagate a culture of sexism, racism and utter disregard for culture and science. He facilitated organized crime and helped Putin gain a foothold within the EU both politically and financially.
Even though he was already waning politically after the 2012 crisis, the damage he has done within Italian society will take decades to undo.
@mdhughes I highly recommend checking out Spicediver's fan-edit of Lynch's movie that uses cut scenes and generally a different edit to get it much more in line with the book (at least story-wise) https://www.youtube.com/watch?v=vJykw3H4PDw
Anyway I agree with the sentiment. Villeneuve took at least as many liberties as Lynch changing the story compared to the book, but the esthetics of his movies are extremely bland, and so is the score. Plus a lot of characters end up being completely flat (e.g. Piter De Vries)
Let's start with the first promise for application developers: you can make a single package that will work on all Linux distros! The irony of having two competings standards isn't lost on me, we're basically in the scenario of the ages old XKCD joke and I'm waiting for yet another format to come out. More importantly both have corporate backers that will never reconcile on a single format, so no, you can't make a single package even if you'd like to. 2/14
Last week I dunked on #Snap and #Flatpak because I think both formats are more trouble than they're worth, so here's a short thread where I actually make a few arguments against both.
This will largely address why the theoretical benefits of both formats just don't hold up in practice. That is the ability to make a single package that will work across all #Linux distributions, and a safe sandbox for the user to run untrusted applications in. ? 1/14
That's even more true for enterprise deployments. I don't know how Snap/Flatpak interact with automation tools but I'm positive no IT department enjoys having to deal with two different package managers when one would suffice. Enterprise deployments are entirely single-distro so there's literally no use for Snap/Flatpak in that area. Even internally developed applications are better deployed using the default package manager. 6/14
And that's not even taking into account that - as a devevloper - you still need to make a regular package or binary distribution because some users won't install Snap/Flatpak. So it's actually better to make your software easy to package - so that distros will actually pick it up - rather than spend resources on Snap/Flatpak. 5/14
Here's a very non-scientific idea of how much users love using a separate package manager: one of the most common questions from Ubuntu users in Mozilla support forums is how to get rid of the Snap-packaged version and install the .deb-based one. 4/14
Which leads us to the second issue: whatever distro you use has already a package manager! So your users now need a second one if they want to use your application, how fun is that? Many distros don't ship Snap/Flatpack by default, but even for those which do - like Ubuntu - what if you're using the other format? Do you really expect users to have three different package managers installed? 3/14
And here's the thing: the sandbox behavior must be programmed to allow the application to behave normally. So it's only as safe as the holes that were punched into it via configuration and prompts. And here's the thing: we've already got something like that for trusted applications: it's SELinux! So why you - as a developer - would want to deal with a second sandbox given that there's already a very popular way of curtailing application behavior? 8/14
Now let's switch to the second aspect: the sandbox. In theory it makes things safer for the user, especially when dealing with untrusted data or the network. However that's only true as far as the application's normal behavior is safe, because the sandbox can't curtail some aspects of it without making the application useless (preventing access to your home directory won't do wonders even for an application that only manipulates local files). 7/14
Last but not least, maybe you're really worried about your local applications being compromised by a motivated, well funded attacker. If you are then I don't think the Snap/Flatpak sandbox can do much for you. If you really need tight isolation between apps something like Qubes OS is a much better idea, and probably safer. 9/14
That's true even of things like downloading binary applications from the internet. There are some though not many - Steam/GoG games for example - but they're not pre-packaged, so Snap/Flatpak brings no benefits for these either unless the users write their own packages which sounds improbable. 10/14
And what about the developers? Applications will behave differently inside and outside of the sandbox, and will behave differently on Snap vs Flatpak. So now something might break, users will come to you - the developer - for a fix and you'll have to ask yourself if it's a genuine bug, a bug in the packaging or a bug in the sandbox (we've encountered *plenty* of those with #Firefox). 12/14
There's two more things I didn't go over: disadvantages for users and developers.
The sandbox and compatibility layers aren't free, they have drawbacks: larger downloads size, larger storage required on disk, higher memory usage, lower performance and bugs that don't happen in the non-Snap/Flatpak version. Way to go. 11/14