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

71–80 of 102 posts

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

#71

Post by Daishiman »

marshray wrote: post #67
oakwhiz wrote: post #41

Earlier quoted context omitted.

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"...

Isn't it kinda the kernel's job to allow multiple processes to access shared resources? Imagine if only one process at a time were allowed to access the disk.

Resources that require low-latency low-level access cannot be multiplexes easily

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

#72

Post by Daishiman »

stelonix wrote: post #60
jlgreco wrote: post #56

Earlier quoted context omitted.

JACK is not apart of the standard Linux sound experience for anybody but sound technicians or musicians. I'll fully concede that this particular situation may be shit, but it does not represent the typical Linux user, or even the typical Linux power user, experience. Can't say I've ever noticed Pulse latency, even while playing Quake, except when using Pulse's networking features. Maybe I have crude ears.

I'm trying to convey the fact that you need something like JACK in order to do real time audio DSP, while in Windows/Mac, it just works. More importantly, in 2013, per-application volume control should be a given. It's possible under Pulse AFAIK, just not under ALSA. It may not represent the typical Linux users, but while audio processing also doesn't represent the typical PC user, it works under mainstream operating…

> I'm trying to convey the fact that you need something like JACK in order to do real time audio DSP, while in Windows/Mac, it just works.

There's a ton of Windows applications that take over audio and do a lot of driver weirdness. There's still ASIO incompatibilies, latency issues, etc. In fact it happens in the same space where PulseAudio and JACK intersect on Windows.

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

#73

Post by synchronise »

bitwize wrote: post #51
efuquen wrote: post #27

Earlier quoted context omitted.

I think you're mistaking what is probably largely a political issue for a technical one. The sense I get here is that there is nothing technically wrong with the patch, it's not like Intel went back to Ubuntu and said you have to fix X Y & Z to get this merged. They initially accepted the patch and only after having accepted it on technical grounds they've come back and rejected it because Mir isn't the horse they're…

Intel is acting in the best interests of the community, which almost unilaterally backs Wayland. Linux is not about choice[0]. It's 2013, and the hard lesson that choice is death to a reliable platform should have been well-learned by now, if by nothing else than by the sheer fact that Apple steamrolled the Unix workstation market into oblivion. Mac OS -- which provides comparatively little choice -- grows YoY, where…

Apostasy needs to be punished, that's 21st century thinking right there.

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

#74

Post by synchronise »

worldsayshi wrote: post #59
wmf wrote: post #45

Earlier quoted context omitted.

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

Does anyone know why?

It has been implied that it's so other devices couldn't as easily implement their 'convergence device' idea as they could have with Wayland.

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

#75

Post by barrkel »

jlgreco wrote: post #55
barrkel wrote: post #52

Earlier quoted context omitted.

Did you try nVidia graphics + UEFI bios + encrypted disk? Wasted a whole day at work with that one. The nVidia drivers don't support framebuffer consoles, only VGA, but UEFI doesn't provide VGA console I/O. And an encrypted disk needs human interaction to type the password in at bootup, meaning some kind of graphical support. Meanwhile, the non-proprietary drivers crash the X server if you so much as jiggle a window…

"Did you try nVidia graphics + UEFI bios + encrypted disk?" Not with proprietary drivers. AMD/NVidia's failure to produce usable drivers of their own isn't particularly relevant as far as I am concerned. In fact, it serves to highlight just how good the the FOSS drivers are at "just working". "Meanwhile, the non-proprietary drivers crash the X server if you so much as jiggle a window about." That makes absolutely no…

It's a fact, verified on two brand new identical spec machines side by side, with GTX 670 cards. I have multiple witnesses!

All you had to do to crash X was move a window quickly from side to side. The proprietary drivers are infinitely better in so far as they don't crash.

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

#77

Post by gph »

synchronise wrote: post #73
bitwize wrote: post #51

Earlier quoted context omitted.

Intel is acting in the best interests of the community, which almost unilaterally backs Wayland. Linux is not about choice[0]. It's 2013, and the hard lesson that choice is death to a reliable platform should have been well-learned by now, if by nothing else than by the sheer fact that Apple steamrolled the Unix workstation market into oblivion. Mac OS -- which provides comparatively little choice -- grows YoY, where…

Apostasy needs to be punished, that's 21st century thinking right there.

If Linux is ever to become mainsteam the way OSX and Windows are then 'apostasy' needs not be accommodated.

Now you can debate whether the philosophy of the Linux and open-source community is for creating a standardized product that can be easily adopted and used by the mainstream user-base. But for companies like Intel, I understand why they want to push it in that direction.

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

#78

Post by kazagistar »

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 hardware supports it. The specs are open. But they don't have to take responsibility for any patch that rolls their way. When you accept a patch like this, that means you have to be responsible for fixing it if it breaks. If Ubuntu wants to make their own window manager separate from everyone else, they can maintain their own Intel driver patches too.

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

#79

Post by eltondegeneres »

dkuntz2 wrote: post #69
tga_d wrote: post #33

Earlier quoted context omitted.

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.

Some argue that if it makes calls to a GPL application, it's a derivative work, which means it must also be GPL. This means that if one part of the stack is GPL, everything higher must also be GPL.

Can you point me towards some people arguing this? It's patently false. If it were true, every single application on your typical GNU/Linux box would also be GPL.

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

#80

Post by SEJeff »

raldi wrote: post #76

Can someone summarize the story in a way that doesn't presuppose prior knowledge of what Mir or XMir is, and who isn't familiar with the Ubuntu-Intel history? Free karma if you do!

X.org is an ancient beast that works, but is creaky. Intel has really been leading the charge to develop a new display server named Wayland. After much publicity from none other than Mark Shuttleworth about how Ubuntu was going to adopt Wayland, they decided to write their own display server from scratch named XMir.

They want to use the same code for Ubuntu on phones, desktops, tablets. Intel doesn't much care to support anything other than Wayland because after 10+ years of X.org, they know better than anyone (most of all Canonical) what is best when it comes to display servers. They are putting all of their weight behind Wayland and don't see XMir as a viable future. As a result, they made a decision to not support it upstream.

Their driver their call. Seems relatively cut and dry to me. As usual, another case where Canonical can't play with the rest of the open source community.

Edit to add all below:

I would also highly suggest anyone curious to read:

http://www.phoronix.com/scan.php?page=article&item=x_wayland...

http://mjg59.dreamwidth.org/26254.html

Those two articles are both critical of Mir, but are also from some very senior developers in the low level Linux/X related plumbing of Linux. I'd argue they are more qualified to speak about the failings of X than the Mir developers primarily because they've been the people fixing it's bugs the past many years.

Post reply on HN