4 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 chan

> 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 ago
Agreed 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 ago
      The 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.
      - tpmoney 2y ago
        > The market being the sum of iPhone end-users buying other stuff than iPhones. Which seems a little ridiculously narrow doesn’t it? Why does any hardware vendor have an obligation to open all of their APIs and functionality to all comers just because they open some of them? Why is selling a highly sandboxed product not a valid thing to do? And especially why is that not valid when there is an entire other half+ of the market that is completely open and exactly the sort of free for all people are apparently looking for? Ultimately it always comes down to this. Apple is one vendor, selling one piece of hardware that runs one OS. You can not buy or run iOS on anything other than Apple supplied phones. You can not run anything on an iPhone except an Apple supplied OS. Apple does not force carriers or retailers to exclusively carry Apple phones. They don’t require hardware manufacturers to buy iOS licenses even when they sell a phone without iOS. They don’t require 3rd party iOS developers to sign exclusivity contracts when developing for iOS. They don’t fine developers for making better versions of their software for other platforms. They don’t do those things for accessory manufacturers either. Apple sells Apple phones that run Apple software in a way that Apple feels is best for that phone. Why is this a problem? Yes I understand that iPhone users who want a pebble smart watch are given a worse experience. But they don’t have to use an iPhone. Nothing at all stops them from buying any of the hundreds of Android phones on the market and having the ultimate pebble smart watch experience. This whole thing feels like the equivalent of demanding the government force GM to support CarPlay. GM has decided they don’t want to do that. They think they can sell a better product without it. That might suck for people who want a Chevy and also want to use CarPlay, but is that really unfair competition and worthy of government regulation to force GM to open up their in-car entertainment systems?
- lucyjojo 2y ago
  i do not know about ios as i don't own an iphone, but sound has sucked on macos for every single macbook i have had the displeasure to use. - random full drop (have a little script to reboot the stack) - device aggregation failing when i add my motu interface and no obvious way to debug it (that's on a mac mini) - random semi-persistent stuttering when linking my mixer to my macbook via bluetooth (which did not happen on windows) windows has not given me pain around audio for the longest time. for some reason my ipad has been running smooth though, no complaint even with semi-exotic stuff
- kennysoona 2y ago
  > 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. This sounds very much like an edge case. Why didn't you use Windows or MacOS on the mini PC instead? Was it because you were unable to do so? > Or how about the huge fight that systemd has been (and continues to be). That fight was over pretty much when Devuan and Artix formed. > If we imagine a world where os init was regulated by the EU, The EU would only be interested in regulating this if it were an OS init controlled by a monopoly abusing their position.
  - tpmoney 2y ago
    >This sounds very much like an edge case. https://www.google.com/search?hl=en&q=linux%20radeon%20audio%20hdmi%20muted https://www.google.com/search?hl=en&q=linux%20radeon%20audio... > Why didn't you use Windows or MacOS on the mini PC instead? Was it because you were unable to do so? Because despite what you might assume from reading what I've written here today, I'm not against or opposed to open source and open protocol stuff. Everything I personally write I release open source. I push my own company to publish as much as we can as open protocols. I've been running some form of linux in one form or another since I first pulled down the MkLinux CDs over a 33.6 modem. I don't hate open systems. But I recognize that open systems have their own disadvantages and that a system being open doesn't inherently mean it's going to be a better experience or solution. > The EU would only be interested in regulating this if it were an OS init controlled by a monopoly abusing their position. And so as I've asked before in other places, what monopoly are they regulating here? If the other comments in this discussion are to be believed, iOS represents < 50% of the EU market. Not only that, but iOS represents a single os and a single hardware vendor. The only way to run iOS is to buy Apple hardware, and the only OS you can run on the Apple hardware is iOS. Meanwhile the entire rest of the cellphone market exists, has a fully open OS just like people want, and supposedly has an equal or superior experience to iPhone/iOS. Apple doesn't do anything to prevent retailers from selling non-Apple devices, they don't require app developers to sign exclusivity agreements, they don't require accessory vendors to sign exclusivity agreements. They don't require retailers to buy iOS licenses even for hardware sold without iOS. The only way one can construe Apple to have a monopoly is to say that they have a monopoly on the hardware that they manufacture. Which is a tautology. Sony has a monopoly on their TVs, Bose has a monopoly on their stereos, and Nintendo has a monopoly on their consoles. This is not a useful definition of a "market"
