Realistically, nobody outside of Hacker News commenters have ever cared about the OSD. It's just not how the term is used colloquially.
5,684 karma · joined November 8, 2011
Realistically, nobody outside of Hacker News commenters have ever cared about the OSD. It's just not how the term is used colloquially.
• Logging events for errors.
• Seeing device statistics to know which browsers/devices to support/optimize for.
• Reviewing page flows to understand how users navigate/understand the site. Is the navigation easy to understand? Are the right pages highly-visible?
• Seeing which pages have high drop off rates, indicating either a resolution or lost hope.
• Analyzing trends over time to better understand users and the topics they're focused on. Is there high traffic to covid-19 symptom pages? Or maybe student loan forgiveness resources?
I can see a lot of meaningful and actionable data being gleaned from such systems. It's much more difficult to make improvements without supporting data.
I think most programmers find this logic easier to type out than to "draw" in a graph, but it's conceptually the same thing.
What about running LoRAs, adjusting temperature, configuring prompt templates, etc? It seems pretty early to build something like this into the browser. The technology is still changing so rapidly, it might look completely different in 5 years.
I'm a huge fan of local AI, and of empowering web browsers as a platform, but I'm feeling pretty stumped by this one. Is this a good inclusion at this time? Or is the Chrome team following the Google-wide directive to integrate AI _everywhere_, and we're getting a weird JS API as a result?
At the very least, I hope to see the model decoupled from the interface. In the same way that font-family loads locally installed fonts, it should be pluggable for other local models.
Basically, you did a fuzzy search and got a fuzzy result. Usually that's what people want. Quotes will let you fine-tune results. Or if you want all results to be strict by default, use verbatim mode. I tested that with the above string and again, only this thread showed up.
For example, a small, personal blog might be great for solving a specific technical problem ("my dishwasher of model XXX has YYY problem"), but might be terrible for something like giving public health advice.
With on click, it only requires lining it up once before executing. There's less follow-through required. And as a best practice, there is an undo button.
Ultimately the Privacy Sandbox has dozens of different proposals, and each is on a separate standards track. It's not a singular technology.
I will say that many of the proposals do directly improve user privacy, or offer more-private alternatives to existing APIs. But I'd also be surprised if there weren't objections as well. It's the web, and scrutiny is important.
That's debatable, but I doubt that's the case. The CMA isn't a privacy organization; they deal with monopolies. They're intervening at the behest of other advertisers who are concerned that they'll lose the ability to adequately track users under the Privacy Sandbox proposal. The CMA's chief concern is that everybody is on equal footing.
The alternatives proposed for more private ad targeting have gone through multiple evolutions, including FLoC and Topics, but these were created largely in response to the CMA's objections.
It's explained in the article, and below in this thread. They legally cannot due to intervention from the CMA.
Without this interference, third-party party cookies would have been dead years ago.
Organic and perovskite cells have a higher potential efficiency. Just like was the case with silicon, it will take years of development and incremental improvements to see higher efficiencies in these technologies. Silicon cells were also not very good at the start of their development.
In that sense perovskite has the potential to be the next generation of solar cell. New developments, such as the one demonstrated in the linked paper, are just a step towards that ultimate goal of more efficient solar.
I'm not an expert in this field, so please feel free to correct any mistakes I've made.
Still seems a bit complicated to me, but could be meaningful for web apps that are required to be large.
Looking at your network graph real quick, you might be able to get away with simplifying GTM. I'm only seeing it load analytics, at least on the client side.
Normally this page is 824KB/15 requests. With an adblocker preventing GTM though, it's 655KB/8 requests. A pretty big reduction.
Also, I see it bootstrapping google-analytics.com/analytics.js, which if I'm not mistaken is the now-defunct GA3's analytics. Could that be nixed?
If you're using GA4, there might be lighter alternatives as well. Though it sucks to lose data continuity, most of their competitor are a _lot_ smaller in JS payload (Matomo, Plausible, umami).
Previously you could also just send the signals directly to GA using the Measurement Protocol, but it seems like they've made that a lot more difficult in GA4. Searching online, it looks like maybe GA4MP can do it, but I've not tested that tool.
You could also just load gtag.js rather than all of GTM if you're not using other tags, but that's still pretty heavy.
Outside of analytics, you might want to look at thumbnail generation. To take the worst offender, speed3.png is being rendered at 512px, but it's actually 2430px wide. Now sure this image is mostly white so it compresses well, but on most images that would make a big difference.
Lossy compression (via TinyPng.com) also brings this image down from 167KB to just 46KB. And if we first shrink it to the displayed resolution of 512px, then it shrinks to just 8KB. That's a 95% reduction from the original!
Image weight is less offensive than JS because it doesn't need to be processed. And if you're using size attributes (you're not), it also avoids CLS problems. But it's still often an easy win when it comes to reducing total page size.
If you wanted to be really fancy, you could generate multiple resolutions (for mobile, etc) and provide all of them in the <picture> tag. Or generate some more optimized format alternatives (webp, avif).
Realistically you probably have some limits due to using GitHub Pages. I do too, so integrating build steps to perform these kinds of optimizations is difficult. Maybe it's possible using GitHub Actions - that's something I'd like to look into for my own site.
Anyway, hope some of this information is helpful to you.
Skimming through some of the code comments, this tool actually does a pretty good (though not perfect) job of interpreting each function. It would likely need to be limited to only larger functions though, since many of the smaller or boilerplate functions are self-explanatory. And seeing as this is Java, there are a lot of those!
https://docs.godotengine.org/en/3.1/getting_started/step_by_...
It might not be as good as sharing real popcorn, but it can be a surprisingly convincing imitation.
[1] https://store.steampowered.com/app/457550/Bigscreen_Beta/
I tried it in Firefox and got an XML parsing error[1] instead. Again refreshed and it loaded fine. So it seems intermittent at best.
[1] Error follows:
XML Parsing Error: mismatched tag. Expected: </link>.
Location: https://www.feed.style/example.xml?feedurl=https%3A%2F%2Fnews.ycombinator.com%2Fshowrss
Line Number 6, Column 3:As a side note, it seems like a number of your "after" examples do not load. HN hug, or something else?