cflat

This is pure politics. The AOM want proof of loyalty and shipping a competing image format threatens that loyalty pact.

It’s also incrementalism at its finest. “We already shipped av1, adding a single frame decode is minor overhead” is the likely rationale. But it misses the point that images are gazed at while video is moving and can get away with a lot of quality sins that you can’t with images. But worse is that av1 is full of optional features. Sure the client could implement it, but how can you know? Even the lauded animated avif is horribly broken across the ecosystem because of this optionality — and there isn’t any way to tell a priori if the browser can support animated avif. Or 444 avif. Or ycocg avif. It’s just down right broken as an image format falling to the lowest common denominator.

Find yourself a canadian VPN endpoint and check out the CBC coverage (website or "Gem" app). It's pretty complete and much more accessible.

5.25" floppy disks are more likely to suffer physical damage at this point in history than a 3.5" disk. This would also contribute to the supply-demand curve biasing to 3.5" (on top of the ubiquity argument)

3.5" have a more durable design - the hard plastic, the spring loaded shield and, most importantly, the center disk that rested on the enclosure housing that prevented the magnetic medium from sagging.

When 5.25" disks are stored on end, they sag over time causing them to physically be unreadable. You have to store them flat. 3.5" are (mostly) resistant to this sag and therefore will be more likely to survive long term.

DNS is not content.

HTTP caches were always problematic from a business perspective. Great for downloading large binaries (installs) but problematic when they don’t expire as expected, or if content needs to change for contractual reasons.

This feels contrived. Rarely do I, as a brand or content creator, want it circulating without my control. It doesn’t make business sense.

CDNs are a known commodity with business relationships. You can’t have an unknown CDN in the mix. They are an extension of your infrastructure and you can control if they are or aren’t in the path of control. They key here is that there is also a legal and business relationship.

Yea, but the web server delivering them is now google. Google now gets the access logs and using the persistent tls socket can follow the users activity. Sure the content is signed, but the delivery is no longer private.

Let’s call a spade a spade. The only real world problem that WebBundles (and Signed Exchanges) really solve is to allow AMP to impersonate your website.

Google wants all the click data and the click through navigation data about users (by way of passive logs) so they can sell more ads.

There are no other real world problems that web bundles solve.

Agree. Safari has already made moves for this[1], but Chrome seems to be resistant[2].

[1] https://calendar.perfplanet.com/2017/animated-gif-without-th... [2] https://bugs.chromium.org/p/chromium/issues/detail?id=791658

Totally agree. To be clear, I wasn’t trying to overhype the ‘cure’ but rather emphasize that the problem is way more complicated than many believe because of the islet regeneration. That’s why I’m a believer in the tech we have now because it’s the most viable path to long term management.

For those who aren't initiated in the world of T1D there is some amazing research coming out of the Faustman lab (MGH). There is both a promising cure (BCG vaccine), but also research which indicates that islet cells _do_ regenerate for decades after diagnoses. Islet cells are the part of the pancreas that generates insulin - needed to store/save sugar. That means, that the pancreas is constantly trying to repair the damage from the immune system.

Let that sink in.

Many diabetics suffer from 'random' lows or highs that can't be explained. Not because they aren't doing the right things - because they are - but more likely because their body is bringing islet cells online, producing extra insulin, then the immune system promptly kills them and knocks off the extra production. It's a war within the body!

This is why Loop is sooo amazing and needed. You need a closed loop system that monitors and calibrates to these kinds of bio and environmental changes. Unexpected sprint for two blocks to get to class in time? no problem. Unexpected insulin production in the blood stream? no problem. This project is truly hero work.

As a spouse to a T1D, life is sometimes scary. I, like many partners always have a backup plan in the back of our minds for that that fateful day of an extreme low will not be caught in time. It's scary.

I for one, look forward to life with a bionic partner.

I wonder what would be necessary to spin up a device lab for proper TDD for the Loop?

This is such an amazing story of classical "hacking". This is what makes technology fun.

Teaching.

FWIW, using M3.Mediums at Spot with AWS Batch, the per vcpu rate works out to 0.0067/hr. Fargate is still ~600% more expensive.

A few clarifying points: * the author specifically said -1% Conversion. If this were AWS, that would mean a daily reduction of $6million in revenue! * the author specifically says this is for IE users. This implies two things: a) webp is not an option and b) likely we are also talking about lower class of hardware (mom & dad). I would expect WebP had older hardware probably has the same kind of performance tax, but it's harder to identify because at least with IE/Edge there is an implied age-of-hardware

still doesn't scale efficiently. http based streaming is the only reliable way to get economies of scale. The cpu cost per webrtc socket is high compared to a cache-hit for a static resource. Not to mention that WebRTC is way more cpu intensive client side compared to hls/dash which has kernel/hardware offloading.

Don’t use webrtc for live video. It doesn’t scale with CDNs. Use dash/hls.

the biggest impact is all the navel-gazing time we have spent trying to decipher what _is_ personal data and what are our obligations to our customer's and to their user. The actual work has been the easy part. We will never get back all the lost hours spent on debate, clarification, re-clarification, non-answers, vague-answers, more debate.

mp4s aren't HEIF. but this feature is certainly pre-lude to Safari supporting HEIF in the browser.

cool. painful, but cool.

in the context of <img> the audio track doesn't play anyway. dropping it ensures you save the bytes.

This usually happens when you have colour pallet increases. If you had a simple animated Gif with only 256 colours and convert it to any video you instantly have more data to compress. The better use case is where you start with video and convert down to gif (like when you use gif.ski)

Don't know if you need a spec change since this is technically now supported in Safari TP. (See the example) Really it's up to the browser to decide if it wants to use the media type or not.

Chrome now has the same enforcement for <video> tags.

the biggest draw back is the browser preloader and general performance. For cinemagraphs & clips this will be great. Anytime you want to add audio or pause/control playback, this will be the wrong solution.

ya. sad times. mirrored here: https://medium.com/@colinbendell/evolution-of-img-gif-withou...

Mirror: https://medium.com/@colinbendell/evolution-of-img-gif-withou...

read the post

the biggest challenge I've run into is big/legacy CMSes that simply can't get the templates updated to use <video> instead of <img>. It's why we can't have nice things.

still ridiculously large file compared to webm/mp4. The alpha support is cool though.