6 ms·
Open protocols are great but they are also absolutely a hindrance on change. If you’ve ever worked on a public API you know how painful making a breaking change
by tpmoney 2y ago
Open protocols are great but they are also absolutely a hindrance on change. If you’ve ever worked on a public API you know how painful making a breaking change to that API can be. Inevitably something you want to change becomes some one else’s “hold space bar to heat room” feature. And sure you can have “private”
Or reserved spaces in APIs, but that can often lead to messes like needed 5 different vendor specific CSS tags to accomplish the same thing in all browsers, which in turn really leads to consolidation around one “winner” (see also IE6 and Chrome). They might very well still be able to make unified systems on open APIs and platforms, but it’s not clear whether they would be able to make them as well as they do when they control and own the whole stack and can change it without having to worry about anyone else.
- rickdeckard 2y ago> Open protocols are great but they are also absolutely a hindrance on change. If you’ve ever worked on a public API you know how painful making a breaking change to that API can be. I worked on public API's. If there's a justified need for a breaking change, make a new API and deprecate the old one. It can of course be harder than this, but its complication mainly comes from proper PLANNING of the action and AWARENESS of the environment. It's an OS, let's treat it as such and not buy into this narrative how hard and unfair the world is to this trillion dollar company.
- tpmoney 2y agoAgreed it is an OS. How many years will it be before audio on the Linux OS doesn’t suck? It’s way better than it used to be, but I still spent weeks this year trying to sort out what magic combination of alsa, and pipewire and pulse-audio and wireplumber setting, configs and launch timings would get HDMI audio to not come up muted on a mini PC with integrated Radeon graphics in Ubuntu. Surely the openness of the x86 platform and Linux itself would mean that these sort of experience should be easy and painless in the way that audio on macOS or even windows is right? Or how about the huge fight that systemd has been (and continues to be). If we imagine a world where os init was regulated by the EU, what do we imagine the systemd integration into RedHat would have looked like? We might imagine it would have looked the same, or we could also imagine that it gets challenged and beaten down in court because it’s breaking the current open standards “for no reason”. The world already has an open phone os with multiple hardware vendors platform. It’s called Android. What do we expect actually gets better if iOS is forced open and why is that not already an option on Android?
- rickdeckard 2y ago> How many years will it be before audio on the Linux OS doesn’t suck? to be blunt, it doesn't seem to suck whenever someone designs a consumer product around it. I have DVD-Players, BluRay Players, Network Radios, all based on Linux OS, and I never have to hassle with alsa and pulse-audio. In fact I never interact with the underlying Linux, just like accessory vendors don't use linux APIs to communicate with iOS. > If we imagine a world where os init was regulated by the EU We don't need to imagine anything like this, the EU is not regulating any OS. The EU identified that Apple is a gatekeeper to a market and simultaneously a player there, controlling the market in its favor. To ensure fair competition, Apple is required to ensure that it's a fair market for all players. As stated elsewhere, Apple is still enjoying a significant advantage, because they could still develop i.e. a Airpods feature which relies on a newly developed iOS-feature, launch both simultaneously and be the only one on the market using it. The only major impact is that they are not allowed to restrict competitors from ever catching up with them.
- tpmoney 2y ago> We don't need to imagine anything like this, the EU is not regulating any OS. The EU identified that Apple is a gatekeeper to a market and simultaneously a player there, controlling the market in its favor. That market being… software development for their OS? And the features they are regulating being OS features (see “newly developed iOS feature”). So they are trying to regulate the OS then right? Like if Apple release iPhones with two OS options, “iOS Core” with not private APIs and no developer restrictions, but limited (even for Apple products) to all their things any external developer is limited to now and “iOS Apple Edition” with a model exactly like the current iOS and reserved all their “competitive advantage” features to interactions running against that OS, this clearly wouldn’t be good enough to satisfy the DMA requirements right? The goal isn’t that Apple competes “fairly” on any arbitrary platform, it’s specifically that Apple competes “fairly” on the platform that Apple puts their best features on.
- rickdeckard 2y agoThe market being the sum of iPhone end-users buying other stuff than iPhones. > The goal isn’t that Apple competes “fairly” on any arbitrary platform, it’s specifically that Apple competes “fairly” on the platform that Apple puts their best features on. It's about putting features on the platform which are beneficial only to other products of Apple. The goal is that if Apple offers products on the market it is gatekeeping, it does so in a way that doesn't hinder fair competition on that market. Apple competing on headphones for iPhones while offering features that require iOS functionality not accessible to competitors is not fair competition.
- regularjack 2y agoApple can afford maintaining the public APIs.
- sealeck 2y agoApple can change the API interfaces as they see fit, no?
- tpmoney 2y agoPhysically can they? Sure. But there’s costs associated with that too. They’re clearly not hugely concerned with developer relations right now, but an ever changing “public” api certainly can annoy and drive off your developers in a way that a private and non existent api won’t. Likewise there’s an argument to be made that a constantly changing public API is also anti-competitive. If every iOS release winds up with breaking changes that force developers to update their devices and kill off devices that aren’t being updated anymore is that really any better than a private API? We already see a lot of anger over Apple dropping 32 bit libraries or how quickly they drop developer support for older OS versions and “force” developers to keep making updates to stay current on their public APIs.
- makeitdouble 2y agoIf your question is whether it will be more work for Apple, the answer is yes, to some point. If you're also wondering whether Apple being mildly inconvenienced matters for the EU court or most users in general: honestly no. They're at fault in the first place, and if for a new feature that took 2 years to build, users have to wait some extra months because of that decision, so be it IMHO. That has always been happening with the US only launch features, and nobody's been crying a river.