Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Devs Discuss Android's Possible Readmission To Linux Kernel

Soulskill posted more than 4 years ago | from the calling-an-estranged-cousin dept.

Google 151

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

Sorry! There are no comments related to the filter you selected.

One thing is for certain (0)

Anonymous Coward | more than 4 years ago | (#31878308)

There will be paddling involved.

Re:One thing is for certain (0)

Anonymous Coward | more than 4 years ago | (#31880084)

Petting?

Yawn (5, Funny)

Anonymous Coward | more than 4 years ago | (#31878328)

What does this have to do with the iPad? I come to slashdot for iPad stories, not stuff real nerds have never heard of.

Re:Yawn (3, Funny)

ickleberry (864871) | more than 4 years ago | (#31878434)

Really? I come to slashdot to read about how Google is taking yet another piece of technology we have taken for granted for many years and turning it into an online, ad-based Clout 2.0 service and tunneling it through HTTP with JSON and SOAP to their servers for a nice intense data-mining session for better targeted ads and predicting future crimes one might commit.

Re:Yawn (4, Insightful)

girlintraining (1395911) | more than 4 years ago | (#31878552)

Really? I come to slashdot to read about how Google is taking yet another piece of technology we have taken for granted for many years and turning it into an online, ad-based Clout 2.0 service and tunneling it through HTTP with JSON and SOAP to their servers for a nice intense data-mining session for better targeted ads and predicting future crimes one might commit.

Unbridled capitalism and the apathetic and ignorant citizens are to blame for that. Your personal data can be aggregated and monetized, and for the foreseeable future, there's very little legislation to prevent this and very little awareness of how pervasive such technology is. My whole generation is living with software riddled with government and corporations that have put back doors into everything, freely share data with each other, and those living in urban areas (the majority of the population) are rarely out of contact with some device or another wired into the global network, tracking their movements, purchases, communications, relationships, and every aspect of your life. Remotely-enabled webcams, cell phones that can be turned on silently to broadcast everything it hears and sees, and laptops and routers that can be readily converted into eavesdropping devices, just to name a few of the many things that are out there right now. And the only reason it's not all interconnected more seamlessly is because the technology is still rapidly evolving and hasn't reached a stable plateau where convergence is possible, although the internet has made a giant leap forward in enabling that future. The NSA spends billions each year trying to keep up with infrastructure changes and only is able to harness a fraction of that potential.

But I mean, comeon -- what do you expect from a world where we find it okay to setup metal fences with razor-tipped wire and cameras everywhere as "official protest zones", where we have passports, credit cards, (and soon ID cards) that can be remotely scanned to identify you... put it all together. Where do you think this all ends?

Re:Yawn (2, Funny)

maxume (22995) | more than 4 years ago | (#31878642)

It is entertaining that a tinfoil hat will work quite well at protecting your wallet from remote scans.

Re:Yawn (4, Insightful)

russotto (537200) | more than 4 years ago | (#31880318)

It is entertaining that a tinfoil hat will work quite well at protecting your wallet from remote scans.

Only if you keep your wallet on your head.

Re:Yawn (1)

BlackHawk-666 (560896) | more than 4 years ago | (#31880594)

I carry my phone, wallet and even keys in a tinfoil handbag. It looks gay, but keeps the government from spying on my precious bodily fluids. I'm thinking of switching to a new shampoo with tinfoil instead of alumninium as a a major ingredient.

Re:Yawn (2, Funny)

Abreu (173023) | more than 4 years ago | (#31879396)

I'm not worried! A lot of the info I have posted online is false!

Re:Yawn (1)

MichaelSmith (789609) | more than 4 years ago | (#31880144)

I'm not worried! A lot of the info I have posted online is false!

Including this?

Re:Yawn (0)

Anonymous Coward | more than 4 years ago | (#31879414)

Where do you think this all ends?

Room 101

Re:Yawn (1)

WrongSizeGlass (838941) | more than 4 years ago | (#31878484)

What does this have to do with the iPad? I come to slashdot for iPad stories, not stuff real nerds have never heard of.

Just be patient and give it time. This Lenax stuff may just catch on one day and we'd all look pretty foolish if we didn't pay attention to it now.

Re:Yawn (0)

Anonymous Coward | more than 4 years ago | (#31878644)

I think you meant to go to Ars Technica. Chris Foresman in particular can't get enough of the iPad.

Bad Marketing (1)

phantomcircuit (938963) | more than 4 years ago | (#31878342)

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.

Re:Bad Marketing (2, Insightful)

theshibboleth (968645) | more than 4 years ago | (#31878400)

Outdated webpages are the hallmark of a dying product

Re:Bad Marketing (1)

WrongSizeGlass (838941) | more than 4 years ago | (#31878516)

Gee maybe they could update the front page?

It's in the process of updating. Just keep in mind that "the cloud" isn't exactly 'real time'. It'll be showing the "back to school specials" well before Christmas.

Backwards? (4, Insightful)

Sponge Bath (413667) | more than 4 years ago | (#31878406)

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.

Re:Backwards? (5, Insightful)

Microlith (54737) | more than 4 years ago | (#31878482)

The only people I've seen clamoring for a static, unchanging driver interface are those writing proprietary drivers. Last I checked, changes to the interfaces by someone puts the onus on them to fix all the calls to it in the kernel, which is why getting your driver into the tree is considered better than keeping it closed.

That said, if you're keeping your driver closed it's a problem you're bringing upon yourself.

Would you rather have completely unsupported HW? (3, Insightful)

tepples (727027) | more than 4 years ago | (#31878554)

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.

Re:Would you rather have completely unsupported HW (3, Insightful)

cynyr (703126) | more than 4 years ago | (#31878604)

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.

Where's the ROI? (3, Insightful)

tepples (727027) | more than 4 years ago | (#31880716)

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.

Re:Where's the ROI? (1)

yahwotqa (817672) | more than 4 years ago | (#31881022)

Right, hardware is only used on desktops. Servers run purely on love, goodwill and farts.

Re:Would you rather have completely unsupported HW (3, Insightful)

Microlith (54737) | more than 4 years ago | (#31878630)

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.

Re:Would you rather have completely unsupported HW (2, Interesting)

tepples (727027) | more than 4 years ago | (#31879074)

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?

Re:Would you rather have completely unsupported HW (2, Interesting)

Anonymous Coward | more than 4 years ago | (#31879310)

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.

Re:Would you rather have completely unsupported HW (2, Insightful)

HeronBlademaster (1079477) | more than 4 years ago | (#31879346)

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

Return shipping and restocking fees (1)

tepples (727027) | more than 4 years ago | (#31880640)

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?

Re:Would you rather have completely unsupported HW (0)

Anonymous Coward | more than 4 years ago | (#31879354)

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.

Re:Would you rather have completely unsupported HW (1)

Aldenissin (976329) | more than 4 years ago | (#31879394)

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

Re:Would you rather have completely unsupported HW (1)

h4rr4r (612664) | more than 4 years ago | (#31879642)

look for one with a tux sticker on it?

Re:Would you rather have completely unsupported HW (1)

Grishnakh (216268) | more than 4 years ago | (#31879706)

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.

Back use tax (1)

tepples (727027) | more than 4 years ago | (#31880672)

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.

Re:Would you rather have completely unsupported HW (1)

grcumb (781340) | more than 4 years ago | (#31879702)

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.

Cutting off your nose (1)

tepples (727027) | more than 4 years ago | (#31880690)

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 [printfection.com] becomes profitable.

Re:Would you rather have completely unsupported HW (1)

h4rr4r (612664) | more than 4 years ago | (#31879798)

Fine by me. Better than encouraging closed drivers.

Re:Backwards? (2, Insightful)

Anpheus (908711) | more than 4 years ago | (#31878624)

Those proprietary drivers still have to be maintained against the rest of the kernel, and that costs time, and consequently money.

Furthermore, many of these devices are protected by patents, and I'm sure you don't want code for a special model of capacitive multi-touch screen that only one phone uses to be added to the general Linux kernel. There's no point in it.

So that's the problem. All these phones have highly specialized devices that may be protected by patents that in Europe have no weight, but in the US do, and could cause problems for the linux kernel potentially even if they were introduced. Add to that the fact that for many of these devices a generic, unifying framework doesn't exist that they can attach themselves too, and you could end up seeing the kernel with ten thousand different phone drivers, each of them so specific that all it does is bloat the kernel.

So what's the answer? Well, the answer is that if Linux doesn't start building a good ABI, they're going to shoot themselves in the foot, or more literally, they'll end up sawing off their own leg because it decided to fork itself. And for all the babbling the kernel devs do about the difficulty of maintaining an ABI and how it constrains them, it also makes it very difficult for the generic, current Linux kernel to gain widespread adoption in markets that resemble embedded ones in all but name. What is HTC supposed to do, keep people on payroll perpetually to maintain their thousand plus phones and their potentially tens of thousands of drivers?

Suddenly, Linux is starting to look a lot more expensive than free.

Re:Backwards? (1, Interesting)

0123456 (636235) | more than 4 years ago | (#31878710)

The last thing Linux needs is a set-in-stone kernel interface: 'backwards compatibility' is what has ensured that Windows remains a steaming pile of kludges and security holes as no old components can be thrown away.

I can only presume that you are actually Bill Gates and want to destroy Linux by forcing it to repeat Windows' mistakes.

Re:Backwards? (4, Insightful)

Sponge Bath (413667) | more than 4 years ago | (#31878946)

The last thing Linux needs is a set-in-stone kernel interface...

I can agree with this, but then again I don't see anyone asking for that.

How about something in between, say a well defined interface that is stable for a reasonable period of time with clear points of deprecation and then replacement with improved interfaces? Windows's driver interface is not set in stone with never ending backwards compatibility, you can't use Win 9X drivers on XP. Yet a binary driver that works on Windows 2K has a reasonable chance of running on Vista.

There needs to be a balance between improvements/changes and stability/maintainability.

Re:Backwards? (1)

Daengbo (523424) | more than 4 years ago | (#31880320)

you can't use Win 9X drivers on XP

They're completely different code bases and product lines with different kernels. Of course you can't. You should be mentioning whether NT4 drivers can be used by XP or not.

Re:Backwards? (1)

Anpheus (908711) | more than 4 years ago | (#31878996)

Not set in stone, but less volatile than "every other release needs some minor fixup." That's all.

For example, we're currently on 2.6.33.2. Why not standardize on an ABI for the minor version number? 2.6 versus 2.8 for example. (Or since they switched development pattern, will 2.7 be a legit release? I don't know.)

The problem is that the volatility is so high that kernel drivers need 24/7 maintenance, or else they're dropped and then it becomes even harder to re-integrate them. Ask Microsoft about their paravirtualization drivers. They've submitted two or three versions to the kernel, and each time you had to use the specific version of the kernel that they compiled them on, or it didn't work. That's the problem. Linux. Isn't. Free. Microsoft is however eventually going to have to come to a sad realization: it may cost them a salaried employee and benefits just to maintain these drivers. That's ridiculous. If it's difficult for Microsoft to justify targeting Linux, how is a small business going to justify putting 1/10 of its development staff on it? 1/20?

It's insane. Linux is such a "me me me" culture where everything revolves around the sanctity of the kernel and how free and open it is, and no one appears to consider the ramifications of the actions.

The fact is, the Linux kernel will fix these problems or Android will fork, or HTC, Nokia, et al. will do it for them. And then Android will be fragmented, and we'll be back to considering iPhones and BlackBerry phones the best in the world, each with their horrendous lock-in. With one, I have to code in The One True Language, and with the other, I have to make sure my clients are using The One True Message Server. As soon as Android isn't viable, they're the best options. That's sad.

Re:Backwards? (1)

Microlith (54737) | more than 4 years ago | (#31879118)

Linux is such a "me me me" culture where everything revolves around the sanctity of the kernel and how free and open it is, and no one appears to consider the ramifications of the actions.

What, they're WRONG for not allowing arguably more selfish proprietary driver vendors to decide the course for the kernel?

Re:Backwards? (2, Insightful)

HeronBlademaster (1079477) | more than 4 years ago | (#31879386)

No, but they're wrong for being unwilling to meet them halfway (even something as simple as a clear schedule for ABI changes and deprecation). There's nothing wrong with adding a little method to the madness.

Re:Backwards? (0)

h4rr4r (612664) | more than 4 years ago | (#31879658)

Why meet them halfway when they provide nothing?
If they want a stable ABI layer let them write a shim that exposes this stable ABI and update that when things change in the kernel. Then all the proprietary folks can share keeping one stable ABI shim up to date.

I don't meet the homeless halfway and let them move into my garage.

Re:Backwards? (1)

Josh04 (1596071) | more than 4 years ago | (#31879772)

You seem to be equating the actual users in the equation to 'nothing'. This is a pretty fundamental flaw for any project.

Re:Backwards? (1)

Ash-Fox (726320) | more than 4 years ago | (#31880800)

I have never seen software development cater to all users - did not make a difference if it was opensource or proprietary.

Re:Backwards? (1, Troll)

Daniel Phillips (238627) | more than 4 years ago | (#31879374)

Why not standardize on an ABI for the minor version number? 2.6 versus 2.8 for example.

There is no 2.8 on the horizon, the next number over to the right has become the de facto minor version number, and the module ABI is stable within each of those releases. Clearly, you are not involved in actual kernel development, but thanks for playing.

Re:Backwards? (1)

Sponge Bath (413667) | more than 4 years ago | (#31879714)

There is no 2.8 on the horizon, the next number over to the right has become the de facto minor version number, and the module ABI is stable within each of those releases.

I don't know where you get that. I've seen and continue to see plenty of changes to kernel functions called by drivers between 2.6.x and 2.6.x+1. Maybe you mean the next number to the right of that, the so called stable branches maintained by Greg Kroah-Hartman?

Those are a step in the right direction, but the x changes every few months and includes fixes usually unrelated to any driver interface changes. Some of those fixes get back ported to stable, some do not. That makes the useful window of a stable branch not much longer than the interval between 2.6.x and 2.6.x+1. There is still an unnecessarily coupling of fixes to unrelated driver interface changes that keeps you on the 2.6.x upgrade path.

Despite the intent to keep 2.6.x.y compatible with 2.6.x.y+1, I've still occasionally seen changes to kernel functions called by drivers that break the driver.

All of this said, the current system obviously works. I just think there is room for improvement using some common sense and long proven development techniques.

Re:Backwards? (2, Informative)

Mad Merlin (837387) | more than 4 years ago | (#31880352)

The problem is that the volatility is so high that kernel drivers need 24/7 maintenance, or else they're dropped and then it becomes even harder to re-integrate them. Ask Microsoft about their paravirtualization drivers. They've submitted two or three versions to the kernel, and each time you had to use the specific version of the kernel that they compiled them on, or it didn't work. That's the problem. Linux. Isn't. Free. Microsoft is however eventually going to have to come to a sad realization: it may cost them a salaried employee and benefits just to maintain these drivers. That's ridiculous. If it's difficult for Microsoft to justify targeting Linux, how is a small business going to justify putting 1/10 of its development staff on it? 1/20?

Bzzt! Wrong.

Once code is properly merged to the Linux kernel, it is maintained by the kernel community at large, which need not include the original author. When a kernel developer changes an API, they are required to simultaneously update all in kernel drivers that use the API in question. The only drivers that require 24/7 maintenance are those that are out of tree (regardless of the reason they're out of tree).

Android was never properly merged to the Linux kernel. Google did a big code dump for Android and it was merged as a set of staging drivers with the caveat that it needed a lot of cleanup before being moved into non-staging. Unfortunately, that cleanup never came and Google basically let the code rot. Thus, a few releases later, Android was removed.

Indeed, probably well over half of the code in the Linux kernel is now maintained by someone other than the original author (be it an individual or a corporation), particularly for non-core subsystems and drivers. As a hardware vendor or other similar party, if you want a) your widget to work out of the box on every Linux distro and b) to not worry about maintaining your driver, you should be getting your driver merged to the Linux kernel.

Re:Backwards? (0)

Anonymous Coward | more than 4 years ago | (#31879174)

The right way to look at this is that they are getting a whole OS for free. That's a lost of savings! They can get additional savings if they merge their drivers upstream. If they think, it's more valuable to have a closed driver than upstreaming it, then it's their decision. But they can't bitch about it.

Btw, for all embedded devices, you only compile what's needed. So, you aren't adding any bloat by getting different companies to open and upstream their drivers.

Disclaimer/credibility: I actively work on the Android kernel code. That's my full time job.

Re:Backwards? (0)

Anonymous Coward | more than 4 years ago | (#31879676)

Sounds great, but sometimes management is stupid. My own company is now adopting Linux so they don't have to pay per-device license fees like with their previous embedded OS, but they don't want to contribute anything back whatsoever, including all the drivers they're developing.

Worse, many of the drivers we're developing use GPL-only symbols, so we're declaring the drivers "GPL" in the MODULE_LICENSE macro. However, we're not honoring the GPL at all. Can that get us in legal trouble? What if a disgruntled employee were to rat them out?

Posting anonymously for obvious reasons.

Re:Backwards? (1)

Grishnakh (216268) | more than 4 years ago | (#31879640)

First, I'd like to say, what moron modded this "troll"? I personally don't agree with it, but that doesn't make it a troll.

Furthermore, many of these devices are protected by patents, and I'm sure you don't want code for a special model of capacitive multi-touch screen that only one phone uses to be added to the general Linux kernel. There's no point in it.

Wrong, absolutely wrong. Greg K-H himself has explicitly said that he WANTS people with drivers for even highly obscure devices to merge them into the mainline kernel. It doesn't matter if your capacitive multi-touch screen is only used in one phone; the code is useful to have publicly available in the kernel as a reference. Furthermore, as more drivers for similar devices are merged into the kernel, commonalities between them can be found, and more generic drivers can be created.

Eventually, with multiple capacitive multi-touch drivers in place, someone will probably look at them all, and create a generic "capacitive multi-touch core" driver, and all the other drivers will only have the specific code needed for themselves, and will share the core code. This reduces the total amount of code, and increases the quality. As bugs are found and fixed in the shared core code, these bugs are then fixed for ALL such devices, instead of having to fix the same type of bug in every single driver.

Even if no "core" driver is written, having more drivers in place serves as a reference to those writing drivers for similar devices. So if you're trying to write a driver for a different capacitive multi-touch chip, you can look at the other drivers in the kernel and see how they did it. This will speed your development greatly.

Interestingly and coincidentally, I happen to be working on a capacitive touchscreen driver myself at the moment (not multi-touch, however).

Add to that the fact that for many of these devices a generic, unifying framework doesn't exist that they can attach themselves too, and you could end up seeing the kernel with ten thousand different phone drivers, each of them so specific that all it does is bloat the kernel.

You have to merge all the drivers in before someone's going to start writing a generic framework. OSS tends to be more reactive, not proactive about these things.

And no one cares about the kernel having 10,000 different phone drivers. This doesn't "bloat" the kernel, only the source code. The only people complaining will be those downloading the source code. Given that people regularly download 1GB HD TV shows on BitTorrent these days, an extra 100MB of source code in the kernel isn't going to be a big deal. Most people don't download the Linux kernel source, only kernel developers.

As long as people merge their drivers into the mainline like they should, there is absolutely NO reason to have a stable ABI. All it does is allow cruft and bloat, because of the need to maintain backwards compatibility. Backwards compatibility is Windows' Achilles heel; why repeat that mistake? Just because a few companies are idiotically afraid of merging their drivers? Let them suffer.

Re:Backwards? (3, Informative)

dgatwood (11270) | more than 4 years ago | (#31880252)

Wrong, absolutely wrong. Greg K-H himself has explicitly said that he WANTS people with drivers for even highly obscure devices to merge them into the mainline kernel. It doesn't matter if your capacitive multi-touch screen is only used in one phone; the code is useful to have publicly available in the kernel as a reference. Furthermore, as more drivers for similar devices are merged into the kernel, commonalities between them can be found, and more generic drivers can be created.

Based on what I've seen over the years (as a developer on a project that never made it back into the mainstream kernel), the problems with this approach are threefold:

  1. Nobody maintains most of them. Most of the 5% of drivers that everybody uses are already in the kernel tree. Of the remaining 95%, half of the drivers don't build at all, and most of the other half don't work. If they're barely maintained now, you can bet money that they won't be maintained at all when some kernel tree maintainer gets a hair up his/her backside and decides that a particular fix isn't elegant enough and won't take the changes....
  2. The tree is already too large. If every driver out there were in the tree, checking out an update to the tree would be horribly painful, the source packages that distributions include would become huge, etc. The bigger it gets, the fewer people are going to be willing to maintain their drivers inside that tree, so in the long run, encouraging people to put their drivers in the tree is just going to cause other drivers to move back out of the tree, eliminating any real benefit.
  3. Many such drivers are outside the tree because they require substantial changes to some subsystem in order to build them. Now one could argue that these changes should be made to those subsystems to make them more general, or one could argue that those drivers are so specialized that nothing else will use them, so there's no reason to bother. That's often not an easy question to answer, and tends to result in highly political shouting matches, with the end result being that the driver never goes in, which is usually why those drivers got published outside the kernel tree to begin with.

There are ways to solve these problems, of course; IMHO, they basically amount to:

  • Design a kernel build infrastructure that can easily bring in driver sources from third-party sites (like a ports collection, but for kernel drivers). With proper categorization, this can provide all the same benefits as having the drivers in the main tree, but also allows for a richer tagging scheme instead of a simple filesystem hierarchy, which should actually make it significantly easier to spot patterns (for example, seeing that there are now eighty-seven different drivers for capacitive touchscreens, or whatever), all without bloating the tree that everybody has to download.

  • Subject all kernel API changes to a formal API review process in which no API change can go in unless the owners of all drivers in that area agree that the design is acceptable and will meet with their needs. Set up a reasonable set of rules of engagement (e.g. A. don't shoot down the idea just because you don't need it, B. don't shoot down an idea without proposing an alternative). And so on.

  • Redesign the kernel interfaces in an object-oriented language. Such designs make it more likely that drivers can extend the interfaces without requiring major changes to the core code. The Linux kernel sort of halfway adopts this approach insofar as code reuse is concerned, but does so in ways that aren't particularly clean and neat.

    For example, if I were writing an ATA driver and needed to do almost everything the same way but change the behavior of one function in some other library... say down at the block device layer, I'd either have to make a change to the block device layer with some special case detection code or I'd have to copy entire swaths of code at the ATA device layer and change the calls to that function to point to my own function. Eventually that might become a function pointer variable, but until then, it's a mess (and, arguably, huge piles of function pointers are still something of a mess).

    With an OO language, I'd just override one method in my class and I'd be done. No muss, no fuss.

I'm not holding my breath about any of these, though.

Re:Backwards? (1)

sjames (1099) | more than 4 years ago | (#31879782)

The thing is though, I've seen that argument since the mid 2.0.x kernels. The ABI hasn't happened and the Linux kernel hasn't shriveled up and died.

It's not like the interface for a driver changes every single release either. There are a number of out-of-tree drivers that compile and work fine for most of the 2.6.x series (perhaps all, I haven't tried them all). So it's not exactly a lot of work to keep current. There's no real call in an embedded device (or server for that matter) to slavishly track every kernel update either.

If they have tens of thousands of drivers, they have MUCH bigger problems than just the kernel.

Re:Backwards? (5, Informative)

Sponge Bath (413667) | more than 4 years ago | (#31878656)

That said, if you're keeping your driver closed it's a problem you're bringing upon yourself.

I should have been more clear. I'm talking about drivers in the main kernel source. I know the linux kernel mantra: binary only drivers are evil (I agree), out of tree open source drivers are slightly less evil. I think out of tree open source drivers can be useful when inclusion to the main kernel is denied because some critical functionality is deemed unnecessary by the gatekeepers who require it to be removed before consideration. But I'm not even talking about that.

Last I checked, changes to the interfaces by someone puts the onus on them to fix all the calls to it in the kernel...

That's the theory. Here is how it works in practice: A pet project or cosmetic change that touches a lot of code is implemented and then dependencies are grepped. The dependencies are fixed up in a cut and paste way. Sometimes more important drivers get some review to make sure nothing breaks. Everything else just gets shipped if it compiles. Then when that kernel is used in a distribution, sometimes years later, many drivers are suddenly broken and you have to back track to see which change took it out. If someone has a lot of time and desire to support a "lesser" driver then they can spend all of their time playing catch up, but that wears out volunteers quickly and annoys commercial vendors.

Re:Backwards? (1)

jhol13 (1087781) | more than 4 years ago | (#31880046)

All drivers are binary only to those who are not willing to compile, fix, debug and test. ALL, even those on kernel tree as they are not tested either.

Very, very few drivers get into the kernel tree within reasonable time period, several years of driver hell is not INMSHO acceptable.

Re:Backwards? (1)

10101001 10101001 (732688) | more than 4 years ago | (#31880098)

Last I checked, changes to the interfaces by someone puts the onus on them to fix all the calls to it in the kernel...

That's the theory. Here is how it works in practice: A pet project or cosmetic change that touches a lot of code is implemented and then dependencies are grepped. The dependencies are fixed up in a cut and paste way. Sometimes more important drivers get some review to make sure nothing breaks. Everything else just gets shipped if it compiles. Then when that kernel is used in a distribution, sometimes years later, many drivers are suddenly broken and you have to back track to see which change took it out. If someone has a lot of time and desire to support a "lesser" driver then they can spend all of their time playing catch up, but that wears out volunteers quickly and annoys commercial vendors.

Unfortunately, that's a simple fact of life. The kernel has two main responsibilities: make sure the system doesn't crash and make sure that a process doesn't exceed the authority that's granted to it. Hardware drivers, by definition, have to access hardware. While it's possible in some circumstances to create an all-encompassing kernel driver and ferry out actual hardware interface handling to a user process in a stable and secure way, in most circumstances such amounts to create a huge gaping security hole which allows for nearly trivial system crashes.

Meanwhile, within the kernel itself there's a lot of consideration that has to be given to a lot of very varied considerations, from low latency hardware access to high scalability and utilization. While this has translated into various "pet projects", in general they are efforts to take an idea an outstanding problem in one or several part of the kernel and solve them. Enough times they're incomplete solutions which only become apparent as new problems are discovered. In short, the kernel's efforts to be all things to all people has at times required significant rewrites, but the overall effort has been generally worth it.

So, while I certainly understand your feeling about significant code churning and not enough testing, I think the kernel would be in much worse shape if consideration was given more to slow and decisive actions. Yes, this does translate into volunteer churn as well, but so long as "pet projects" are more geared towards the pragmatic and less of the political, I think most volunteers who sought out Linux for pragmatic reasons are a lot less likely to be dissuaded by yet another pragmatic push to do things better.

Re:Backwards? (1)

gbjbaanb (229885) | more than 4 years ago | (#31880696)

Unfortunately, that's a simple fact of life

it is if you accept the status quo. If you took all drivers out of the main tree and created a new tree specially for driver code, not only would the kernel suddenly get smaller and easier to work with (as you at least wouldn't have to download all that useless-to-you driver code) but the distinction between them would help to keep drivers as separate, truly distinct modules.

Of course this only happens with a stable ABI. Break that every version and all that driver code starts to wither. Keep it and you won't have to keep going back to fix up the interfaces. A stable ABI would be a good thing.

And, no that doesn't mean the interfaces couldn't ever be changed, you can change them in major versions of the kernel, just that anything built for 2.6.0 should still work with 2.6.100

It won't be perfect, but it'll be a lot easier to manage for driver writers. I can't see how it would be too much of a hardship for kernel developers either, unless they only churn the code in an amateur 'just hack it until it works' way.

Re:Backwards? (1)

jhol13 (1087781) | more than 4 years ago | (#31880028)

I have had several years of driver hell, when two or three machines have constantly died because FOSS drivers have stopped working in every kernel security update (which occured about monthly for 8.04).

Now the eee.ko driver which gives 900MHz on Eee701 does not even compile (on 10.04beta). How do you explain it? It is FOSS, I did not "bring it myself", but ...

All this because some idiot has religious hate against "proprietary".

Re:Backwards? (1)

Daengbo (523424) | more than 4 years ago | (#31880366)

Learn the difference between the Linux kernel and Ubuntu. Ubuntu uses a modified kernel. Talk to your vendor.

Re:Backwards? (1)

MichaelSmith (789609) | more than 4 years ago | (#31880210)

Once I write something, Free or not Free, I prefer that it stays written, unless there are good reasons for the underlying system to change.

Re:Backwards? (5, Insightful)

Daniel Phillips (238627) | more than 4 years ago | (#31878498)

The truth is, Google doesn't really get open source even though its livelihood depends on it.

Re:Backwards? (1)

cynyr (703126) | more than 4 years ago | (#31878574)

in kernel drivers should be an issue. The module ABI/API changes as needed, but this has already been hashed out. Opensource you diver and get it in the kernel and it will work across versions. want your's to live outside the kernel (nvidia) you maintain it.

Re:Backwards? (1, Interesting)

Anonymous Coward | more than 4 years ago | (#31880370)

Nope, the embedded market is the opposite, and is like the parent describes.
          In the mainstream, you have perhaps nvidia and others who make closed source stuff dreading any disruptive shifting of the internals, while the kernel developers will make the chances needed to make things work and improve the kernel.

          Embedded? From THAT point of view, the kernel is the mainline and what to aspire being compatible with, while they may have custom hacks to make the kernel loadable by a boot loader, they may have custom one-off drivers (One-off? I mean, instead of doing any existing plug-n-play, using the kernel to set up DMA and I/O, etc., the driver may just do it itself. Perfectly functional but completely non-portable, and inappropriate to plop in the mainline kernel source in that form.) They may have custom optimizations for either speed or space, that are also non-portable. And then they endeavor to re-port their custom changes to newer kernels from time to time.

          Android specifically? From what I heard, there were a lot of ARM optimizations and drivers. The ARM improvements are probably already mainline, and drivers being implemented when possible. BUT, although the kernel has plenty of lock types already, Google introduced a new one seemingly superflously, and the drivers tend to use it instead of one of the numerous existing lock types. They introduced a new security model, even though there's users&groups, Access Control Lists, and 1 or 2 additional VERY flexible security systems already in the kernel tree. They also have their frame buffer drivers implementing a new type of framebuffer Google implemented instead of just showing as a standard Linux framebuffer, and making improvements to that framebuffer code as needed. These three are the real issues from what I've read, the kernel guys would VASTLY prefer the lock, securtiy model, and extra framebuffer type not go in kernel unless Google makes a VERY compelling case there's a reason for it.

Tricky (5, Funny)

Monkeedude1212 (1560403) | more than 4 years ago | (#31878414)

"{
        '{
                "{
                  }"
                "{
                    }"
          }'
}"

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?

Re:Tricky (1)

Zixaphir (845917) | more than 4 years ago | (#31878762)

WRONG!

It is three quotes and a double quote. The distinction is relevant!

Re:Tricky (0)

Anonymous Coward | more than 4 years ago | (#31878924)

LOL... very good! You made my day!

Re:Tricky (1)

LynnwoodRooster (966895) | more than 4 years ago | (#31879404)

I see you used spaces rather than tabs... How anti-developer of you!

Re:Tricky (1)

Internalist (928097) | more than 4 years ago | (#31879556)

I see you used spaces rather than tabs... How anti-developer of you!

Somebody's clearly not a Pythonista [python.org] . (oh I know, it's an awful name)

Cheaper costs (5, Insightful)

girlintraining (1395911) | more than 4 years ago | (#31878420)

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.

Re:Cheaper costs (1)

ZERO1ZERO (948669) | more than 4 years ago | (#31878480)

Yes.

I still waiting for some kind of phone etc that isn't crippled in that way. I just don't have a mobile phone now. The operators are creaming way too much off the top and giving so little back.

I have a 10 meg line for a tenner a month to my house and can do pretty much whatever I want with it. The fact that operators charge 5p or what ever to send a 160 byte SMS message, or if I Pay 25 a month for 24 months I can send 500 or 1000 just sucks. It needs to be £5 for a month and including internet access. Some providers charge 60p per meg if you fetch more than the limit per month

Re:Cheaper costs (1)

tepples (727027) | more than 4 years ago | (#31878602)

I still waiting for some kind of phone etc that isn't crippled in that way.

Then buy one from the manufacturer instead of from a carrier.

I have a 10 meg line for a tenner a month to my house and can do pretty much whatever I want with it.

Spatial multiplexing of RF signals over a wired connection is easy: just pull another insulated cable through existing conduits. Doing so over the air is harder because there's no copper or fiber waveguide to keep your signals from mixing with other subscribers' signals.

Re:Cheaper costs (1)

h4rr4r (612664) | more than 4 years ago | (#31879684)

The signals are not the issue, you talk to the cellular gear via ATT. This is the same method that PCs using usb cellular modems use.

Towers are expensive for AT&T (1)

tepples (727027) | more than 4 years ago | (#31880742)

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.

Re:Cheaper costs (5, Insightful)

EvanED (569694) | more than 4 years ago | (#31878522)

It's a real problem -- Android is easily the most hackable phone out there.

I'm not so sure... I think the Nokia N900 has got it beat.

Re:Cheaper costs (4, Interesting)

girlintraining (1395911) | more than 4 years ago | (#31878586)

I'm not so sure... I think the Nokia N900 has got it beat.

Yeah, but who's heard of the Nokia N900, or even knows what that means, outside geek circles? On the other hand, billboards and TVs everywhere are blasting out "Droid does". For bringing a hackable system to the masses, Android has it beat.

Re:Cheaper costs (4, Insightful)

drsmithy (35869) | more than 4 years ago | (#31879364)

Yeah, but who's heard of the Nokia N900, or even knows what that means, outside geek circles? On the other hand, billboards and TVs everywhere are blasting out "Droid does". For bringing a hackable system to the masses, Android has it beat.

But "the masses" aren't interested in hacking it, thus making said hackability essentially irrelevant to anyone who isn't in "geek circles" anyway.

Re:Cheaper costs (3, Insightful)

girlintraining (1395911) | more than 4 years ago | (#31879778)

But "the masses" aren't interested in hacking it, thus making said hackability essentially irrelevant to anyone who isn't in "geek circles" anyway.

They said the same thing about the internet, twenty years ago. And yet look what the hackers of the world built out of the refuse of wires and chips that the corporations of then said was useless and had no commercial value. Now they're fighting to tax it, control it, and some countries have declared it an inalienable human right to have it.

Maybe it has no value to them, but that's because they don't know the value of it yet. It's our job to find it and tell them. You just haven't been around long enough to realize the purpose of your own learning yet. Your individuality, your knowledge and talents, are not for your own gratification. The purpose of the democratic process, which the internet comes closest in form and function, is not to create a great country, or great works, but to create great people.

Hacking is therefore the highest form of the democratic process; Not because of what we do, but for what we share.

Re:Cheaper costs (1)

c0d3g33k (102699) | more than 4 years ago | (#31880194)

Thanks, girlintraining, that was an awesome post.

The purpose of the democratic process, which the internet comes closest in form and function, should not be to create a great country, or great works, but to create great people.

Brilliant. (I fixed it a little for you. It reads a little better to me that way).

Re:Cheaper costs (3, Informative)

cynyr (703126) | more than 4 years ago | (#31878628)

i second that.

you have hardware level access to the N[789]00 devices. I would like an ipad sized n900. that would be a great device.

Re:Cheaper costs (0)

Anonymous Coward | more than 4 years ago | (#31879298)

... the N[789]00 devices.

You mean the N770/800/810/900 devices? I'm not sure how Nokia comes up with those numbers, but my present theory is that they have for some unknown reason decided that the product numbers should form a Golomb ruler [wikipedia.org] .

Re:Cheaper costs (1, Offtopic)

bug1 (96678) | more than 4 years ago | (#31878788)

Dont they both have "binary only" components ?

Or do you mean crackable ?

Re:Cheaper costs (1)

Microlith (54737) | more than 4 years ago | (#31878572)

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.

That's only because you're buying phones from your carrier, who demands they be crippled accordingly. Every once in a while you can get good, un-crippled phones from your carrier but they tend to carry higher fees.

The trick is to go to device vendors who recognize who their true customers are, namely the ones who use the phone daily. I bought an N900 and it gives Android a severe run for its money in terms of hackability and compatibility with existing Linux platforms. The catch is that you can't buy it in the US except at full price from Nokia, and most people stumble at spending $500 on a device they consider to be nothing more than a phone with a big screen.

Re:Cheaper costs (0)

Anonymous Coward | more than 4 years ago | (#31879172)

hackability and compatibility with existing Linux platforms.

Oh yea, man, hackability and compatibility with existing Linux platforms. Phone users want that by the shitload...

Re:Cheaper costs (1)

h4rr4r (612664) | more than 4 years ago | (#31879698)

The real issue is the only carrier it works with has shit coverage. T-mobile has great plans and is even willing to let you pay off phones over 20 months at no interest, but their coverage sucks.

Re:Cheaper costs (1)

TheRaven64 (641858) | more than 4 years ago | (#31878832)

I'm confused by your second paragraph, because that's pretty much exactly how it does work. My SIM enables the device that contains it to make calls or use the data service. I can drop it into a phone or a computer, although mostly if I want to use a computer while mobile and be online I use the bluetooth DUN profile on my Phone, because it's less effort than removing the SIM and doesn't prevent me from receiving calls. I've never come across a firmware update for any phone I've owned removing functionality either, but maybe that's because I don't buy phones from the service provider.

Re:Cheaper costs (1)

girlintraining (1395911) | more than 4 years ago | (#31879258)

I've never come across a firmware update for any phone I've owned removing functionality either, but maybe that's because I don't buy phones from the service provider.

You're european.

Re:Cheaper costs (1)

LynnwoodRooster (966895) | more than 4 years ago | (#31879456)

Or maybe he has a phone that doesn't allow OTA updates like Windows Mobile? Never had a problem with OTA updates since I've had WinMo smartphones for the last 8 years... And I can load pretty much any program I'd like, independent of what the carrier desires.

Re:Cheaper costs (1)

linj (891019) | more than 4 years ago | (#31878938)

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.

You can eject your SIM card from your phone and plug it into your computer. My father actually has two SIM cards from T-Mobile; one resides in a UMTS modem in his laptop (unlocked, bought in Singapore), and the other is in a Blackberry. I'm not sure if there's software to take phone calls, but you can definitely Skype off of it.

I've got an HTC Touch Pro 2. It runs Windows Mobile 6.5 and it's now unlocked and can flash any firmware it wants (3rd party developers have even got Ubuntu and Android to run on it, although with less hardware support). However, even if it were locked, it can sync all my emails, texts, whatever over Bluetooth. With MyPhone (a pretty good Microsoft product), it syncs all that even into the cloud. MyPhone can sync documents, pictures, music, as well. I can pull pushmail off Gmail as well as calendar and contacts, so even if I flash a new 3rd party ROM, which is a really nice ability that isn't officially advertised, I can easily resync and be off again.

That said, all this I first experienced overseas. When I came to the US for college, I suddenly realized how much the mobile companies cripple their consumers. Because I couldn't really live without these capabilities (and others couldn't either!), it's easy to find information online to help you achieve what you're imagining.

Re:Cheaper costs (0)

Anonymous Coward | more than 4 years ago | (#31879100)

AT&T, T-Mobile, Verizon, etc. are NOT manufacturers. This is what they sometimes want you to believe, but extremely far from the truth. They specify how they want the software to behave, and the only way for manufacturers to sell through them we have to agree to their terms. No one wants to pay the full up front cost so there's no alternative.

Re:Cheaper costs (1)

upuv (1201447) | more than 4 years ago | (#31879328)

"My Sidekick recently lost the ability to send files to my computer over bluetooth. Why? "

You bought a phone controlled by the operator.

----
"It's complete and utter bullshit that cell phones are as powerful now as desktops were ten years ago "

Actually I dare say the phone is more powerful than the PC of 10 years ago. My phone can drive 720p straight to my TV. No way a PC I could afford could do that 10 years ago. My phone also communicates at very good broadband speed over 3 techs. bluetooth, 802.11g, & 3G. No way my P133 could communicate anything like that. As for Capacity I have a 32Gig microSD card in it. 32Gig was a pipe dream 10 years ago.

Then there is touch screen, 5 meg camera, gps Web browsing etc.

Just because you got roped into a bad contract and a bad phone combo it does not mean that the entire state of the industry is defined by your choices. I did my research I bought my phone separately from my contract things are better.

Get off your butt and do some research make choices based on your requirements and hunt for the best deals. And accept responsibility for your choices. Cause some times we all make bad ones.

Re:Cheaper costs (0)

Anonymous Coward | more than 4 years ago | (#31879406)

find a better option in the US? Seriously. For the 98% consumer, find a better option. Go to any place that advertises cell phones, and find a better option.

Re:Cheaper costs (1)

h4rr4r (612664) | more than 4 years ago | (#31879710)

Eris $79 and pay me $20 to root it or do it yourself.

Re:Cheaper costs (1)

h4rr4r (612664) | more than 4 years ago | (#31879680)

Then why did you buy it?

An Eris is $79 and can be rooted within 15 minutes of having it home. Heck, 2 minutes if you install the sdk and get the files you need before you go pickup the phone.

Re:Cheaper costs (1)

DryGrian (1775520) | more than 4 years ago | (#31880296)

Where the hell can you get a HTC Eris for $79? Looks to me like they are in the $400+ range.

Re:Cheaper costs (1, Interesting)

Anonymous Coward | more than 4 years ago | (#31880044)

I would add a qualification to the statement that Android is the most hackable phone out there.

Depending on the model you get, the phone might come pre-rooted and ready to flash custom images. Or you can get it into fastboot mode so you can flash something.

Or a model might be harder to root and require a bug in the firmware signing, the OS, or something along those lines.

Or some models just may not receive the installed base to attract the top notch developers that are willing to take the time and trouble to get root.

And as time goes on, some carriers are demanding that the Android models be locked down. For example, the Backflip that doesn't allow sideloading of apps.

And it only is going to get worse. We are going to see models which have no ADB access at all, and where the only way to flash them is either an update.zip or an OTA update. There are already apps like the Blizzard Authenticator out there which refuse to run if they see a file named /bin/su. And it is going to be a matter of time before we see a process killing background task that will auto-kill anything that isn't on a signed manifest, so if someone gets a root shell, it gets killed immediately. And of course, someone can make a process to detect rooted phones and disable them and the owner's Google account permanently.

The moral: Only buy devices on providers who are root friendly, such as an Android Dev Phone (assuming they make an adp3 and higher with modern CPUs), a Nexus One, or most HTC devices. If possible, buy a popular model where Cyanogen or other modding deities will be putting out ROMS out on.

Some providers have android phones, and they are the front line models. Verizon and T-Mobile come to mind. Other providers have Android phones, but definitely are there only as token phone, as they have their own smartphone they are championing like the iPhone.

If people vote with their wallets with this issue, we might still have a modding community in the future.

Re:Cheaper costs (0)

Anonymous Coward | more than 4 years ago | (#31881082)

Get a Nokia N900. If you think Android is hackable, wait until you have an OS which is -just- regular, everyday, Linux.

Developer's first thought (0)

Anonymous Coward | more than 4 years ago | (#31879508)

That is going to be one killer merge.

I am against this. (2, Insightful)

FlyingGuy (989135) | more than 4 years ago | (#31879916)

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.

Re:I am against this. (0)

Anonymous Coward | more than 4 years ago | (#31880432)

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.

So, pretty much like almost everything else in the kernel then?

Re:I am against this. (1)

Luke has no name (1423139) | more than 4 years ago | (#31880498)

Because volunteers are consistently reliable maintainers.
Because companies don't often contribute to the kernel.

I get your concern, but don't think it's called for. Besides, doesn't code have to meet guidelines to get into mainline?

Load More Comments
Slashdot Login

Need an Account?

Forgot your password?