LukeLambert

The big problem with statement-based replication is that many queries are non-deterministic. e.g. Inserting a row with current_timestamp or random()

Yes, it was the Ghost URL. Thank you for correcting it! I read just about every post, so I have a lot of catching up to do.

This is really cool and I can't wait to read all about it. Unfortunately, I've missed a month of blog posts because Cloudflare changed their blog's RSS URL without notice. If you change blogging platforms and can't implement a 301, please leave a post letting subscribers know where to find the new feed. RSS isn't dead!

I don't think Starlink has any data caps. On average, the tests download 140 MB and upload 15 MB each run (560 MB and 60 MB daily).

Note that the timestamps are UTC, while Texas is UTC-6:00 during Standard Time and UTC-5:00 during Daylight Saving Time. The biggest dip is during prime streaming hours.

Yep!

  speedtest -f json -I eth0

My parents in rural Northeast Texas use Starlink as their primary connection (they have a WISP as failover). Since Sept. 2022, I've been running automated speed tests four times a day (1 and 7, AM and PM). Speeds vary a lot throughout the day, but average about 100 Mbps down by 10 Mbps up.

https://gist.github.com/LukeLambert/dd722e49bc773bcb27e859d9...

Can someone explain what it looks like from a user's perspective when an article is blocked? Is there an error message? Limited reach? Plain link instead of rich preview?

If the publishers don't want their photo, headline, and first sentence or two appearing without payment as a rich preview on Facebook, well ok. I think it's a stretch, but I can at least see their perspective. It's worth noting that publishers are already in control of that preview with Open Graph tags.

However, if they want to get paid for an unadorned <a> tag, that completely goes against the spirit of hypertext.

I think Simon has a lot of experience solving hard problems: https://simonwillison.net/about/

With Messages and Music in particular (and perhaps other apps), you can sign into a different Apple ID than the one used for the system-level iCloud account.

That's likely due to the page having a canonical URL meta tag:

  <link rel="canonical" href="https://www.twintown.com/collections/acoustic-guitars"/>

  javascript:prompt('URL',window.location.origin+window.location.pathname)

Thank you for following up. IMHO, object-fit is not the right model for server-side image manipulation, since its behavior is only specified when both width and height are supplied. I've also never seen a real world use case for stretching, squeezing, padding, or enlarging images on the server. That should be done on the client. I mentioned some of the same issues on the Cloudflare forum when they announced an image resizing product based on object-fit.

I believe all resizing operations a user might realistically want can be achieved with three parameters: width, height, and crop. Additional x and y parameters (floats between 0.0 and 1.0) could be used for setting the focal point of the crop box.

Examples:

  source.jpg?width=400

  source.jpg?height=300

  source.jpg?width=400&height=300

  source.jpg?width=400&height=300&crop=true

In nearly two decades developing for the web, I've never found a good reason to enlarge an image server-side, so thank you for anticipating that footgun. So many of your competitors get it wrong.

However, it's unclear from the docs [0] if one of the most common use cases is supported: requesting an image at a specific aspect ratio while not exceeding a maximum size.

For instance, I want a 1600×900px hero image at the top of my blog posts, but my source image is only 1200px wide. I request:

  transform: {
    width: 1600,
    height: 900,
    resize: 'cover'
  }

A few more notes:

The blog post states "default mode maintains aspect ratio and the resize mode is fill", but the docs say that cover is the default mode.

The docs say, "If only one [width or height] parameter is specified, the image will be resized and cropped, maintaining the aspect ratio." I believe that with only one parameter, you could either resize or crop, but not both. I hope it's resize.

For cropping modes, is it always from the center? Are there plans to support other "gravity" modes?

[0] https://supabase.com/docs/guides/storage/image-transformatio...

  div {
    width: 640px;
    aspect-ratio: 16 / 9;
  }