- rstuart4133 2y ago
  > How many years will it be before audio on the Linux OS doesn’t suck? Bad example. It's a bad example because in order to achieve that Linux has has many, many sound API's over the years. Most of them interacted in bad ways. Often the new boy on the block had emulate all the previous ones to have a hope of being adopted. If a great, reliable sound system depended on the ability to iterate on API's Linux's should have been stellar in very short order. That said, Linux's sound is very good now. Echoing other responses here, it's now much better than MacOS. Given your your "easy and painless" comment about it, I'm wondering it you've used a modern mac. "You can't hear me? Wait, while I turn sound off and or, restart the app, restart the laptop" is a very familiar ritual now work forces me to use a mac. As for standard's causing ossification - you're wrong on that too. What causes ossification is a wide deployment. Once it's out there you can't change the API without breaking all the deployments. Yes, a successful standard means it's been widely deployed, but it doesn't cause it. Apple has so many watches out there it can't make breaking changes to the API it uses to talk to the iPhone. Publishing that API as a standard doesn't change that. The way you fix API fragility isn't by avoiding standards. A successful API will become a defacto standard - whether you want it to or not. You fix the issue by designing your API's so they can be upgraded. This is why Google's Protocol Buffers allow you to add stuff at the end, and IP has a version field. Without those things API's based on Protocol Buffers would be hard to change, and we could never have had IPv6.
  - tpmoney 2y ago
    > Often the new boy on the block had emulate all the previous ones to have a hope of being adopted. > ... > Once it's out there you can't change the API without breaking all the deployments. Yes, a successful standard means it's been widely deployed, but it doesn't cause it. Yes, that was the point. A public API in use by its very nature will have negative impacts on future development of that API. Or as I put it in the original comment: "Open protocols are great but they are also absolutely a hinderance on change" > Apple has so many watches out there it can't make breaking changes to the API it uses to talk to the iPhone. Publishing that API as a standard doesn't change that. They can, all they have to do is push out an update for those watches. That's the point. Because that API is private an exclusively used by Apple and Apple's software, they can replace it as many times as they want provided they are willing to push the updates. On the other hand, if hundreds of third parties are using that API independently, even if they push an update they still have to contend with a whole ecosystem of products that will or won't update on whatever schedule those developers feel like operating on. Apple already catches a bunch of flak for the speed at which they update and abandon their current public APIs, hardly an incentive to also open up their private APIs. > Without those things API's based on Protocol Buffers would be hard to change, and we could never have had IPv6. I'm not sure I'd call the transition to IPv6 an example of a resounding success of fast iteration on a change to a protocol or API. It's only been 30 years and we're still using IPv4 for most things and slapping band-aid upon band-aid on the problems, never mind the list of headache switching to exclusive IPv6 (for example, unless something has changed recently, you still can't use DHCPv6 to manage IPs for android devices)

tpmoney 2y ago

Agreed 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 ago
    The 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.
    - tpmoney 2y ago
      > The market being the sum of iPhone end-users buying other stuff than iPhones. Which seems a little ridiculously narrow doesn’t it? Why does any hardware vendor have an obligation to open all of their APIs and functionality to all comers just because they open some of them? Why is selling a highly sandboxed product not a valid thing to do? And especially why is that not valid when there is an entire other half+ of the market that is completely open and exactly the sort of free for all people are apparently looking for? Ultimately it always comes down to this. Apple is one vendor, selling one piece of hardware that runs one OS. You can not buy or run iOS on anything other than Apple supplied phones. You can not run anything on an iPhone except an Apple supplied OS. Apple does not force carriers or retailers to exclusively carry Apple phones. They don’t require hardware manufacturers to buy iOS licenses even when they sell a phone without iOS. They don’t require 3rd party iOS developers to sign exclusivity contracts when developing for iOS. They don’t fine developers for making better versions of their software for other platforms. They don’t do those things for accessory manufacturers either. Apple sells Apple phones that run Apple software in a way that Apple feels is best for that phone. Why is this a problem? Yes I understand that iPhone users who want a pebble smart watch are given a worse experience. But they don’t have to use an iPhone. Nothing at all stops them from buying any of the hundreds of Android phones on the market and having the ultimate pebble smart watch experience. This whole thing feels like the equivalent of demanding the government force GM to support CarPlay. GM has decided they don’t want to do that. They think they can sell a better product without it. That might suck for people who want a Chevy and also want to use CarPlay, but is that really unfair competition and worthy of government regulation to force GM to open up their in-car entertainment systems?
lucyjojo 2y ago
i do not know about ios as i don't own an iphone, but sound has sucked on macos for every single macbook i have had the displeasure to use. - random full drop (have a little script to reboot the stack) - device aggregation failing when i add my motu interface and no obvious way to debug it (that's on a mac mini) - random semi-persistent stuttering when linking my mixer to my macbook via bluetooth (which did not happen on windows) windows has not given me pain around audio for the longest time. for some reason my ipad has been running smooth though, no complaint even with semi-exotic stuff
kennysoona 2y ago
> 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. This sounds very much like an edge case. Why didn't you use Windows or MacOS on the mini PC instead? Was it because you were unable to do so? > Or how about the huge fight that systemd has been (and continues to be). That fight was over pretty much when Devuan and Artix formed. > If we imagine a world where os init was regulated by the EU, The EU would only be interested in regulating this if it were an OS init controlled by a monopoly abusing their position.
- tpmoney 2y ago
  >This sounds very much like an edge case. https://www.google.com/search?hl=en&q=linux%20radeon%20audio%20hdmi%20muted https://www.google.com/search?hl=en&q=linux%20radeon%20audio... > Why didn't you use Windows or MacOS on the mini PC instead? Was it because you were unable to do so? Because despite what you might assume from reading what I've written here today, I'm not against or opposed to open source and open protocol stuff. Everything I personally write I release open source. I push my own company to publish as much as we can as open protocols. I've been running some form of linux in one form or another since I first pulled down the MkLinux CDs over a 33.6 modem. I don't hate open systems. But I recognize that open systems have their own disadvantages and that a system being open doesn't inherently mean it's going to be a better experience or solution. > The EU would only be interested in regulating this if it were an OS init controlled by a monopoly abusing their position. And so as I've asked before in other places, what monopoly are they regulating here? If the other comments in this discussion are to be believed, iOS represents < 50% of the EU market. Not only that, but iOS represents a single os and a single hardware vendor. The only way to run iOS is to buy Apple hardware, and the only OS you can run on the Apple hardware is iOS. Meanwhile the entire rest of the cellphone market exists, has a fully open OS just like people want, and supposedly has an equal or superior experience to iPhone/iOS. Apple doesn't do anything to prevent retailers from selling non-Apple devices, they don't require app developers to sign exclusivity agreements, they don't require accessory vendors to sign exclusivity agreements. They don't require retailers to buy iOS licenses even for hardware sold without iOS. The only way one can construe Apple to have a monopoly is to say that they have a monopoly on the hardware that they manufacture. Which is a tautology. Sony has a monopoly on their TVs, Bose has a monopoly on their stereos, and Nintendo has a monopoly on their consoles. This is not a useful definition of a "market"
