Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

arstechnica.com

Post reply on HN
Print view View original

41–50 of 102 posts

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

#41

Post by oakwhiz »

jmillikin wrote: post #14
gaius wrote: 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…

Another problem with PulseAudio is with latency and routing, which is why a lot of professional audio programs on Linux use JACK instead of PulseAudio. It's sometimes very hard to get JACK to play nice with PulseAudio, and this is exacerbated by the fact that ALSA only allows one program to use one audio device at a time. So it doesn't always "just work"...

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

#42

Post by [deleted] »

jmillikin wrote: post #14
gaius wrote: 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…

[deleted]

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

#43

Post by qznc »

wmf wrote: post #39
ChuckMcM wrote: post #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…

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.

Nearly,correct. s/Then/Meanwhile/

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

#44

Post by ldng »

wmf wrote: post #40
spacelizard wrote: post #30

Earlier quoted context omitted.

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.

Hence the copyright assignment required for any contribution to Canonical's projects, to ease the double licensing.

But for now, it's only speculation. Time will tell.

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

#45

Post by wmf »

qznc wrote: post #43
wmf wrote: post #39

Earlier quoted context omitted.

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.

Nearly,correct. s/Then/Meanwhile/

Ubuntu initially agreed to use Wayland, then they changed their minds and invented Mir.

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

#46

Post by ikt »

jlgreco wrote: post #32
jmillikin wrote: post #14

Earlier quoted context omitted.

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…

My HTPC has the desktop off the top of the TV and frequently the HDMI audio doesn't work.

With my ATI graphics card on my desktop I have a script that runs on startup to force the display drive to to detect my 1920x1080 monitor otherwise it displays the screen with big black bars all around the edges.

Audio and video are still a pita for me.

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

#47

Post by ikt »

ginko wrote: post #24
toyg wrote: post #20

Earlier quoted context omitted.

Well, what is stopping NVidia and AMD from cooperating on Wayland right now ? When you look at it from this perspective, a shadowy doubt is cast over Canonical's motivations.

This is the part that irritates me most about Mir: By rolling their own display server, Canonical has set back efforts to get all display vendors on board for supporting Wayland. If Ubuntu would have switched used Wayland (along with the other distributions), there would have been a very strong incentive for all vendors to support this in their drivers.

If Red Hat had supported .deb packages maybe packaging wouldn't be such a pain in the ass and we wouldn't have a .tar, .deb and a .rpm for every program.

There are a lot of things in linux land that don't make sense, I think picking on Canonical for choosing to do what they want as opposed to all the others who are choosing to do what they want, is very un linux like.

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

#48

Post by jlgreco »

ikt wrote: post #46
jlgreco wrote: post #32

Earlier quoted context omitted.

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…

My HTPC has the desktop off the top of the TV and frequently the HDMI audio doesn't work. With my ATI graphics card on my desktop I have a script that runs on startup to force the display drive to to detect my 1920x1080 monitor otherwise it displays the screen with big black bars all around the edges. Audio and video are still a pita for me.

Proprietary driver I assume? That always has been, and always will be (as far as my crystal ball permits me to see), a clusterfuck. If you opt-in to that sort of pain, don't act surprised when you receive pain.

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

#49

Post by stelonix »

jlgreco wrote: post #32
jmillikin wrote: post #14

Earlier quoted context omitted.

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…

Audio just works if you're not a power user, or use only programs compatible with each other. Try using a JACK application alongside an ALSA one and you'll see it doesn't "just work".

Even then, if you stick to ALSA applications, you'll have a few issues:

1) You're going to be limiting yourself to a lot less possibilities (Skype uses Pulse, IIRC, for example)

2) You can't have simple settings such as per-application volume control.

Sure it "just works", but it does if you use a set of programs which only the people who say "it just works" (a lot of people, I know) restrict themselves to. While it may work for you, different people have different needs.

I'm still waiting for the day Linux audio (and video, but less hopeful because of proprietary drivers) simply works in the same way it does under Windows/Mac.

Footnote: I completely forgot to mention latency issues, which is awful for audio processing.

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

#50

Post by ginko »

ikt wrote: post #47
ginko wrote: post #24

Earlier quoted context omitted.

This is the part that irritates me most about Mir: By rolling their own display server, Canonical has set back efforts to get all display vendors on board for supporting Wayland. If Ubuntu would have switched used Wayland (along with the other distributions), there would have been a very strong incentive for all vendors to support this in their drivers.

If Red Hat had supported .deb packages maybe packaging wouldn't be such a pain in the ass and we wouldn't have a .tar, .deb and a .rpm for every program. There are a lot of things in linux land that don't make sense, I think picking on Canonical for choosing to do what they want as opposed to all the others who are choosing to do what they want, is very un linux like.

The difference is that the choice of package system is completely in the domain of open source software. Proprietary drivers require support by hardware vendors.

If we had solid, feature-complete open source graphics drivers this wouldn't be an issue.

Post reply on HN