Slashdot Mirror
Firefox 49 Postponed One Week Due To Unexpected Bugs (softpedia.com)
An anonymous Slashdot reader quotes Softpedia:
Mozilla has announced this week that it is delaying the release of Firefox 49 for one week to address two unexpected bugs. Firefox 49, which was set for release on Tuesday, September 13, will now launch the following Tuesday, on September 20...
Firefox 49 is an important release in Mozilla's grand scheme of things when it comes to Firefox. This is the version when Mozilla will finish multi-process support rollout (a.k.a. e10s, or Electrolysis), and the version when Firefox launches the new WebExtensions API that replaces the old Add-ons API, making Firefox compatible with Chromium extensions.
Firefox's release manager explained the delays as "two blocking issues and the need for a bit more time to evaluate the results of their fixes/backouts" -- one of which apparently involves opening Giphy GIFS on Twitter.
Firefox's release manager explained the delays as "two blocking issues and the need for a bit more time to evaluate the results of their fixes/backouts" -- one of which apparently involves opening Giphy GIFS on Twitter.
Go to about:config and set:
keyword.enabled false
browser.fixup.alternate.enabled false
browser.fixup.dns_first_for_single_words true
Enjoy!
It's also a massive security problem, having no security model.
LMAO. Pretty much all Chrome extensions require access to "all websites" and your "entire browser history" which means they can gather all your browser information, including keystrokes, aka passwords.
So much security, my ass.
Are least Chrome HAS a permission system. That's only part of it though. Chrome extensions run in a sandbox. Firefox extensions run in the main browser process and can patch in to pretty much any of the UI and core features.
Also, you exaggerate, most of the extensions I use don't need access to all sites, and the ones that do are justified (e.g. uBlock and Privacy Badger).
const int one = 65536; (Silvermoon, Texture.cs)
SJW, n: "Someone I don't like, and by the way I'm a fuckwit" - AC
Yeah, systemd is *really* successful. As long as you define successful as "ruining your init system by replacing it with a pile of stinking crap".
Mine is at 0%. If Firefox (or Chrome, because it does it too) is burning CPU cycles it is the fault of a browser tab, I've seen a few sites that regularly cause issues if they're open for an extended period of time. Interestingly on Linux this seems more likely to occur than on Windows.
So what are you supposed to do remove drives that are not essential for your server to start from fstab and manually mount them once the server has booted maybe not init any services that will be using those drives either....
If you use the correct fstab options for these drives you can do various things including deferring the mount, giving the mount a certain time to complete, or just ignoring any failures. This: https://wiki.archlinux.org/index.php/fstab is very helpful.
The simplest change is to just add 'nofail' to all non-essential drives, but this will wait 90s for the drive to be available before continuing without it. This would probably be fine for cases where you *usually* expect the drive to be available.
systemd is probably just doing what should have been done in the past - treating fstab automount entries as 'required' by default.
It's arguable as to whether systemd should have started enforcing this or not, but it's also arguable that once the fstab has been changed to indicate which entries are/are not essential the system is more robust.