Without defending Chrome team here; when a distro provides long time support (say > 1 year) I don't think is upstream responsibility to support the packages for that period of time.

If the distro is upgrading the browser package I think that may break the API/ABI stability that a long time support distribution should provide, so I can't see why this is a Chrome problem.

Also it sounds wrong that a web browser depends on the kernel version; so I'm with you that there are other browsers supporting Linux.

I'm sorry, but we ARE talking about arguably the most important piece of software running on an end-user device not being supported on a less than ONE YEAR old distribution. Not 5 years, not 15 years. Less than a year.

The result of your argument is basically returning to dark ages of having to support old broken IE6 because the vendor couldn't be arsed to support an older platform. When did dropping support for a less than a year old product become something to be applauded?

My argument is that open source is what it is. Read the license and you'll find that there's nothing about free support; and if for some reason it breaks... you keep both pieces.

I know this puts distributions in a bad situation, but unless the users can force the upstream project to be more user friendly, I think the only option is to switch to a different software (hint: Firefox).

You seem to think I endorse Chrome team's behaviour on this, and I don't. That doesn't change reality though.

Open source is what it is, but not all open source is equal.

I often see versions of this argument more or less opposing complaints against open source products. It has some merit, depending on circumstances. Circumstances are important.

Chrome isn't some guy's spare time project, or something done by a team of corporate and personal volunteers. Chrome is a product. Looking for Google's valuation comes up with an analysis that it will likely be the first or second company to be valued at a trillion dollars. Chrome enjoys nearly a 50% browser market share. Google has one of the strongest hands in shaping technology today, and it seems they aren't always making the best decisions; not that one would expect such a large company to always make the best decisions (or that there would be a consensus on _what_ is the best decision).

I've never paid for anything made by Google, but I am a customer regardless; so are you. Money hasn't changed hands but they have certainly profited from the relationship, and so have I.

---

"If you don't like it, submit a pull request" -- that response always rubs me the wrong way. To be clear, some of the loudest complainers about open source projects are entirely too entitled, but those that aren't do have a point sometimes. I believe that whether you are a guy with a hobby making $0 or a company valued at $3.8 * 10^11, you owe it to yourself and your users to maintain a certain level of quality if you create a popular product. More of a personal philosophy than the expectation of a legal obligation of course, but I think just as valid.

Good comment, thanks.

I always have mixed feelings when Google has a project with two versions: the open source one and the binary only based on that one. Chrome and Chromium are not quite the same thing after all.

I don't know for sure, but for Google Chrome may be the product and Chromium just a convenient way to make it happen.

Well put. Although someone makes a LTS distribution, it really does not mean 3rd parties would be compelled or required to support that steadily aging platform.

When you combine the fact that not even Ubuntu developers really support the LTS (9/10 of the developers flock to the newest release, and the bug reports towards LTS get generally ignored - the LTS tagged bug queues are graveyards), I can not see the whole point of making LTS version available in the first place.

That being said, 7 months is a bit small window of support for a specific platform component. I would understand not supporting 1-2 years old kernel/glibc/whatever, but 7 months is really not enough.

Well it's tricky, MSFT actually ties certain vendors to support their OS as long as it's under support. For example if you want to participate in the WHQL program you have to have a version for each supported MSFT OS.

Chrome is still supported on Windows XP, so is FF, on Windows vendors not only do not seem to drop support but actually extend beyond MSFT's requirements.

While canonical is surely not MSFT but when you make an LTS program you either have to get 3rd party vendors on board, or manage and update the packages yourself to make sure they will be compatible with your own software, or to make updates to your LTS distro to keep it compatible with the newer packages.

While the OS is quite important, it's usually not the piece of software neither end users nor corporate users care about, for them it's just a platform to run the software they actually use. And if the platform loses support for a major piece of software after less than a year you can't blame anyone besides the maintainer of that platform.

The Linux community really needs to get their shit together, with every step forward these past few years they've seen to be taking 2 steps back. With PAAS becoming more and more popular, it really should only take Apple to release a general server OS (no OSX Server doesn't count) to push it back completely into the realm of BBS hobbyists these days.

Actually both the bug and the kernel dates back to 7 months old as mentioned in the OP so it would actually be much shorter than 7 months.

A year is not along time 10-20 years is a long time

7 months is too short, but 10 years is too long to go for a workstation, which is where Chrome would be used.

What about Windows XP? It still holds more than 50% Chinese market.

What about XP? It's old, unsupported and littered with security holes. It has 50% penetration in China because it's the last version of Windows with easily circumvented piracy countermeasures and because it runs better on 10-year-old hardware. I don't think it's any guide to how long long-term support should be.