Live data from Hacker News

Intel rejection of Ubuntu’s Mir patch forces Canonical to go own way

arstechnica.com

31–40 of 102 posts

Re: Intel rejection of Ubuntu’s Mir patch forces Canonical to go own way

#31
post #16
post #8

Earlier quoted context omitted.

Beyond that, it may be because Mir is GPLv3 licensed and Wayland is MIT licensed. Just a hunch.

Oh I didn't even know that. That's a great reason to prefer Wayland over Mir or Mir over Wayland. I'm a bit torn now..

Not really. I much prefer the GPL, since I think copyleft is (at least partly) what has made Linux the massive success it is, and I think a copyleft licence for a display server would similarly be better. But in this situation, I have to support Wayland over Mir. The reason largely being that Wayland vs. Mir actually gives credence to the argument that Linux can't succeed on the desktop because of fragmentation. Normally in response to that argument, I'd say it's not that big of a deal, and that things like different package managers and desktop environments keep a healthy level of competition, while still having a great amount of cooperation. But when it comes to display servers, we're talking about something that requires driver support, which is already one of (if not the) top problems on GNU/Linux. Forcing the small teams that deal with Linux graphics driver development to choose between using their already limited time to support the general standard or what the most popular distro uses is a horrible decision.

Re: Intel rejection of Ubuntu’s Mir patch forces Canonical to go own way

#32
post #2

Watch Linux video go the way of Linux audio... Intel are 100% in the right to make a stand.

I wish Linux video would go the way of Linux audio. Linux audio just works. There's a single userspace API (PulseAudio), a single kernel driver API (ALSA), and all the old nastiness of the '90s (ESD, aRts, OSS) is dead and gone. In contrast, getting video to work properly involves figuring out what hardware you're running (nVidia? ATI/AMD? Intel? misc other?), then hunting down the drivers, installing them, rebooting…

Frankly both audio and video "just work" in Linux, and have for years. It has been several years since I bothered to look up what chips a computer had and what Linux support was like before making a purchase.

I just buy the hardware I want, assume it will work, and find that it does. Maybe I've been getting lucky, but I don't think so.

The only real remaining pain in the ass is printer support, but who the hell uses printers these days?

Re: Intel rejection of Ubuntu’s Mir patch forces Canonical to go own way

#33
post #16

Earlier quoted context omitted.

Oh I didn't even know that. That's a great reason to prefer Wayland over Mir or Mir over Wayland. I'm a bit torn now..

Not really. GPLv3 will prevent hardware manufacturers from locking down their devices if they intend to ship Ubuntu Mobile. This is a good thing for users of those devices. I can't defend Canonical's support of proprietary drivers, especially on these devices that are known to be used for such pervasive spying, but at least a non-hardware-locked device allows for workarounds (i.e. deployment of your own free drivers)…

I'm sorry, but must be missing something. How does a GPLv3 display server prevent locking down the hardware? Afaik, the anti-TiVoization stuff only applies to the software that's GPLv3, not the stack it's running on.

Re: Intel rejection of Ubuntu’s Mir patch forces Canonical to go own way

#34
post #2

Watch Linux video go the way of Linux audio... Intel are 100% in the right to make a stand.

I wish Linux video would go the way of Linux audio. Linux audio just works. There's a single userspace API (PulseAudio), a single kernel driver API (ALSA), and all the old nastiness of the '90s (ESD, aRts, OSS) is dead and gone. In contrast, getting video to work properly involves figuring out what hardware you're running (nVidia? ATI/AMD? Intel? misc other?), then hunting down the drivers, installing them, rebooting…

I've had real problems with the display stack once in the last maybe 10 years. And that was simply a case of the software support for Ivy Bridge not being released far enough before the hardware, and thus not supported out of the box on the latest stable release of anything at the time. (Of course our criteria for working might be different -- I care about stuff showing up on my monitor and X not crashing. Couldn't care less about kernel modesetting).

In contrast, audio tends to randomly completely break after every other update. Most recent major breakage I had: for one whole Fedora release, the headset mic input would not work in the one app where I need it to work (Skype). Worked fine on the previous and next releases, with the same Skype binary.

Minor problems that can be worked around just randomly come and go. Right now one one machine all audio playback will stop working every few days, until pulseaudio is killed. Another computer randomly goes to a mode where all audio playback from Chrome is accelerated by IIRC 7%. Just enough to make you uneasy due to things being off somehow, but not enough to make obvious that there's a problem. This persists until pulseaudio is killed and restarted, of course, which magically fixes things.

