Calibre X64 2.1 will not install

[JSWolf]

Another solution is to download the 32-bit version, install that and use it for a week. Then grab the next 64-bit version the following week.

[hidden.platypus]

I shouldn't like you Penguin Wolf Lego BirdThing but I do. I really do.

[BeeTee-Ess]

Originally Posted by JSWolf

Another solution is to download the 32-bit version, install that and use it for a week. Then grab the next 64-bit version the following week.

That would be an interesting experiment. I'll try that, with v2.2, if I have problems with the 64-bit version.

[eschwartz]

Originally Posted by dfsfysdt

However, I've now tried this on 3 machines in our house. All running win 7, 2 running 64 bit win 7. Didn't think about downloading on my android devices, but I'll try that and report back.[Hidden spam link deleted.]

The problem seems to be a networking one, due to ISPs with membership in The Club of Blithering Idiots.

Try downloading using an HTTPS proxy, or from a different WiFi netork, say, at work or Starbucks or something.

I am unable to find a site that offers it over HTTPS.

Perhaps Kovid could upload the releases to GitHub? He already does that for the linux download... Or enable HTTPS on download.calibre-ebook.com

ISPs are fun.

[theducks]

What about just using the alternate site listed on the download page?

[eschwartz]

Originally Posted by theducks

What about just using the alternate site listed on the download page?

Because Fosshub does not offer HTTPS downloading. I did check first.

And neither does SourceForge. (The other mirror.)

GoogleCode does, but calibre is no longer mirrored there, ever since Google neutered the service... by disabling the release hosting. What did they think the service was for anyway?
You can, of course, download 9.35 there with HTTPS.

[BetterRed]

Originally Posted by theducks

What about just using the alternate site listed on the download page?

@theducks, I think the problem is downstream from the download source. It seems that if 'they' have something in 'their' download cache from the same source, with a similar name, and same size, that the same destination got some time before, then they send what's in 'their' cache with the new name rather than doing the download.

I've realised that 'they' cant verify by checksum because that's not available at the start of a download.

Most of us don't have a 'download optimizer' between us and the download site, thats why its only effecting a few folks. It maybe the ISP or it may be a 'them' that offers an 'optimized download service' to ISP's

Why is this happening on MSI files, maybe because this weeks MSI file is more likely to be the same size as last weeks, than a DMG or a TAR, or that 85% of downloads are MSI's.

One certain solution would be to make sure that successive install files, are not the same size. Or we all start running from source

@e...w - would HTTPS change the source, file name, file size, or destination, and if not, then how would it solve the problem ?

BR

[eschwartz]

Originally Posted by BetterRed;2914490@[B

e...w[/B] - would HTTPS change the source, file name, file size, or destination, and if not, then how would it solve the problem ?

BR

According to my google-fu, the ISP cannot intercept an HTTPS connection to "optimize" it, whether for good or ill.

Which makes sense, HTTPS being more or less designed for exactly this.

[BetterRed]

I appreciate 'they' can't intercept HTTPS to interrogate content - but what about source address, file name, file size and destination address, reading the Wikipedia entry its not clear to me that that metadata is not available. I'm not minded to read the RFC's

BR

[eschwartz]

Originally Posted by BetterRed

I appreciate 'they' can't intercept HTTPS to interrogate content - but what about source address, file name, file size and destination address, reading the Wikipedia entry its not clear to me that that metadata is not available. I'm not minded to read the RFC's

BR

Wikipedia on HTTP proxies (transparent proxy/http cache proxy):

http://en.wikipedia.org/wiki/Proxy_server#Detection

Detection

• By comparing the result of online IP checkers when accessed using https vs http, as most intercepting proxies do not intercept SSL. If there is suspicion of SSL being intercepted, one can examine the certificate associated with any secure web site, the root certificate should indicate whether it was issued for the purpose of intercepting.

My google-fu gave me the impression that the ISP literally cannot see anything you are doing on the website. Like this SuperUser question: http://superuser.com/questions/56385...-https-traffic

tl;dr
They can see the domain/IP address you connected to. And an indecipherable stream of encrypted data transferred between that IP address and your IP address.

Unless they use an SSL proxy with SSL certificates they signed themselves and conned you into adding to your computer's certificates bundle. (Read: shady man-in-the-middle attack.)



As the purpose of HTTPS is to encrypt your web traffic from both spying and tampering by anyone other than the two parties involved -- you and the website -- and the traditional way to circumvent this is with a man-in-the-middle attack, we must simply ask ourselves: how shady is this ISP anyway? The problem may be far greater -- they may be seeing all our bank info as well. If they can intercept and view or change the https MSI download, they can see/edit our online banking just as easily.

[BetterRed]

Originally Posted by eschwartz

My google-fu gave me the impression that the ISP literally cannot see anything you are doing on the website.

See what you make of this ==>> ssl - Why aren't application downloads routinely done over HTTPS?

See attachment for file sizes - only msi 64-bit was same size

BR

[kovidgoyal]

HTTPS adds overhead both bandwidth and CPU. In case of large file downloads, the bandwidth overhead is going to be large, since it prevents all caching.

Since I have to pay for both of those from my pocket, I am not inclined to do so to work around a few broken ISPs. Hopefully, weeks where the installers are exactly the same size as the previous weeks', will be rare.

[JSWolf]

One way to work around a broken ISP is to put up both the MSI and a ZIP version for when the files are the same size. That would solve the problem and no need for https.

[eschwartz]

Originally Posted by BetterRed

See what you make of this ==>> ssl - Why aren't application downloads routinely done over HTTPS?

See attachment for file sizes - only msi 64-bit was same size

BR

Yep, generally a bad idea because it cannot be cached for better performance. We have the opposite problem here.

The other real issue is extra resources required for encrypting, which are a horrible drain on basic file servers. But on a site like GitHub which does a lot of intense stuff, this is less of an issue.

Same reason why Google upgraded their entire infrastructure to support SSL. They can handle it easily, and now go around proselytizing it.

Now, I don't think software should always be served https. That is what digitally signing the exe is for, and linux repos use, I think signed checksums. However, it doesn't hurt to have the option. If the calibre site used ssl, most people would never know because it wouldn't be forced. And people with problems could be directed as needed. Alternatively, GitHub is a nice out-of-the-way place with free bandwidth to serve the fringe cases in the same manner.

Options are always good. And this one seems pretty feasible.

[BetterRed]

As Kovid said, having identical file sizes close together is 'rare', the number of 'too clever by half' ISPs is small. There are workarounds - wait a week, use a proxy, use portable or the other bittedness for a week, be nice to someone and they might offer to PM you a link to their file locker

BR