Qualcomm Calls To 'Kill All Proprietary Drivers For Good'
An anonymous reader writes "Next week at the sixth Linux Foundation Collaboration Summit, two Qualcomm Atheros engineers will be making a stand for killing all proprietary drivers for good — across all operating systems. The Qualcomm slides go over their early plans. Do they stand a chance?"
I know where I'm throwing my money the next time I need such hardware!
For large sets, this will be our guide even unto death, for the LORD will work for each type of data it is applied to...
No.
-- I ignore anonymous replies to my comments and postings.
Killing software patents.
The thesis here presumes that there is no room for innovation in the software drivers. Hardware vendors can compete by both hardware and software improvements. If they can't keep competitive innovations proprietary, then there is no incentive to fund R&D in the software.
This is the sort of thing Google should have pushed for with Android, but after a year of struggling with their OS I've come to realize Google doesn't care about the end user experience. By subsidizing and dumping Android they pushed webOS and MeeGo out of the market.
Why would it stand a chance? Their slides do nothing but repeat the same talking points that have been said for years that have been mostly unpersuasive. Unless they have some way to force this, it'll mostly be nothing but preaching to the choir.
If Qualcomm starts with their cellphone baseband processors, I'll start listening.
Without the active participation of the patent holders this idea is just wishful thinking with as much validity as when I said it eight years ago while I was flipping burgers on the barbecue.
One of the big problems here is that many businesses don't really want things to be open. Openness runs contrary to control, and even if the result is a net gain by every measure, people *hate* to give up control-- especially when it's a PHB who does nothing but meddle, and that accounts for most decision-makers.
Clearly you are just trolling here, but... wow.
Off your meds today?
Nobody is telling you what to do. Just like RFCs don't tell you what to do.
They tell you what you should do. This is an important distinction.
Of course, if you ignore those recommendations and do your own thing: you are on your own.
For large sets, this will be our guide even unto death, for the LORD will work for each type of data it is applied to...
Accomplishing such a feat would require the market to be largely informed and interested. Neither is the case.
Anyone check out that slideshow? Definitely worth a chuckle. The whole Star Trek powerpoint template is copious amounts of awesome, and the comic strip re: WTFs/minute is great.
Wish I worked with these guys
Saw the title and thought: "Wow, death threats in public? They couldn't be driving THAT bad..."
Step One: Convert PowerPoint to randomly switch colors every third word when using Star Trek-like background styles.
(for those who rtfa on the slides)
I sometimes ask revealing, often ignorant-seeming questions. Maybe they're harder to answer than you think.
Fagets, is that French?
Not to worry, you can make all the proprietary drivers you want. But if Qualcomm has its way, no one will buy drivers or hardware from you.
Killing software patents with fire.
Flexible bare-metal recovery for Linux/UNIX
Yes. It's a kind of bread you can smoke.
yes.
It's going to have to be done. Whether the manufacturers like it or not - it is this exact reason why android phones are a major pain in the ass, buggy, unrelaible, etc.
This proposed metric for rating code during review is the best part of that whole slideshow!
Common Sense isn't as Common as people think...
Aren't there also some serious regulatory hurdles, particularly when it comes to devices that are intentional RF radiators? There are (1) limits imposed by the regulatory bodies (not more than x uV/m signal strength over frequency band y) but also (2) prevent of the guy who just wants his signal to get through (and damn you all) and cranks up the TX power beyond what the equipment is rated for, making adjacent bands useless for anything else. I see some of the restrictions on these things from that light, and I don't know a good answer, particularly to (2).
10 years ago, I would have said no. However some thing have changed.
People moving into management now have seen the value open drivers can bring.
They understand the controlling the drivers has no impact on value, and has little or no return.
If they, and others, include cost analysis arguments, then they have a chance.
While we will still see official drivers, we will have other options . Plus, opening up drivers means you can maintain a tree to review and possible integrate other peoples changes. Of course ego maniac developers won't like it because others will see 'their' precious' code.
The Kruger Dunning explains most post on
Because if Qualcomm wants to run something like Windows Phone s/w, they'll have to take steps to protect the API. Or no Windows Phone for you!
Have gnu, will travel.
Nokia's original Maemo was GTK based, and it had a lot of potential, then they decided to merge with Intel's Qt using Moblin. GTK and Qt do not mix.
Although Stephen Walt was talking about something entirely different, his sentiment seems appropriate: ...Moreover, why do discredited ideas come back
into fashion when there is no good reason to
resurrect them? Clearly, learning the right lessons
- and remembering them over time -- is a lot harder
than it seems. But why?
It's faggots, you fucking dimwit.
I think pushing for the genocide of tax drivers is asking a bit much, right? Or did I read this wrong...
can't sleep slashdot will eat me
I expect that a very large percentage of drivers are infringing on other companies' patents. Make the driver open source means exposing yourself to IP litigation. Only the larger hardware companies are going to be willing to spend the $$ necessary to audit their drivers and expunge all foreign IP.
IMO we need to get rid of software patents before this will take off in a big way.
-deane
as real engineers. Hardware must also change to be more standardized without shipped drivers. Drivers must be provided by the OS or as third party software. Open hardware means healthy competition. Qualcom seems to understand it.
Many years ago i was associated with Project UDI, the Uniform Driver Interface. The goal was to make a uniform ABI/API for device drivers. On Machines with the same hardware target (say, 32 bit x86) you would have binary compatibility. The same driver works on Solaris or Windows. For other platforms, they'd be at least source compatible. It worked in theory, and somewhat in practice - I think UnixWare shipped this as their native Device Driver Interface.
But you never heard of it. Part of it was the SCO/Caldera fiasco. 'Nuff said about that.
But part of it also was the fact that people had vested interests in this failing. Most famously, Stallman didn't like it. For now you could ship drivers without source for all i386 targets (not that having the normal Linux DDI prevented that before). But it was fun that I worked on something shipped in a commercial kernel, and also something that pissed off Stallman.
More importantly, the people who want this are necessarily in the weakest position. MS doesn't want this - everyone makes Windows drivers. They get nothing from it except lower exclusivity. (The fact that Gates and Stallman were on the same side of this should have given Stallman time to reflect). They'd never allow the UDI code to touch their kernel. One or two other big UNIX vendors feigned interest, but they had the same issue - they had exclusive (to UNIX) device drivers, and they'd lose exclusivity. Only Caldera used it. It was their project, and it helped their forked codebase - they had both UnixWare and OpenServer (very old) code bases they needed drivers for, and it made it an easier target for device makers.
None of the issues were tech issues, they all were people issues, which haven't gone away in the intervening years.
What is the distinction? I don't get it.
"The RFC doesn't tell me what to do; it tells me what I should do."
The two sound like synonyms to my ear.
One is a command... an edict. The other is a guideline... a suggestion.
For large sets, this will be our guide even unto death, for the LORD will work for each type of data it is applied to...
but I don't see much discussion about what the pros and cons are for those involved, I may be a little bit under-informed but it seems having everything open would be a bonus for all people in the supply chain. The cons however, I don't really see any. Aren't people already paying for the hardware, they get the software regardless of whether the drivers are open or not.
Is there any cons? I honestly don't know.
Cryonics!
Taiwan.
They propose to do it by eliminating GPL'ed drivers in favour of BSD. This is a) unnecessary even on Windows regardless of what they tell you and b) allows others to create proprietary forks of your drivers.
And RFCs will even tell you how you should interpret the word should .
Has to happen. Should have happened 20 years ago.
Yes, that is what gov should do.
Yes. It's a kind of bread you can smoke.
I thought it was Italian-American for when you cant remember something.
Calling someone a "hater" only means you can not rationally rebut their argument.
Funny seeing this coming from Qualcomm. I've been working on the HP TouchPad Ubuntu port and would love to see open-source Adreno 220 drivers with X support, but none appear to exist. I can't take them seriously on asking other companies to kill proprietary drivers when their own drivers are closed and unavailable (even TI's SGX drivers are available as a binary package with SDK and installation instructions for your kernel).
It won't happen. A lot of device drivers utilize patented code which is rigorously protected by many software companies. The GPL is not suitable for those who want to maintain control over their code. Proprietary drivers are a necessary evil if one is using a FOSS operating system with specialized hardware.
From the article: "Their path to killing proprietary drivers is easier said THEN done,"
The new America - where 'then' means 'than'. (And also 'that' means 'than' too, apparently).
It may make the DRM pointless, but no more than giving the users the device that decodes the encrypt.
So, unless selling the BluRay player becomes a DMCA offence, giving out the source or even just the register codes, cannot be one either.
And take your Japanese phone to the USA and it's now breaking local regulations.
Download the Japanese firmware and install on your US laptop's WiFi and it's now breaking regulations WITH THE EXPLICIT AND REQUIRED aid of the provider.
Oddly enough, the fact that you can change your firmware is not a problem for devices that are intentional RF radiators.
And, if you were not allowed to change your firmware, then that would STILL fall foul of your imaginary problems with devices that are intentional RF radiators that aren't nailed permanently to the ground.
You see what you can do is change the specrum. And if YOU, the customer, change it outside the spec allowed by your local laws, then YOU, the customer, are in trouble. IN NO CASE can the manufacturer be held liable except where they lock down and refuse to allow the output to be changed on their devices.
Why are you removing propriatory and patent encumbered parts?
Patents are still covered by patents even if you give out the source code.
And what propriatory stuff could be in NVidia/AMD's graphics cards that don't belong to NVidia or AMD that could possibly slow down the card's gaming or 3D GUI performance?
What's your point? It means exactly what I think it means.
For large sets, this will be our guide even unto death, for the LORD will work for each type of data it is applied to...
Really Qualcomm? Your website says "Worldwide, Qualcomm's extensive patent portfolio boasts more than 9400 United States patents and patent applications for CDMA and other technologies." Your "Wall of Patents" is a back-lit shrine to patent protection. [see pic] http://tinypic.com/view.php?pic=54iofk&s=5
OK, you committed to Android to save yourself, but calling to kill all proprietary drivers... when your proprietary/patent portfolio is one of the largest on earth? CDMA is dead. LTE won't save your ass.
Why would you go to the hassle of creating driver packages for every different distro, when you could submit your driver source to be included in the upstream kernel?
Because, for example, some video card companies find it more profitable to engineer a product to work well with the products of Disney, Last Century Fox, Paramount, Sony, Universal, and Warner. The compliance and robustness requirements of some digital restrictions management schemes, such as HDCP, appear to forbid publishing driver source code.
Ableton looks like it's for Windows and Mac only
I've been able to run some low-end audio software designed for Windows under Wine. This includes FamiTracker and Modplug tracker.
get a new card.
Good luck replacing an unsupported WLAN card in a laptop. They aren't externally accessible CardBus or ExpressCard cards anymore; they're on the motherboard. Or what do I misunderstand?
Have you even tried Meego?
I'll admit that I haven't because I haven't been able to find any showrooms with a MeeGo phone in my area. Or did you mean buy before I try, and then eat round-trip shipping and a 15% restocking fee should I end up not liking it?
I agree that I can't judge MeeGo on this basis, but I can judge the organizations that failed to market it to where I could at least try it.