yep, definitely. i just thought "hey wouldn't it be funny if two dudes just ate some undefined substance because it's cheap" and, uhhh, yeah
i genuinely love it when people make their own meaning about shit i make sleep deprived out my mind because i thought of a funny word
Am I understanding right that this has a low percentage chance of triggering on every tick
yes!
but will release a bunch of angry Enderman when it finally does?
no. you'll get teleported to where the enter pearl is and the potions will be shot towards you, killing you instantly.
tallarico's really outdone himself this time
They aren't forced to do anything. Manifest v3 is just a part of the WebExtensions API (which is not a standard and is really just "whatever Chrome does except we find/replace'd the word chrome to browser") which both Safari and Firefox chose to implement in order to make porting of Chrome extensions easier.
Before that, Firefox had a much more powerful extension system that allowed extensions quite a lot of access to browser internals, but that turned out to be a maintenance nightmare so they walled those APIs off (not a coincidence that Firefox started getting massive performance improvements after that, and extensions stopped breaking every other release) and decided to go the WebExtensions route. I have no clue what Safari was up to but I think they implemented it after.
If they don't implement Manifest v3, extensions that want to work across multiple browsers need to support both the older Manifest v2 and the later Manifest v3, which would be a burden not many extension authors would want to bother with, which would make them just say "yeah we're not supporting anything outside Chrome". Firefox avoids this problem by extending the v3 API to allow for the functionality necessary for powerful ad blocking Google removed in v3 (webRequestBlocking) while also implementing the new thing (declarativeNetRequest) side by side, so extensions that want to take advantage of the powerful features on Firefox can do so, while Chrome extensions that are fine with the less powerful alternative can still be ported over relatively easily.
Firefox does have it's fair share of extensions on top of the WebExtension API already (sidebar support for one), so adding one more isn't too big of a deal.
TLDR of linked gist: wayland is not X therefore it is bad. end of.
Wayland breaks Xclip: As you said it yourself, Xclip is an X11 application, so it doesn’t work on Wayland. Of course it wouldn’t work on Wayland. With Wayland, we’re trying to prevent what happened with Xorg from happening again, or am I wrong?
also, https://github.com/bugaevc/wl-clipboard. perhaps all OP (of gist) needs is a simple shim that can convert calls to xclip to wl-copy/paste? that doesn't seem too hard to make compared to keeping X.org alive I'd say (perhaps they should try making it if it's that much of a problem)
Wayland breaks screensavers: Yeah, that seems to be the case.
from the dev of xscreensaver at https://www.jwz.org/blog/2023/09/wayland-and-screen-savers/ :
[...] Adding screen savers to Wayland is not simply a matter of "port the XScreenSaver daemon", because under the Wayland model, screen blanking and locking should not be a third-party user-space app; much of the logic must be embedded into the display manager itself. This is a good thing! It is a better model than what we have under X11. [...]
[...] Under X11, you run XScreenSaver, which is a user-space program that tries really hard to keep the screen locked and never crash. It is very good at this, but that it needs to try so hard in the first place is a fundamental design flaw of X11. [...]
other people can comment on the parts they know about, these are two i know of off the top of my head
as far as i can tell this particular image is fake. and as far as i know pluton does not work like that.
Security? Probably. I wouldn't expect any measurable improvements to performance but the with compiler being able to do more checks it might enable some clever optimization trickery that would be harder to maintain in C.
Still, Rust on the kernel probably won't leave the realm of drivers any time soon, so it all depends on if you have the hardware that will use a driver written in Rust.
A popular misconception is that Firefox runs Gecko. And while that is kinda true, the real problem is much more interesting when you come down to the technical details.
Because it's the other way around. Firefox doesn't run Gecko, Gecko runs Firefox. Firefox is built in Gecko. In a similar vein, Thunderbird also runs inside Gecko. It's why they look so similar despite one being a browser and the other being an email client. Gecko is, in a way, a proto-Electron.
You cannot "rip off" Gecko from Firefox and embed it inside something like you can do with Blink/Chromium (unless you're on Android and use GeckoView), which means the only way to have a "Firefox based browser" is to fork the entirety of Firefox. There are forks like the TBB or Librewolf that do this, but the embeddability of Chromium makes it much easier for devs to make something that diverges from Chromium in major ways (stuff like Qutebrowser, for example)
the 4 horseman of the apocalypse (when you know you need to reformat):
- sfc /scannow
- dism /online /cleanup-image /checkhealth
- run the troubleshooting tool
- install KB069420 from dead link
at least on linux we get to tailor our useless terminal commands to your specific problem before telling you to fuck off
sorry i just had to