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

51–60 of 102 posts

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

#51

Post by bitwize »

efuquen wrote: post #27
WestCoastJustin wrote: post #18

Earlier quoted context omitted.

I don't really see why Ubuntu is getting bent out of shape about this. Maybe this is just a media/blogger generated grudge. Many very popular open source packages are maintained out of stream before getting pushed upstream. DRBD [1] was a very popular package which, after years of patches, finally got accepted into the kernel. I think there is a burden of proof required before asking someone to maintain your patch se…

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, whereas non-Mac desktop Unix, including Linux, has faded into statistical noise.

If non-Android Linux is going to claw its way back into relevance, then the community needs to decide on one framework for graphics, one for sound, etc. and back them wholeheartedly. It is a technical issue because focusing all developer effort on one good thing produces better technical results than splintering it among a dozen mediocre things. Apostasy needs to be punished, and that's what Intel has done.

[0] http://www.redhat.com/archives/rhl-devel-list/2008-January/m...

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

#52

Post by barrkel »

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…

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

Your best bet with desktop Linux is still to buy old, cheap, common-denominator hardware. Anything recent is a gamble unless you're very technically adept or have access to professionals.

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

#54

Post by oakwhiz »

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.

Have you tried this?

  sudo amdconfig --set-pcs-val=MCIL,DigitalHDTVDefaultUnderscan,0

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

#55

Post by jlgreco »

barrkel wrote: post #52
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…

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 sense whatsoever. Frankly, I do not believe it.

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

#56

Post by jlgreco »

stelonix wrote: post #49
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…

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…

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.

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

#58

Post by Elhana »

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…

Yeah, I was given a poulsbo netbook as a "present" few years ago.. at that time I thought cool, intel has great linux support... not! I'll stick to NVidia for now despite all the fuckyou they get.

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

#60

Post by stelonix »

jlgreco wrote: post #56
stelonix wrote: post #49

Earlier quoted context omitted.

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…

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 systems. Until such a simple thing also "just works", I won't be happy with sound on Linux.

Basically, I'm from the group of people who want things to work on Linux for the same use cases they work on mainstream OSs before I state that it "just works". I believe saying things "just work" only because it works for most of my needs is detrimental, as it gives a wrong image and may frustrate people trying to do something different , as it has happened to me in the past, I've caught myself trying to do non-standard things a lot (read: most) of the time.

Post reply on HN