Live data from Hacker News

The likely end of DownThemAll

downthemall.net

131–140 of 142 posts

Re: The likely end of DownThemAll

#131
post #120

Earlier quoted context omitted.

> So you're suggesting they say "we intend to deprecate this feature", but not give a timeline? Yes; but that only works if they don't actually _have_ a timeline. Do the necessary work to let people explore options, then evaluate and give a timeline (in the same order as what it took to get all that implemented). The timeline currently is "you have 12 to 18 months, but can't actually start". That's pretty much a reci…

I guess it's a matter of opinion, but I greatly prefer it they way they did it. Announcing "this is going away" without a timeline would make me worry "when? now? in a month?" Instead, by saying "12 to 18 months", I know this is a long-term thing and I can plan for it. The timeline is very useful information.

But the point is that they shouldn't have set the timeline until a replacement was reasonably in place. They could (and should) have said "this is going away 12 to 18 months after we've been able to determine what APIs are needed and implemented them".

Re: The likely end of DownThemAll

#132
post #90

As to NoScript: - from a linked Mozilla blog post: > [...] A major challenge we face is that many Firefox add-ons cannot possibly be built using either WebExtensions or the SDK as they currently exist. Over the coming year, we will seek feedback from the development community, and will continue to develop and extend the WebExtension API to support as much of the functionality needed by the most popular Firefox extens…

Giorgio's post on the matter: https://hackademix.net/2015/08/22/webextensions-api-noscript...

Re: The likely end of DownThemAll

#133

Earlier quoted context omitted.

> What you're describing isn't a modern power user OS -- you're describing iOS. Hardly. Windows, Linux and OS X do not let you monkeypatch the entire system.

Actually, they pretty much do. Take for example Dropbox. Windows officially 3rd party applications adding overlays to icons which dropbox uses to provide sync status for items in the dropbox folder. OS X has no such feature or API for icon overlays. Through lots of trial and error, swizzling, mach_inject, and mach_override they managed to provide this feature in OS X as well.

> Through lots of trial and error, swizzling, mach_inject, and mach_override they managed to provide this feature in OS X as well.

And it's not unlikely that Apple will break them at any time. Apple won't even go through the trouble of making an announcement when they do so.

Re: The likely end of DownThemAll

#134

Earlier quoted context omitted.

Actually, they pretty much do. Take for example Dropbox. Windows officially 3rd party applications adding overlays to icons which dropbox uses to provide sync status for items in the dropbox folder. OS X has no such feature or API for icon overlays. Through lots of trial and error, swizzling, mach_inject, and mach_override they managed to provide this feature in OS X as well.

> Through lots of trial and error, swizzling, mach_inject, and mach_override they managed to provide this feature in OS X as well. And it's not unlikely that Apple will break them at any time. Apple won't even go through the trouble of making an announcement when they do so.

In fact, I believe they are doing exactly this in El Capitan. Under the umbrella of "Rootless", you will no longer be able to arbitrarily modify [1] some special blessed OS processes, like Finder.app.

Some discussion of the politics of this issue: http://atp.fm/episodes/128

[1] haven't read enough to know the exact mechanism, but presumably restricting some forms of IPC like Mach messages?

Re: The likely end of DownThemAll

#135
post #35
post #21

Earlier quoted context omitted.

>Electrolysis apparently breaks XUL extensions. This is wrong. It absolutely does not break XUL extensions per-se. Add-ons will require some (moderate for most add-ons) changes when accessing out-of-process web content. A lot of add-ons may not even require changes at all, because they either do not access web content directly in the first place, or the Cross-Process-Wrappers and shims mozilla already implemented wil…

I'm prepared to be wrong, as I am not an expert on XUL, Electrolysis, or the Firefox runtime. I can however interpret what Mozilla says is the reasoning behind breaking XUL extensions, which is: XUL extensions, among other things, get in the way of getting Electrolysis working. That's linked from this blog post. If things have to break in the short term for Mozilla to modernize Firefox's runtime hardening, well, that…

Electrolysis is mostly already implemented with the XUL version of Firefox and many add-ons have been ported over to be compatible with it.

The main new change being announced recently (electrolysis and extension signing have been known about for a while now) is the deprecation of XUL in the browser in general and for add-ons in particular and the adoption of a new extension API's that are more limited in functionality (WebExtensions and whatever else they decide to do to allow more functionality than is available in Chrome). There are security implications to these changes but multi-process Firefox is not the main driver. Mozilla is giving up on XUL in favor of HTML and using this as a pretext to limit the functionality of add-ons (which many Firefox developers have wanted to do for a long time for security and stability reasons).

Re: The likely end of DownThemAll

#136

Earlier quoted context omitted.

Actually, they pretty much do. Take for example Dropbox. Windows officially 3rd party applications adding overlays to icons which dropbox uses to provide sync status for items in the dropbox folder. OS X has no such feature or API for icon overlays. Through lots of trial and error, swizzling, mach_inject, and mach_override they managed to provide this feature in OS X as well.

> Through lots of trial and error, swizzling, mach_inject, and mach_override they managed to provide this feature in OS X as well. And it's not unlikely that Apple will break them at any time. Apple won't even go through the trouble of making an announcement when they do so.

I'm sure they understood the risk when they did it.

Re: The likely end of DownThemAll

#138
post #7

This is what happens when humans achieve success. Rather than maintain the course they are obligated to exploit to the nth in order to squeeze every gram of return from an idea(product) until they can get no more. Then, they will get creative and pull out every hook & crook to squeeze some more. Thanks Mozilla, for everything up until your mass-collection, feature- bloat, entrapment blitz you've set out upon. Perhaps…

I don't understand what is being exploited?

The end-user, of course.

"Surreptitious spying is all the rage. Everybody is doing it."

Re: The likely end of DownThemAll

#139
post #55

Earlier quoted context omitted.

The main reason people install it I thought is because 1. It allows downloads to start and stop. No more 90% of that iso then having to start again. 2. It opens up 4 thingies on the file and downloads simultaneously. So 4 times quicker if the website is restricting bandwidth per connection.

> 1. It allows downloads to start and stop. No more 90% of that iso then having to start again. I'm surprised Firefox doesn't do this itself, as in, this sounds like a clear bug. Is there some reason the upstream project by itself doesn't get this right? > 2. It opens up 4 thingies on the file and downloads simultaneously. So 4 times quicker if the website is restricting bandwidth per connection. ... this works in 20…

This works pretty well if you are behind a HTTP Proxy and the proxy is limiting speed per connection. This was a common scenario in my university.
Post reply on HN