I just can’t find the live iso. If I click on Clear Linux* OS Desktop download button, it downloads the SHA512. If I click on Sha512, it downloads clear-31290-live-server.iso. I can’t find the live-desktop.iso that comes with the Gnome desktop.
Any help, please?
Yeah, sorry about that. There is bug with the downloads page right now.
Here is a direct download link for now:
https://download.clearlinux.org/releases/31270/clear/clear-31270-live-server.iso
Thanks for the quick reply.
I need the live-desktop.iso, not the server.
https://download.clearlinux.org/releases/31270/clear/clear-31270-live-desktop.iso for the live-desktop
1 Like
Thanks!
Will have a look. 
puneetse
The two download locations are incredibly slow, have been for a long time, that is, never seen much more than 1MB/sec download rate.
Any other options to deliver higher bandwidth?
I’m in Australia, are you using a CDN edge location here?
What about a torrent solution?
At home i’ve a connection of about 11.8MB/sec
My server connection is about 120MB/sec
Takes so long downloading images @ 1MB/sec you know.
Hi @ketonik , I’m flagging this up to our devops team to see if there’s anything they can do in the CDN configuration to help.
@ketonik - we do use a CDN vendor for distribution of content, and it definitely has edge locations in Australia. Unfortunately, if you are the first (or second) to download a file, it has to cache from the Origin location, which is in the U.S… I can confirm that for sites far away latency wise - that 1M/s is what I see as well. The CDN vendor uses some logic/heuristic to decide when to cache - in conjunction header settings. What I have noticed is that after two consecutive pulls of a cache eligible file, I see 40M/s rates.
I don’t have any systems in Australia to test - but could you confirm what I see (3 consecutive downloads) to ensure the CDN is caching properly there?
1 Like
Yes, I can confirm, caching behaviour as described is working.
First download was 1.1MB/sec, second and 3rd download 11.8MB/sec, effectively saturating my maximum download rate potential.
Congrats on being our first Australian user!
Maybe not! I’ll add what I’ve observed connecting via Sydney.
Originally you had Akamai I think as the main CDN, was not great and would fluctuate a lot mainly between 700KB-1MB/s. If I forced an IP to the DNS lookup to get a US node, I would get a faster download speeds. cdn-alt (Equinix I think) was similar, but faster on average (25-50%) so used that.
Then you had I think the current Amazon CDN running as cdn-alt for a few weeks. During this period I felt like I was getting full speeds pretty much all the time. When it was deployed as the main cdn, speeds dropped to what we see now (about 1.4MB/s for me). It’s always felt like a load issue on the server feeding the CDN too slowly, rather than a bandwidth/connection issue from the CDN node to US, as I certainly max out my connection to pretty much anywhere in the US.
I only peak at 3MB/s so I haven’t really cared about it. Updates have been slow at times (one took 40 minutes for maybe a weeks update), and often not due to download speeds. Autoupdates (which I don’t use) means people won’t see how fast (or slow) updates are.
Thanks for the caching test @ketonik, and for the observations @sunnyflunk.
Some background. We did have two CDN’s in play for some time. Akamai for cdn. and AWS CloudFront for cdn-alt. Indeed, there were certain sites that Akamai seemed slower, and we would point users to the cdn-alt address where they enjoyed better speeds. In August - we migrated the download content ‘Origin’ server from a traditional Linux system with a SAN backend to a cloud native object store bucket. The desire to do so was for the high up-time, endless disk space, auto-scaling and from our perspective, a server-less design. However, moving the to the object bucket required some Akamai features to make it all work, things that could not be done in AWS CloudFront. As a result, all addresses were directed through Akamai.
I will query the IT folks that manage Akamai for us to see if we can improve those initial downloads speeds.
Fascinating, perhaps that server change is what coincided with the speed change as the traceroute has changed somewhat (no longer showing AWS servers).
Is it possible to test the speed directly to the origin server (i.e. taking out the CDN bits, though you may not want to post it publicly)?
CDN’s have always worked out poorly for distro packages in AU, likely due to lack of users from the location so files are never cached!
Try this lightweight extension with Firefox.
Instead of looking for a local mirror, open multiple threads to any other source(s).
It has full split / stop / resume / chunk / retry capabilities.