well, in my opinion it is a bit of a paradox. i think you are partially correct.
your door analogy may be right from the perspective of the platform on which the cube is. however, one flaw is that the whole space is moving, not just the door. as soon as the cube enters that door, it will be inside that space, and if you consider the cube part of it, moving that space “downward”, then due the cube being held by the platform, you could consider the cube moving “upward” in the space behind the orange portal. if you consider preserving momentum there, then as soon as the apparatus stops moving, the cube should not stop its momentum and move further up in the space.
or look at it like this: if you are behind the orange portal, meaning you are looking at the blue portal, you will see a cube moving towards you. then as soon as the platform hits the wall of the orange portal, the preserved momentum should make the cube “fly”.
the change of perspective leads to two different conclusions, therefore i think it is a paradox.
the problem sort of is that there are two “spacetimes” that are kind of being changed. one could interpret it as both of these effects “pulling” against each other since when the cube has partially passed the portal, one part of the cube is “in one of the spacetimes”, ant the other part in the other. ultimately though, the cube then would actually fly because in the limit (infinitesinally close to when the platform hits the portal wall) the cube is completely on the other side of the portal, so from the view of that spacetime, the cube does get pushed and should fly.
i don’t even remember if it is possible in the video game for walls with portals that move. a video game would probablt have some kind of “center of mass”, like a single vector of coordinates where describing the position of the object. there is no notion of “partially” being somewhere (except for collision boxes, but i don’t mean that). so also from that view the box would fly. however, in most video games (with or without portals), if a platform moves up and suddenly stops, the object won’t travel further in that direction anyway, especially not ulwards (even sideways usually not).
Which Firefox fork is a hard fork? Which Firefox fork has a hard fork of the Gecko engine?
As far as I know, all Firefox forks are dependent on the Gecko engine, and basically have Firefox as upstream.
I would love for you to prove me wrong, but I don’t believe any of these projects, though with many highly dedicated contributors, would be able to maintain active development of a web browser engine that can keep up with new modern web standards.
There is a reason the Ladybird project is taking so long to materialize and has many sponsors giving significant amounts of money.
Internet shit is hard. Firefox and their forks only work because Mozilla is fucking huge and has money to develop Firefox as part of the three big industry standard web browsers. Even though Mozilla does a lot of stupid decisions and spends the majority of their money on dumb shit, and they put dumb shit into the default Firefox that they ship, it is still excellent in many ways and the very best thing we have as a FOSS web browser. I encourage everyone to use Firefox with hardening or one its forks.
I agree with the article, and people saying “Yeah let’s boycott Firefox, use [insert Firefox fork here]” every time there is a Lemmy post on a stupid decision by Mozilla are effectively not boycotting Firefox at all, or if they recommend a Chromium fork they are supporting Chrome/Google, even if they don’t think they are. These forks are in essence just preconfigured and hardened Firefox/Chromium profiles with a few bells and whistles here and there.