HN user

atopal

343 karma
Posts5
Comments61
View on HN

I was just correcting your numbers, but I also want to point out that power generated from solar has grown more than 30% in just two years and I think it's uncontroversial that we are in the early stages of the s curve for adoption. Negative prices are obviously an arbitrage opportunity that Battery Energy Storage Systems (BESS) are in the process of capitalizing on.

If you mean "driven or steered remotely": They were never teleoperated. I'm assuming that would be completely reckless given the nature of radio networks and possibly because of regulations. The car will call a service once it can't make a decision (this is only when the car is fully stopped), and a human will decide to send out a driver or make a decision in the moment.

We made that change around 2017. Mozilla Developer Network is somewhat ambiguous. In surveys and user interviews people were confused about the name. Web developers thought it might be a resource specifically for Mozilla developers, which to be fair was the focus in the earlier days. The web platform documentation was just one part of many Mozilla related things documented on MDN for some time. In 2017 though the web platform documentation had grown to make up 95% of MDN's traffic and it had become clear that it was not primarily a resource for Mozilla developers anymore, the name change to "MDN Web Docs" was intended to reflect that change in focus.

Looking at browser usage for the last two major versions is misleading. That would only be true in a parallel release of a web platform feature in every browser, but that's basically never the case, and it's not the same for every feature. A feature like subgrid was launched years ago in Firefox, last year in Safari and will be launched later this year in Chromium. So, by the time it's in Baseline, it will be in two versions back for Chromium browsers, but 20+ versions back for Firefox and over a year old in Safari.

The issue with Safari is that it's tied to the operating system on iOS. That's an issue with minor releases, but even more so with major releases, where you can't get Safari 16 for iOS 15. That naturally means slower uptake compared to Chrome or Firefox which will update the browser in the background seamlessly.

I'm hoping that we'll be able to identify better usage data and a better understanding of developer expectations to refine this definition.

The core browser set is not defined in exact versions of browsers, since many browsers release every 4-6 weeks. The two most recent major versions refers to the number before the first point. So, for Chrome it would be 113 and 112, for Safari it would be 15.x and 16.x.

But the crucial point is, it's not the same for every feature. A feature like subgrid was launched years ago in Firefox, last year in Safari and will be launched later this year in Chromium. So, by the time it's in Baseline, it will be in two versions back for Chromium browsers, but 20+ versions back for Firefox and over a year old in Safari.

Maybe showing the version numbers on the widget per feature might be useful.

Wow, is that really necessary? It almost hurts physically to read that strong of a statement directed at another person.

You aren't even really disagreeing with the OP. You could have said: "You're right about the 99% of non professional use cases (sharing on social media and the occasional small print), but not the 1% case of big prints.

Thanks for the feedback! So, one thing we are doing differently this time around is updating the site incrementally instead of a big bang redesign. In the case of the article pages that means limited changes in the first phase to get them to conform to the new brand identity. The number of characters per line is an issue though. As stated in the blog post, we'll address the article page layout in the next phase. Article pages are where MDN users spend most of their time, we want to make sure we get those right, so we are setting aside time to focus on just them.

But Mozilla claims that it's exactly the old add-on system that keeps Firefox from being more secure. What if they were just as secure as Chrome after giving up on the old add-on system? Wouldn't it make more sense for them to compete without the disadvantage of being the less secure browser?

AFAIK they don't. There is a cap on licensing for H264. Cisco is already hitting that limit with their commercial offerings, so they can essentially offer OpenH264 at zero (licensing) cost.

There is a lot to be said for having choice. Just because the dominant browser today is OSS (Chrome) doesn't mean Mozilla should declare victory and pack its bags with Firefox.

Just since this is repeated so often: Chrome is not and never has been open source software in any shape or form. Chromium is OSS, but has only a tiny fraction of Chrome's market share and AFAIK nobody really knows what the differences between those two are (outside of the obvious: Flash player, pdf reader, etc.). Btw, Firefox is still the only major browser that's OSS, neither Safari nor Edge/IE are open source.

This isn't academic nitpicking either. Mozilla had to build a PDF reader from scratch (pdf.js), it couldn't just reuse what Chrome was using to display pdfs, since it wasn't open source. However everyone can now use pdf.js for the same task.

One thing that's really disappointing is that more and more sites are hiding pricing information until you sign-up. That feels like at least a gray if not a dark pattern. For me that's a terrible first impression. It's a sign that I have to look out for further deception, even if that's not the intention.

I'm guessing that A/B testing shows this to be more profitable than being upfront with pricing?