No, Argo optimizes the route of traffic from the edge (your closest Cloudflare data center) to the origin (the server hosting your website). With Pages, everything is served from the edge.

Static sites benefit from being low-maintenance and highly-portable. You can easily switch from generous free services (Cloudflare Pages, Netlify, Vercel, Firebase, etc.) to highly-available paid services (Amazon S3, Cloudflare R2, Backblaze B2, Google Cloud Storage, etc.) Keeping a VM running and updated is more work (and sometimes higher cost).

The benefit of a static site generator like Next.js is that you can cache everything at the edge. It’s not surprising to me that the initial page loads quickly (via Cloudflare’s cache). But the multi-megabyte JSON embedded in the HTML as well as the multiple JSON files loading in the background are completely unnecessary and just waste battery, memory, and data. The page could easily be 1-5% of its current size.

While looking for the blog’s RSS feed (sadly it doesn’t appear to have one anymore), I noticed that the size of the HTML alone was nearly 5 MB uncompressed. Over the course of scrolling to the bottom of the page, it loads tons of 4+ MB JSON files. The unscaled author images and numerous tracking scripts also contribute to the enormous payload. I don’t know enough about Next.js internals to say what went wrong here, but that seems ridiculous for a simple blog.

This is the second security issue with a TLS-based challenge [1]. This was a good reminder to switch to the HTTP challenge for the one remaining server I had that was affected.

[1] https://letsencrypt.org/docs/challenge-types/#tls-sni-01

fit=crop and fit=cover only work well if the source dimensions are greater than 512×512. If either dimension of the source is smaller, the behavior is useless.

fit=cover will return a square (as requested), but will enlarge it (which you never want because it wastes bandwidth).

fit=crop will cut off excess pixels if either dimension exceeds 512, but it does not always return a square. (And contrary to the docs, it does not behave like fit=scale-down.)

I want to maintain the aspect ratio of my crop, not that of the source image. Perhaps `fit=cover-scale-down` would be a more appropriate name. In other words, I always want a square image <= 512px wide. I think this is a very common use case.

That’s why many image CDNs allow signed URLs. With Cloudflare Image Resizing, you’d need to implement that functionality using Workers.

Image Resizing is technically a separate product, so I apologize if this is off-topic, but it appears to be missing the most useful `fit` mode – something like `fit=cover-scale-down`. I never want to enlarge an image on the server, since I can do that client-side. If I request a version with the dimensions 512×512 (square), but the source image is only 400×600, there should be a way to get a resulting image of 400×400. Am I misreading the docs? https://developers.cloudflare.com/images/image-resizing/url-...

Edit: Changed suggested name of fit mode for clarity.

It only works with hardware from certain manufacturers, which at the moment does not include Apple:

"While there is a variety of hardware security keys, our initial rollout is limited to a few devices: YubiKeys, which we had the chance to use and test; HyperFIDO keys; and Thetis FIDO U2F keys."

I had no idea Randall Munroe of XKCD has had a column at NYT since 2019. His illustration style is so distinct.

The tech preview[1] works and you can run x86 images (though you get a warning from the CLI).

[1] https://www.docker.com/blog/download-and-try-the-tech-previe...

I'm not great at bash, but this little script worked for me.

    #!/usr/bin/env bash
    docker ps --format "{{.ID}} {{.Names}}" | while read line; do
      read -ra arr <<<"$line"
      id="${arr[0]}"
      names="${arr[1]}"
      arch="$(docker exec "$id" uname -m)"
      echo -e "$arch\t$names"
    done

    docker ps --format "{{.Names}}" | xargs -tI {} docker exec {} uname -m

This CNET article features a diagram of how the cat was wired up. Pretty crazy that 1960s surveillance tech would be miniature enough to go unnoticed inside a cat.

https://www.cnet.com/pictures/crazy-cia-spy-tech-from-the-50...

Also, I hope anyone looking for a band name is taking note of this project's name.

I think that was sort of Axios's goal.