rstuart4133 2y ago
> How many years will it be before audio on the Linux OS doesn’t suck? Bad example. It's a bad example because in order to achieve that Linux has has many, many sound API's over the years. Most of them interacted in bad ways. Often the new boy on the block had emulate all the previous ones to have a hope of being adopted. If a great, reliable sound system depended on the ability to iterate on API's Linux's should have been stellar in very short order. That said, Linux's sound is very good now. Echoing other responses here, it's now much better than MacOS. Given your your "easy and painless" comment about it, I'm wondering it you've used a modern mac. "You can't hear me? Wait, while I turn sound off and or, restart the app, restart the laptop" is a very familiar ritual now work forces me to use a mac. As for standard's causing ossification - you're wrong on that too. What causes ossification is a wide deployment. Once it's out there you can't change the API without breaking all the deployments. Yes, a successful standard means it's been widely deployed, but it doesn't cause it. Apple has so many watches out there it can't make breaking changes to the API it uses to talk to the iPhone. Publishing that API as a standard doesn't change that. The way you fix API fragility isn't by avoiding standards. A successful API will become a defacto standard - whether you want it to or not. You fix the issue by designing your API's so they can be upgraded. This is why Google's Protocol Buffers allow you to add stuff at the end, and IP has a version field. Without those things API's based on Protocol Buffers would be hard to change, and we could never have had IPv6.
- tpmoney 2y ago
  > Often the new boy on the block had emulate all the previous ones to have a hope of being adopted. > ... > Once it's out there you can't change the API without breaking all the deployments. Yes, a successful standard means it's been widely deployed, but it doesn't cause it. Yes, that was the point. A public API in use by its very nature will have negative impacts on future development of that API. Or as I put it in the original comment: "Open protocols are great but they are also absolutely a hinderance on change" > Apple has so many watches out there it can't make breaking changes to the API it uses to talk to the iPhone. Publishing that API as a standard doesn't change that. They can, all they have to do is push out an update for those watches. That's the point. Because that API is private an exclusively used by Apple and Apple's software, they can replace it as many times as they want provided they are willing to push the updates. On the other hand, if hundreds of third parties are using that API independently, even if they push an update they still have to contend with a whole ecosystem of products that will or won't update on whatever schedule those developers feel like operating on. Apple already catches a bunch of flak for the speed at which they update and abandon their current public APIs, hardly an incentive to also open up their private APIs. > Without those things API's based on Protocol Buffers would be hard to change, and we could never have had IPv6. I'm not sure I'd call the transition to IPv6 an example of a resounding success of fast iteration on a change to a protocol or API. It's only been 30 years and we're still using IPv4 for most things and slapping band-aid upon band-aid on the problems, never mind the list of headache switching to exclusive IPv6 (for example, unless something has changed recently, you still can't use DHCPv6 to manage IPs for android devices)