But with FF57, I've heard rumors (not verified, but troubling...) that the former privacy extensions that are being ported to 57 won't be able to offer as much privacy as before. For example, instead of blocking the fetch of various ad trackers, they have to fetch them but then not display them. The fetching is the part I want to block.
That is false. Their "new" (chrome-parroting) WebExtensions API is horrible, but stopping the "fetch" of any resource at any stage is quite easy. It's also trivial to selectively block inline scripts, css animations, etc. from an extension.
Because the stupidity of the google-heads who designed the API it's not easy to do those things/nicely/, but if you swallow your pride and accept cargo-cult programming and duplicating functionality as facts of life, you can get things working/somehow/. Of course, there are things that are no longer possible to do (eg replacing the whole body of a response from an extension).
And they're also very good at astroturfing and kool-aid drinking.
That is, they don't put up with bullshit. If you're going to contribute code, you will be held to a high standard.
If you want to contribute code, let's say a patch, expect it to be brutally rejected at first (and you to be harrassed and humiliated by non-contributing hordes of fanbois on mailing lists), and then committed with small changes by some senior developer with no credits whatsoever to its original author.
You should be happy enough that your code may end running on every hipster's MacOS, shouldn't you?
Also, expect atrociously stupid ideas (using xml to configure disk volumes? build a lua interpreter inside the kernel?) to sail through without much discussion, based on just who they came from.
Don't forget bitrig. From the very people that brough us scrotwm and xxxtem.
And there was yet another nasty guy with his own OpenBSD fork -- I forgot his name; all I remember of him is that he broke ksh so it no longer uses vi keys when VISUAL=vi is set (That alone would merit him some severe punishment).
and yet the changing the "crappy architecture" (XUL -> WebExtensions) is what people bitch about.
You're missing the bootstrapped extensions between XUL and WebExtensions, where you simply had to fill 4 callbacks to be run when starting and shutting down the browser, and when installing and uninstalling the extension.
Nothing was presumed about inner architecture of the browser, or the way you choose to structure your extension. They killed that because of politics and policy, not because of any technical reasons.
Besides, the new WebExtension api is not only badly designed, is also HUGE, a big blob of shit taking space in your browser (just like the java goo wasting your phone's battery with no good reason). A huge pile of garbage they will have to kludge around in the future, no better than the XUL/XPCOM monstrosity.
You have no clue what you're talking about. Your verbiage sounds looks like common sense, but it has no technical basis.
Every abuse that was practical with old-style legacy/bootstrapped extensions in firefox is also possible with new, chrome style "webextensions".
Content scripts do interact with random stuff from the page you visit (broken HTML, etc), are NOT undetectable to malicious scripts on the page (because they share the same DOM), and because they have to communicate with the "privileged mode" part of an extension (in order to be able to do anything useful), they offer a easy backdoor into the browser -- unless they're written by security geniuses with a perfect grasp of the millions of javascript pitfalls.
What they don't offer is the ability to change that horrible interface (an extension can no longer build some emacs-like split window interface, or a less-like "command line" at the bottom of the page), or overcome the abject stupidity of bored (paid) developers who designed the APIs we codemonkeys are supposed to use (you're no longer able to get stuff done by using undocumented interfaces they're using in their bundled extensions, eg. developer tools).
Firefox developers vs extensions slowing them down are like a crow thinking it could fly much faster if it hadn't to overcome that pesky air drag.
With the new API, it's impossible to do obvious things you would like to do in an add-on, like creating a side-panel, or adding an extra menu item.
Also, there's no way to step through an animated image, other than doing something very shitty and complicated, like setting a timer to repeatedly render it on a canvas.
There's no way to stop animated favicons in tab titles or history menus at all;-)
There is no way to enumerate all listeners registered on an element.
There's also no way to replace the whole data of an HTTP response, other than by redirecting it -- which is not transparent, and would fail with the very pages where such a thing would be useful.
And these are things I tried to do in my silly, ~1.2k lines, own-use extension. I can only image the pain and disgust of the people that have invested their time in writing and maintaining a real extensions, with real users.
Since they killed the old interface and with it the "CityBlock" flash viewer, their stuff is only usable on high-end computers, and even there, the user experience is much worse than with the old viewer.
Webgl and all the newfangled javascript stuff are supposed to be better and faster than flash, what went wrong with it? What features does the typescript interface in flash offer that are not available with modern browsers in javascript + webgl? Or is it just a matter of new. less skilled programmers trying to do something different?
Also, they offer no access to older street view images (which have historical value), and for much of US, there are only low-resolution images from 10 years ago.
In fact, I've seen it take a minute or two to get a lock, and even then it keeps chatting with the satellites to narrow down your location.
That was years ago. Most recent android phones take at most 10 sec to get a lock. It helps if the case is not made of metal.
It's not like the old Nokia N810, which needed half an hour to get a lock (and after two or three times wasn't able to get a lock at all, unless you flushed the corrupted almanach data file and killed the gps driver daemon).
Also, it doesn't "chat" with the satellites. The GPS radio on a phone is purely a receiver, like the FM module.
Because you are not receiving 'a GPS signal'. You are receiving a multitude of GPS and GLONASS signals. From the time stamps and positional information encoded in these signals you then have to calculate your position.
Those calculations couldn't be that expensive. Besides, they're probably mostly hardware accelerated.
With the cellular + wifi radios turned off ("aircraft mode") and the gps radio turned on (with a gps tracking app collecting all nmea data and gzip-compressing it into a file) AND occasional use of a mapping map (written with OpenLayers in javascript and pulling data from a local http server), my cheap chinese phone is able to hold a charge for ~2days.
I've never used an iPhone, but it's probably the google maps app which is doing something seriously fucked up (track and collect info about cellular towers and wifi hotspots and send it to google?).
I know you're trying to be funny, but for those who don't know it, setuid executables have been deprecated since a while. $ ls -l/bin/ping -rwxr-xr-x 1 root root 44104 Nov 8 2014/bin/ping
See? No setuid bit, and still able to mess with raw packets.
The old setuid thing has been replaced with granular capabilities(7) bits, which are stored in a "security.capability" extended attribute. $ getcap/bin/ping/bin/ping = cap_net_raw+ep
man operator(7) and get rid of all those cock-sucking parentheses.
They clutter your mind and if your brain isn't able to cope with simple levels of precendence, you're worthless even as a janitor; and indenting is not the cure for your disease.
You won't be able to grasp the difference between 'or' and 'and' even with copious whitespace, syntax highlighting.and blinking.
No, it's not obvious. The person in question may change "their" gender in the future, and then the editors will have to either modify the article (rewriting the history in a 1984-like manner) or to face accusations of bigotry and disrespect.
I know of al least one free software project whose leader had a sex reassignment surgery, and of a well known microprocessor designed by a female-born-male, so that may more common than most people think.
If you are unable or unwilling to rebuild a browser from source, you've come to the wrong Web-site...
No shit.
disabling an option is usually a prelude to removing it completely
It is not disabled. It was turned off by default — because it is useless for most users, as TFA mentions. Lots of other options are off by default — such as --with-system- foo:
Have you tested all the possible combinations of those '--enable-*' and '--with-*' options? Any configuration that is not tested and not supported is living on borrowed time.
What do you think will happen when they "accidentally" break the --enable-alsa?
Nobody building firefox for reasons other than purely masturbatory will ever bother to use an unsupported config for such a bloated, fragile and messy piece of shit.
I can get rid of my wrapper script that starts/usr/bin/awful_pos (renamed so that nothing can find/usr/bin/pulseaudio)
no need of any wrapper script, pulseaudio can be started/stopped on demand.
I had to do this shit just because of firefox, when testing some app on their 'current' branch (which has stopped supporting alsa a year or so ago). $ cat ~/.config/pulse/client.conf # Applications that uses PulseAudio *directly* will spawn it, # use it, and pulse will exit itself when done because of the # exit-idle-time setting in daemon.conf autospawn = yes $ cat ~/.config/pulse/daemon.conf exit-idle-time = 0 # Exit as soon as unneeded flat-volumes = yes # Prevent messing with the master volume
Incorrect. You need to go back to school and review what divide by zero actually means.
However Javascript uses the broken IEEE 754 definition of x/0 = Infinity. This is is retarded because is broken math
Thanks for proving my point. In other words, javascript is buggy because it's using industry standard floating point, instead of some "ideal" real numbers (which couldn't be represented on any actual or theoretical computer, anyway).
Your mistake is assuming Javascript has integers in the first place. Javascript does NOT have signed integers. All values are 64-bit floating point values.
Yes it has. The bitwise operators first convert their operands to a 32bit signed integers, and then return a 32bit signed integer. Look here and here. This is similar to how arithmetic ops first convert their arguments to double, string ops first convert them to strings, etc -- the way that all typeless/dynamic languages work.
If we're down to sending each back to school, I'll give you a smart student question that will earn you extra points: why isn't javascript using 64bit signed integers there?
But what do you expect from a language designed in 10 days.
I'll expect to use IEEE 754 floating point and 2s complement integers like everybody else.
Returns broken 16331239353195370, instead of correct NaN
That's how floating point doubles work in any language. And besides, why should that be NaN? 1/0 is Infinity, not NaN.
console.log( 123456789 << 5 );
Returns broken -344350048 instead of correct 3950617248
That's how 2s complement 32 bit integers work in any language. Is there some standard that says that "big" signed integers should be surreptitiously changed into unsigned ones? Or that javascript should use 64bit longs?
Don't even get me started on the retarded ASI (Automatic Semi-colon Insertion).
Slashdot Mirror
That is false. Their "new" (chrome-parroting) WebExtensions API is horrible, but stopping the "fetch" of any resource at any stage is quite easy. It's also trivial to selectively block inline scripts, css animations, etc. from an extension.
Because the stupidity of the google-heads who designed the API it's not easy to do those things /nicely/, but if you swallow your pride and accept cargo-cult programming and duplicating functionality as facts of life, you can get things working /somehow/. Of course, there are things that are no longer possible to do (eg replacing the whole body of a response from an extension).
I'm not sure that kind of irony works as intended; I know plenty of cocksuckers that seriously think this is how things should work.
And they're also very good at astroturfing and kool-aid drinking.
If you want to contribute code, let's say a patch, expect it to be brutally rejected at first (and you to be harrassed and humiliated by non-contributing hordes of fanbois on mailing lists), and then committed with small changes by some senior developer with no credits whatsoever to its original author.
You should be happy enough that your code may end running on every hipster's MacOS, shouldn't you?
Also, expect atrociously stupid ideas (using xml to configure disk volumes? build a lua interpreter inside the kernel?) to sail through without much discussion, based on just who they came from.
Don't forget bitrig. From the very people that brough us scrotwm and xxxtem.
And there was yet another nasty guy with his own OpenBSD fork -- I forgot his name; all I remember of him is that he broke ksh so it no longer uses vi keys when VISUAL=vi is set (That alone would merit him some severe punishment).
You're missing the bootstrapped extensions between XUL and WebExtensions, where you simply had to fill 4 callbacks to be run when starting and shutting down the browser, and when installing and uninstalling the extension.
Nothing was presumed about inner architecture of the browser, or the way you choose to structure your extension. They killed that because of politics and policy, not because of any technical reasons.
Besides, the new WebExtension api is not only badly designed, is also HUGE, a big blob of shit taking space in your browser (just like the java goo wasting your phone's battery with no good reason). A huge pile of garbage they will have to kludge around in the future, no better than the XUL/XPCOM monstrosity.
Because of the highly evocative power of phrases like "highly parallel complex datastructures".
Don't they ever have any mercy?
You have no clue what you're talking about. Your verbiage sounds looks like common sense, but it has no technical basis.
Every abuse that was practical with old-style legacy/bootstrapped extensions in firefox is also possible with new, chrome style "webextensions".
Content scripts do interact with random stuff from the page you visit (broken HTML, etc), are NOT undetectable to malicious scripts on the page (because they share the same DOM), and because they have to communicate with the "privileged mode" part of an extension (in order to be able to do anything useful), they offer a easy backdoor into the browser -- unless they're written by security geniuses with a perfect grasp of the millions of javascript pitfalls.
What they don't offer is the ability to change that horrible interface (an extension can no longer build some emacs-like split window interface, or a less-like "command line" at the bottom of the page), or overcome the abject stupidity of bored (paid) developers who designed the APIs we codemonkeys are supposed to use (you're no longer able to get stuff done by using undocumented interfaces they're using in their bundled extensions, eg. developer tools).
Firefox developers vs extensions slowing them down are like a crow thinking it could fly much faster if it hadn't to overcome that pesky air drag.
Yes.
With the new API, it's impossible to do obvious things you would like to do in an add-on, like creating a side-panel, or adding an extra menu item.
Also, there's no way to step through an animated image, other than doing something very shitty and complicated, like setting a timer to repeatedly render it on a canvas.
There's no way to stop animated favicons in tab titles or history menus at all ;-)
There is no way to enumerate all listeners registered on an element.
There's also no way to replace the whole data of an HTTP response, other than by redirecting it -- which is not transparent, and would fail with the very pages where such a thing would be useful.
And these are things I tried to do in my silly, ~1.2k lines, own-use extension. I can only image the pain and disgust of the people that have invested their time in writing and maintaining a real extensions, with real users.
Since they killed the old interface and with it the "CityBlock" flash viewer, their stuff is only usable on high-end computers, and even there, the user experience is much worse than with the old viewer.
Webgl and all the newfangled javascript stuff are supposed to be better and faster than flash, what went wrong with it? What features does the typescript interface in flash offer that are not available with modern browsers in javascript + webgl? Or is it just a matter of new. less skilled programmers trying to do something different?
Also, they offer no access to older street view images (which have historical value), and for much of US, there are only low-resolution images from 10 years ago.
That was years ago. Most recent android phones take at most 10 sec to get a lock. It helps if the case is not made of metal.
It's not like the old Nokia N810, which needed half an hour to get a lock (and after two or three times wasn't able to get a lock at all, unless you flushed the corrupted almanach data file and killed the gps driver daemon).
Also, it doesn't "chat" with the satellites. The GPS radio on a phone is purely a receiver, like the FM module.
Those calculations couldn't be that expensive. Besides, they're probably mostly hardware accelerated.
With the cellular + wifi radios turned off ("aircraft mode") and the gps radio turned on (with a gps tracking app collecting all nmea data and gzip-compressing it into a file) AND occasional use of a mapping map (written with OpenLayers in javascript and pulling data from a local http server), my cheap chinese phone is able to hold a charge for ~2days.
I've never used an iPhone, but it's probably the google maps app which is doing something seriously fucked up (track and collect info about cellular towers and wifi hotspots and send it to google?).
I know you're trying to be funny, but for those who don't know it, setuid executables have been deprecated since a while.
/bin/ping /bin/ping
$ ls -l
-rwxr-xr-x 1 root root 44104 Nov 8 2014
See? No setuid bit, and still able to mess with raw packets.
The old setuid thing has been replaced with granular capabilities(7) bits, which are stored in a "security.capability" extended attribute.
/bin/ping /bin/ping = cap_net_raw+ep
$ getcap
man operator(7) and get rid of all those cock-sucking parentheses.
They clutter your mind and if your brain isn't able to cope with simple levels of precendence, you're worthless even as a janitor; and indenting is not the cure for your disease.
You won't be able to grasp the difference between 'or' and 'and' even with copious whitespace, syntax highlighting.and blinking.
There never was such a point. Lynx was never very popular. You're probably thinking of mosaic, of which early IE was a fork.
Get them to brush their teeth after they eat, not before they go to school.
I'm not saying that would be easier, but at least try something that /may/ make sense before reaching conclusions.
In C99, the main() function doesn't need any return statement. See 5.1.2.3:
reaching the } that terminates the main function returns a value of 0.
No, it's not obvious. The person in question may change "their" gender in the future, and then the editors will have to either modify the article (rewriting the history in a 1984-like manner) or to face accusations of bigotry and disrespect.
I know of al least one free software project whose leader had a sex reassignment surgery, and of a well known microprocessor designed by a female-born-male, so that may more common than most people think.
No shit.
Have you tested all the possible combinations of those '--enable-*' and '--with-*' options? Any configuration that is not tested and not supported is living on borrowed time.
What do you think will happen when they "accidentally" break the --enable-alsa?
Nobody building firefox for reasons other than purely masturbatory will ever bother to use an unsupported config for such a bloated, fragile and messy piece of shit.
life is too short to spend it building firefox.
and disabling an option is usually a prelude to removing it completely.
no need of any wrapper script, pulseaudio can be started/stopped on demand.
I had to do this shit just because of firefox, when testing some app on their 'current' branch (which has stopped supporting alsa a year or so ago).
$ cat ~/.config/pulse/client.conf
# Applications that uses PulseAudio *directly* will spawn it,
# use it, and pulse will exit itself when done because of the
# exit-idle-time setting in daemon.conf
autospawn = yes
$ cat ~/.config/pulse/daemon.conf
exit-idle-time = 0 # Exit as soon as unneeded
flat-volumes = yes # Prevent messing with the master volume
FWIW, sharia courts are actually run and backed by the state in Israel.
BTW, look at what you did there. Infinity is not a number, so multiplying it has no meaning. Your whole "proof" is bogus.
Thanks for proving my point. In other words, javascript is buggy because it's using industry standard floating point, instead of some "ideal" real numbers (which couldn't be represented on any actual or theoretical computer, anyway).
Yes it has. The bitwise operators first convert their operands to a 32bit signed integers, and then return a 32bit signed integer. Look here and here. This is similar to how arithmetic ops first convert their arguments to double, string ops first convert them to strings, etc -- the way that all typeless/dynamic languages work.
If we're down to sending each back to school, I'll give you a smart student question that will earn you extra points: why isn't javascript using 64bit signed integers there?
I'll expect to use IEEE 754 floating point and 2s complement integers like everybody else.
That's how floating point doubles work in any language. And besides, why should that be NaN? 1/0 is Infinity, not NaN.
That's how 2s complement 32 bit integers work in any language. Is there some standard that says that "big" signed integers should be surreptitiously changed into unsigned ones? Or that javascript should use 64bit longs?
I'll get you started, go on.
debuggers?