hi all, to my understanding the above are like WINE in that they try to remedy an unideal situation and thus have to operate with older protocols. is that understanding correct or are they independent / capable of being independent

  • hallettj@beehaw.org
    link
    fedilink
    English
    arrow-up
    28
    ·
    11 months ago

    Wayland replaces the older X protocol. It doesn’t have to operate with older protocols. You might be thinking of XWayland which is a proxy that receives X API calls from apps written for X, and translates those to the Wayland API so that those apps can run under Wayland implementations. Window managers can optionally run XWayland, and many do. But as more apps are updated to work natively with Wayland, XWayland becomes less important, and might fade away someday.

    PipeWire replaces PulseAudio (the most popular sound server before PipeWire). Systems running PipeWire often run pipewire-pulse which does basically the same thing that XWayland does - it translates from the PulseAudio API to the PipeWire API. It’s a technically optional, but realistically necessary compatibility layer that may become less relevant over time if apps tend to update to work with PipeWire natively.

    So no, both Wayland and PipeWire are capable of operating independently of other protocols.

    • jackpotOP
      link
      fedilink
      arrow-up
      9
      ·
      11 months ago

      youre right i was thinking of xwayland, tysm. also, yes i was thinking of pipewire-pulse. i was worried these compatibility layers WERE the programs in their entirety. as in, they had no protocols themselves but rather optimised older, deprecated ones.

  • Rustmilian@lemmy.world
    link
    fedilink
    English
    arrow-up
    11
    ·
    edit-2
    11 months ago

    Pipewire is a modern audio server that can drop-in replace the mess that is alsa, pulse audio, jack, etc.

    Wayland is a communication protocol made to be a replacement for the X11 protocols, with it’s compositer implementations being the replacement for Xorg.

  • PseudoSpock@lemmy.dbzer0.com
    link
    fedilink
    arrow-up
    4
    arrow-down
    1
    ·
    11 months ago

    Wait what? I’m no fan of Wayland, but what you just said, I’m afraid, is all wrong.

    1. Wayland, although being around for over a decade, is the newer protocol. The older protocol would be X11.
    2. Pipewire is also the new kid on the block, for audio. PulseAudio would be the older one being replaced.
    3. WINE is a Windows compatibility layer or wedge. It stands for Wine Is Not an Emulator, if I recall.

    Wayland seeks to provide a newer display standard, as I keep being told (forcefully and repeatedly) X11 is not sustainable… There’s a lot about that we don’t need to rehash here, but long story short, In with the new (Wayland), and sooner or later, out with the old (X11).

    Pipewire is meant to be a replacement for PulseAudio, and near as I can tell, quite backwards compatible.

    WINE is to run Windows application on Linux. Like many Linux applications right now, it is being updated to support Wayland (I believe that’s well underway already) and it already works fine with Pipewire. WINE will work on X11 and Wayland.

    Lastly, what do you mean by weaker systems? X11 is weak when it comes to being security conscious. Part of Wayland’s mission is to address that by being far more secure by default. Pipewire, while maintaining backwards compatibility, is able to do more things, as well, than the original PulseAudio.

    • jackpotOP
      link
      fedilink
      arrow-up
      1
      ·
      11 months ago

      scroll down and read hallet’s comment amd my reply, it’ll clear confusion. thank you for the explainwr!!

  • leanleft
    link
    fedilink
    English
    arrow-up
    2
    ·
    11 months ago

    linux is old too. we should reinvent it.

    • Auli@lemmy.ca
      link
      fedilink
      English
      arrow-up
      5
      ·
      11 months ago

      The thing is Linux continuously gets things added and sometimes dropped. And the coding they was done in X would never be allowed in the Linux kernel.