The nice thing about Apple owning the whole stack is the color management is pretty decent. Really good for testing your stuff to see how it would look if everyone had calibrated displays with the correct settings all the way through the entire software stack.
I keep a janky 10 year old display hooked up so I can drag my content over to it and see how bad it's going to look on everyone else's systems.
The other trick they have is really good ambient lighting compensation. Google just added something similar to the Pixel series, but it's not quite as good as Apple's implementation. AFAIK Apple have custom driver ICs and panels, which probably gives them way more control.
There used to be a service like this, called Car2Go. Not autonomous, but more like how scooter/bike rentals work. It was fantastic, and in no way profitable.
HDMI is patent-encumbered. The original specification has lost patent protection, but VRR and the other bits which form HDMI 2.1 and 2.2 are still protected as part of the Forum's patent pool. You could certainly try and upstream an infringing implementation into the kernel, but no one would be able to distribute it in their products without a license.
> no one would be able to distribute it in their products without a license.
In some jurisdictions, yes; however, some would probably still distribute it anyway, on purpose or not. I doubt all of them would get sued either, since lawsuits are expensive and difficult.
From my perspective, the objective is to make enforcement impractical.
> You could certainly try and upstream an infringing implementation into the kernel, but no one would be able to distribute it in their products without a license.
Isn't that actually a pretty good workaround? Hardware vendor pays for the license, implements the standard, sells the hardware. Linux kernel has a compatible implementation, relying on the first sale doctrine to use the patent license that came with the hardware, and then you could run it on any hardware that has the port (and thereby the license). What's the problem?
> relying on the first sale doctrine to use the patent license that came with the hardware
First-sale doctrine protects against copyright or trademark infringement. You might be thinking of "patent exhaustion"[1], which is a mostly US-specific court doctrine that prevents patent holders from enforcing license terms against eventual purchasers of the patented invention. There is no "transitive law of patent licensing", so-to-speak.
In this case, it would still not protect Valve if they exercise each claim in the relevant patents by including both hardware and an unlicensed implementation of the software process. It would protect end users who purchased the licensed hardware and chose to independently install drivers which are not covered by the license.
It's murky if Valve would infringe by some DeCSS-like scheme whereby they direct users to install a third-party HDMI 2.1 driver implementation on first boot, but I don't think they would risk their existing HDMI license by doing so.
Thanks! Do you have a source for this? Would appreciate a pointer if you have one.
IIRC there is also a limitation on making platform-like super-apps on iOS and it feels like that might be a natural occurrence depending on just how much dynamic functionality you pull in via Wasm (i.e. how powerful your app is).
Apple Developer Program License Agreement § 3.3.1.B, "Executable Code" [1]:
> Except as set forth in the next paragraph, an Application may not download or install executable code. Interpreted code may be downloaded to an Application but only so long as such code: (a) does not change the primary purpose of the Application by providing features or functionality that are inconsistent with the intended and advertised purpose of the Application (b) does not bypass signing, sandbox, or other security features of the OS; and (c) for Applications distributed on the App Store, does not create a store or storefront for other Applications.
> Apps should be self-contained in their bundles, and may not read or write data outside the designated container area, nor may they download, install, or execute code which introduces or changes features or functionality of the app, including other apps. Educational apps designed to teach, develop, or allow students to test executable code may, in limited circumstances, download code provided that such code is not used for other purposes. Such apps must make the source code provided by the app completely viewable and editable by the user.
Problem is, I can easily set up a company and get an EV cert for "FooBar Technologies, LLC" and phish customers looking for "FooBar Incorporated" or "International FooBar Corp.". Approximately zero users know the actual entity name of the real FooBar.
Even if the users knew exactly what the name of the entity whose website they wanted to visit was: that name is not unique, as is shown by the "Stripe, Inc" example in the parents linked blog post.
BIMI, as misguided as it is, does aim to solve this by tying registration to insanely high prices and government-registered trademark verification. You would have a hard time registering the Stripe trademark nowadays in a way that would get you a BIMI certificate for that name/logo.
But I'm glad that it hasn't caught on as strongly-expected by the public (or even commonly used). Big brands shouldn't be able to buy their way into inbox placement in ways that smaller companies can't replicate.
Trademarks are industry-specific. Ordinarily, a painting company called Stripe isn't going to cause confusion with the payment platform Stripe, so there's no reason to deny the trademark.
It's how you end up with both Apple Corps (the Beatles' record label) and Apple Computer (the tech company). They've been involved in quite a few lawsuits over the years, mostly because the tech company decided to expand into the multimedia business.
The tolerance is now precisely specified in the HTML5 parsing algorithm, far from "try their best". This is good, because browsers fail in mostly the same ways as each other, humans do not need a CS degree to handwrite Web content, and your tools can still write perfectly valid HTML5.
Obviously now things are better than IE5/6 era, but I can't help but think people without CS degree have to hand tweaking HTML because people who with ones failed to design proper tools and abstraction for them.
More than that, HTML5 specifies how browsers handle "broken" HTML. There's a super-precise algorithm that dictates what to do for unclosed tags, how to fix up the DOM for incorrect nesting, specific fallbacks/behavior for invalid attributes, and so much more. I would say this algorithm, along with its element/attribute-specific components, are where most of the HTML5 effort was applied, and continues to be such for newer Web APIs.
Browsers "trying their best" was like half of the Browser Wars, and what HTML5 was largely created to address. The other half being nonstandard ActiveX crap and IE-specific JavaScript.
reply