Re: Intel rejection of Ubuntu’s Mir patch forces Canonical to go own way

#35
I find the dissonance of this conversation and the optimism of Gabe Newell in the "Gaming on Linux" article fascinating.

Graphics has been screwed up on Linux ever since the 3dfx Voodoo 1 and nVidia TNT wars. It spilled over into the ARM SoC space.

I don't know what the answer is, but I recognize that chip companies not supporting someone's efforts to make their software useful on that company's chip for more people is mind boggling.

Re: Intel rejection of Ubuntu’s Mir patch forces Canonical to go own way

#36

I find the dissonance of this conversation and the optimism of Gabe Newell in the "Gaming on Linux" article fascinating. Graphics has been screwed up on Linux ever since the 3dfx Voodoo 1 and nVidia TNT wars. It spilled over into the ARM SoC space. I don't know what the answer is, but I recognize that chip companies not supporting someone's efforts to make their software useful on that company's chip for more people…

It's about maintaining a clean codebase. If a maintainer believes that a proposal is genuinely the wrong way to achieve a goal, it is counterproductive to accept it. This happens all the time in the Linux kernel for instance, where one or more further iterations are required to get something accepted. It's just juvenile to stamp ones feet because some upstream disagrees with a particular approach. You argue the technical merits, and then you live with their decision by going your own way or revamping your submission. It's hard to imagine open source working any other way.

Re: Intel rejection of Ubuntu’s Mir patch forces Canonical to go own way

#37

I find the dissonance of this conversation and the optimism of Gabe Newell in the "Gaming on Linux" article fascinating. Graphics has been screwed up on Linux ever since the 3dfx Voodoo 1 and nVidia TNT wars. It spilled over into the ARM SoC space. I don't know what the answer is, but I recognize that chip companies not supporting someone's efforts to make their software useful on that company's chip for more people…

[deleted]

Re: Intel rejection of Ubuntu’s Mir patch forces Canonical to go own way

#38
post #36

I find the dissonance of this conversation and the optimism of Gabe Newell in the "Gaming on Linux" article fascinating. Graphics has been screwed up on Linux ever since the 3dfx Voodoo 1 and nVidia TNT wars. It spilled over into the ARM SoC space. I don't know what the answer is, but I recognize that chip companies not supporting someone's efforts to make their software useful on that company's chip for more people…

It's about maintaining a clean codebase. If a maintainer believes that a proposal is genuinely the wrong way to achieve a goal, it is counterproductive to accept it. This happens all the time in the Linux kernel for instance, where one or more further iterations are required to get something accepted. It's just juvenile to stamp ones feet because some upstream disagrees with a particular approach. You argue the techn…

I thought it was more about making it impossible to use GPUs to guide cruise missiles, but that might be a bit presumptuous.

Re: Intel rejection of Ubuntu’s Mir patch forces Canonical to go own way

#39

I find the dissonance of this conversation and the optimism of Gabe Newell in the "Gaming on Linux" article fascinating. Graphics has been screwed up on Linux ever since the 3dfx Voodoo 1 and nVidia TNT wars. It spilled over into the ARM SoC space. I don't know what the answer is, but I recognize that chip companies not supporting someone's efforts to make their software useful on that company's chip for more people…

The answer to un-screwing Linux graphics is Wayland, and every major player in the ecosystem agreed to it. Then Ubuntu decided to go their own way so the other players are freezing Ubuntu out.

Re: Intel rejection of Ubuntu’s Mir patch forces Canonical to go own way

#40
post #16

Earlier quoted context omitted.

Oh I didn't even know that. That's a great reason to prefer Wayland over Mir or Mir over Wayland. I'm a bit torn now..

Not really. GPLv3 will prevent hardware manufacturers from locking down their devices if they intend to ship Ubuntu Mobile. This is a good thing for users of those devices. I can't defend Canonical's support of proprietary drivers, especially on these devices that are known to be used for such pervasive spying, but at least a non-hardware-locked device allows for workarounds (i.e. deployment of your own free drivers)…

GPLv3 will prevent hardware manufacturers from locking down their devices if they intend to ship Ubuntu Mobile.

Actually the opposite; Canonical will sell phone vendors a non-GPL version of Mir so that they can lock down their phones.

Post reply on HN