Slashdot Mirror
Devs Discuss Android's Possible Readmission To Linux Kernel
MonsterTrimble writes "At the Linux Collaboration Summit, Google and Linux Kernel Developers are meeting to discuss the issues surrounding the Android fork and how it can be re-admitted to the mainline kernel. From the article: 'James Bottomley, Linux SCSI subsystem maintainer and Novell distinguished engineer, said during the kernel panel that forks are prevalent in embedded systems where companies use the fork once, then "throw it away. Google is not the first to have done something like this by far, just the one that's made the most publicity. Hopefully the function of this collaboration summit is that there is some collaboration over the next two days and we might actually solve it."'"
There will be paddling involved.
What does this have to do with the iPad? I come to slashdot for iPad stories, not stuff real nerds have never heard of.
On the front page of the android website is an announcement for a conference that has already happened.
Gee maybe they could update the front page?
Android will be at the 2010 Game Developers Conference in San Francisco from March 9th to March 11th.
Google must now balance any desire to respect the wishes of the Linux community for compatibility with the more diverse, competing - and not always logical - interests of those now adopting Android and its own plans.
I did a double take on this statement.
What I've seen on the kernel mailing list is more a conflict of commercial developer's desire for compatibility (across kernel versions) with the core kernel developer's more diverse (and not always logical) desire to push pet projects and make frequent cosmetic changes that creates a hellish torrent of code churn. The lack of well defined kernel driver interfaces means a lot of time spent chasing the latest changes instead of adding features or fixing bugs.
"{
'{
"{
}"
"{
}"
}'
}"
I wasn't sure if 5 quotes at the end of the article was correct or not. I decided to employ brackets to handle the scenario. Taking out the wording, my findings are above. It IS correct.
Is it bad that this was the most exciting part of the article to me?
It's a real problem -- Android is easily the most hackable phone out there. And that's exactly the kind of thing cell phone manufacturers in this country don't want. It's bundled services that they make their fortunes on -- selling overpriced phones, contract cancellation fees, locking in devices, and more. Android threatens to separate the market into service providers and device providers and up until now, the service provider dictated what the device providers could do.
Imagine if you could just eject your SIM card from your phone, plug it into your computer, and browse the net, take phone calls, etc., then eject it like it's a memory card, slap it back into your phone, and go off to school, work, wherever. Or using bluetooth so that as soon as you get home, it automagically resyncs all your e-mails, text messages, and more. There's so much the technology can do -- and the only reason it's not happening is because service providers want to charge for everything, rather than simply flat-rating everything on a per minute, day, or megabyte use.
My Sidekick recently lost the ability to send files to my computer over bluetooth. Why? Because of an OTA update that disabled that. So now I can't just sit my phone near my laptop and transfer my pictures out of it, I have to open the back up, eject the little card, plug it into my system, copy the files, and then do the reverse. Very cumbersome when before it was 'click icon, drag files'.
It's complete and utter bullshit that cell phones are as powerful now as desktops were ten years ago sitting in the palm of my hand, and yet they have less than a third of the capability. And not a one of them is really interoperable with any other except on the most primitive level. Hell, the dialup days of computing offered more functionality and standardization than the cell phone market does. Why should a 14.4k modem and an antiquidated pentium 133 have more communication functionality than today's devices? Hell... it even cost less.
#fuckbeta #iamslashdot #dicemustdie
If hardware makers can't include third-party code or processes that they aren't permitted to sublicense as free software, then perhaps they won't write a driver at all. Instead of proprietary drivers, you'll have completely unsupported hardware.
yes, if it's enough of a market for them, they will make sure that they get support from upstream, if enough companies ask for linux support for subassembly Y then maybe it will change. If you really feel you need to keep it closed, do like nvidia, or handle it yourself.
All of the above was encrypted with a Quad ROT-13 method. Unauthorized decryption is in violation of the DMCA.
What's your point, that we should encourage closed drivers by setting the APIs in stone for years on end? Allow the non-open to dictate the actions of the open?
That's not -my- problem. It's theirs. They choose to stay closed, so when the APIs change no one else can fix it but them. They have no room to bitch about unstable APIs in an open kernel that is constantly changing, when they won't commit to being open themselves. Others do, and as a result don't have nearly the problems. It's a cost they must accept, or they can do as you suggest and stop.
So I, an end user, am inside a Best Buy store, and I don't have a cell phone with a data plan to check what is in stock against the distro's HCL. How do I find peripherals that are definitely compatible with a free OS?
1. Class compatibility.
Prefer to buy the object which says it implements a device class standard. AHCI is a good example. Classes rule so much that in a lot of cases all the non-class compatible products just went away - HID and ATAPI are good examples of that. In a few cases products don't advertise their class compliance but there's a well known sign that you can learn before you start looking. For example, if a webcam has the symbol that means it's designed to work with Vista, that means it'll work with a modern Linux too, because to get that symbol from Microsoft the webcam must be class compliant.
Today class compatibility covers almost all: input devices, USB storage, onboard sound, internal drives including optical drives, Bluetooth, mid-range webcams.
Class compatibility remains spotty for: add-on PCI sound cards, high-end cameras, graphics display (it's limited to VGA, blergh), printers
Class compatibility is non-existent for: most networking, including WiFi, digital TV, fingerprint readers, scanners
2. "No" drivers
When class compatibility doesn't exist, and you have the choice between two products that make no mention of any OS except Windows, but one says it works without drivers, buy that one. Of course it needs drivers, but they must be built in to Windows, which means hardware of this type is common, and it existed at least long enough ago to include drivers for Windows, which means there's an excellent chance drivers for Linux exist or soon will.
3. Look for the logo
It's not everywhere, but in some categories you will see a penguin logo (or other Free OS logos) on products that offer some support. Now, this doesn't mean you're necessarily going to get a nice Free Software driver that works out the box. It may be an x86 Ubuntu only binary driver, or a patch that only works against Linux 2.6.4 or something equally useless. That's why I didn't list this as option 1. But it's usually a better sign than nothing at all.
Step one would be: don't shop at Best Buy, as you're probably paying too much.
Step two would be: shop at home, online, where you can compare both prices and compatibility with your OS.
I think these steps are valid whether or not you're a clueless end-user. Clueless end-users are more than capable of comparison shopping online (and if the end-user really wants to buy from Best Buy, they can look at Best Buy's website without leaving home).
Easy: don't. Do the research online and order online from the comfort of your Linux grotto. Let Best Buy die along with the perversely churning product of the week shelf stock that depends on third-party drivers.
To respond to you signature, Valve had this idea, and people spurned it at the time. Of course that was before they actually had a bunch of games in their lineup. (At least more than three years ago they did a survey.) The idea was to pay $10-15 and get all the games for free. That idea wasn't bad considering the prices that are paid for games... And you get the kind of support that Steam can offer, such as cloud based services (configuration, saved games, etc.).
Like a city whose walls are broken down is a man who lacks self-control.
That is going to be one killer merge.
look for one with a tux sticker on it?
If hardware makers can't include third-party code or processes that they aren't permitted to sublicense as free software, then perhaps they won't write a driver at all. Instead of proprietary drivers, you'll have completely unsupported hardware.
Releasing unsupported hardware because you don't like the alternative seems like a case of cutting off your nose to spite your face.
Given the situation you describe, in which hardware makers sub-license proprietary code because it costs them less, it would seem to me that they should be promoting FOSS for all they're worth. No more upstream lock-in for the manufacturers, fewer overheads and almost certainly increased profits per unit sold because of reduced demand for royalties.
I realise that it's extremely difficult to move to a FOSS culture from a predominantly proprietary one - especially when there are long-term licensing/royalty agreements to consider. But one would think that hardware manufacturers would see it as a strategic goal.
Crumb's Corollary: Never bring a knife to a bun fight.
I have to agree with the other responders: don't buy at Best Buy! You're just getting ripped off. Go home, and shop on Newegg.com (or zipzoomfly.com, or many others). The prices are much lower, there's customer reviews so you can see what other people say about the product or if there's common problems, and you probably won't have to pay sales tax which should make up for any shipping charges.
Fine by me. Better than encouraging closed drivers.
And here is why.
Google has proven to be benevolent, but I am not sure I want their hooks in my Linux kernel. Google exists to make money and do things in their own self interest. The problem is if their fork gets merged that they will become the maintainers for this. I believe as long as it remains in their self interest they will maintain the code but as soon as it is no longer in their self interest it will be abandoned and where will that leave us should we all decide to begin uses that functionality?
I think they should put the parts that are different out there, lets us all examine them and then let us decide if we want their frankencode or not.
Hey KID! Yeah you, get the fuck off my lawn!
Step two would be: shop at home, online
How much do return shipping and restocking fees cost if the product A. turns out to be an incompatible revision after they switched from, say, Atheros to Broadcom within the same model number, or B. is a laptop computer that turns out to be incompatible with my hands and/or eyes?
The prices are much lower
Because they charge return shipping plus a 15% restocking fee if you're among the first to buy something after the manufacturer has made an incompatible revision to the hardware.
and you probably won't have to pay sales tax which should make up for any shipping charges.
Until you get audited and billed for back use tax plus penalties for non-payment of tax.
Releasing unsupported hardware because you don't like the alternative seems like a case of cutting off your nose to spite your face.
If the (supported) Mac OS X market is an order of magnitude bigger than the (unsupported) GNU/Linux market, and the (supported) Windows market is yet another order of magnitude bigger than that, then cutting off your nose to hide your lies becomes profitable.
if it's enough of a market for them
It isn't. Because GNU/Linux has roughly 1% of the desktop share, a lot of companies don't see the return on investment in getting support from upstream.
The signals are not the issue, you talk to the cellular gear via ATT.
With cable, DSL, or FTTH, the ISP just has to put another "refrigerator" on the corner to handle more signals. But with USB cellular modems, it costs a lot for AT&T to build more towers to handle more subscribers.
Yes - as much as possible. I don't think API's should never be fixed or improved, but at some point Linux ought to be 'done' enough that driver API's don't need to be changed, and that backward compatibility isn't such a liability that it outweighs the advantages.
C'mon folks. Linux is way past the experimental phase. It's the basis for many of the devices we use and love. If the API's aren't solid enough to freeze (or maintain backward compatibility) at this point, then it ought to be a priority to make them so. Just because dev's can rewrite open source drivers to handle API changes, doesn't mean it's not a lot of effort that would not be necessary if the API's didn't have to change.
Posted from my Android phone. Oh, I can change this? There, that's better...
Not many servers use webcams.
My place of employment has a Windows server behind the firewall that manages eight surveillance cameras. Is that close enough?
What's your point, that we should encourage closed drivers by setting the APIs in stone for years on end?
I think the point is that the driver ABI doesnt need to change every cycle just to discourage closed drivers.
..and here is an idea.. an operating system can support more than one driver model and ABI. Pick one, call it BIN_DRV_1. Declare it to be supported for at least N > 5 years, and then continue to fuck around with the SRC_DRV one. After 5 or more years, when there seems to be a significant advantage if BIN_DRV_1 had the same features as SRC_DRV, you define BIN_DRV_2 and then support that one for a long time.
Right now what you have is a catch-22 situation where vendors don't want to write drivers because of low market share, while market share remains low partly because vendors don't want to write drivers.
"His name was James Damore."
An ABI is not in the interest of Linux users. It's only in the interest of lazy manufacturers who want to push pieces of hardware which users will have to trash after the next operating system release. I've got plenty of hardware I can no longer use under Windows because its manufacturers only produced ONE release of the driver before shelving the product. All of it works with Linux.
But hey, I have yet to see hardware that I couldn't use under Linux.
Then you haven't seen a Microtek ScanMaker 4850 flatbed scanner. It's still listed as unsupported in SANE, just like it was when I first checked back in the Mandrake 9.1 days.
Amen to class compatibility. I still don't understand how there hasn't been a basic standard created for NICs similar to VGA, like being capable of establishing a 1 Mbps TCP/IP connection. It is the one peripheral in the entire system that I need to be working in order to get drivers everything else, and yet it is the one device that I spend more time having to get working than any other. Admittedly, I work with a lot of demo units so I am likely having this happen more often than the average bear, but it sure as hell doesn't seem like a weird expectation to have basic functionality from a product that is becoming even more common than a video interface and has been around for decades.
And there is no such OS as GNU/Linux.
I use GNU/Linux to refer to Linux environments that use Bash, GNU Coreutils, and glibc, as opposed to embedded or "uClinux" environments that use BusyBox and either uClibc or Newlib. Do you have a better term for "Linux on desktops and servers" that distinguishes it from "Linux on embedded devices"?