Google To Drop Chrome Support For 32-bit Linux
prisoninmate writes: Google announces that its Google Chrome web browser will no longer be available for 32-bit hardware platforms. Additionally, Google Chrome will no longer be supported on the Ubuntu 12.04 LTS (Precise Pangolin) and Debian GNU/Linux 7 (Wheezy) operating systems. Users are urged to update to the Ubuntu 14.04 LTS (Trusty Tahr) release and Debian GNU/Linux 8 (Jessie) respectively. Google will continue to support the 32-bit build configurations for those who want to build the open-source Chromium web browser on various Linux kernel-based operating systems. Reader SmartAboutThings writes, on a similar note, that: Microsoft is tolling the death knell for Internet Explorer with an announcement that it will end support for all older versions next year. Microsoft says that all versions older than the latest one will no longer be supported starting Jan. 12, 2016. After this date, Microsoft will no longer provide security updates or technical support for older Internet Explorer versions. Furthermore, Internet Explorer 11 will be the last version of Internet Explorer as Microsoft shifts its focus on its next web browser, Microsoft Edge.
The source tarball will no longer support 32 bit Linux? Or are they pulling closed source hijinx?
Yesterday, Google Announced that they will drop support for their product ${product}. Google will continue to support the product for the next few months[, offering users the opportunity to download a tar file of their data]. Google said they chose this step because they wanted to "do the right thing", and "continue to enhance our products for all of our users".
The users of ${product} weren't happy at all about the announcement. Twitter user &{name} writes, ${random_user_quote here}. On other internet platforms, the responses were similar.
I run 32 bit versions of Linux on older hardware that doesn't require 64 bit, will other browser developers be following in Google's foot steps? I can always switch from Chrome to Firefox or another browser but is indication that 32 bit Linux support is going away in general?
I know that this is hard to digest for a Linux neckbeard, but Windows 10 is actually a great way to breathe life to an old computer. Even 32-bit is fully supported. There, I said it.
This is great. Now perhaps they could make a 64-bit Linux version of Google Earth available? Pretty please?
So are they killing the Android builds of Chrome as well, or does the summary suck as usual?
Of course. A company is in the business where they get their revenues. Airlines get their revenues from flying people around. Airlines do in fact have excellent tech for figuring out demand, routes, and other things. As a matter of fact, American Airlines and its SABRE system made data processing (IT to you kids) history in the 70s.
See, Google is an advertising company. People are under the erroneous impression that they are a tech company. Any and all tech they develop is to enhance their business - advertising. They may develop tech that initially doesn't have any advertising purpose, but eventually that is what will happen. And by advertising purpose, I mean either showing ads or collecting consumer data.
Facebook and Yahoo! are Google's biggest competitors and they are not tech companies either.
Anyway, calling Google a tech company is just as ridiculous as calling Amazon a tech company or Delta Airlines or JP Morgan Chase.
That's too bad since most Android phones are 32-bit right now.
Looks like it's about time to upgrade my Vista machines.
Modern app appers use 32 APPS, not 32 LUDDITE bits!
Apps!
For the record...
Chrome binaries which include features listed below will not longer be updated after March 2016:
- AAC, H.264, and MP3 Support
It's possible to leverage ffmpeg to give additional codecs support to chromium.
AFAIK Packman's and OpenSUSE's build of chromium use this.
- Adobe Flash (PPAPI)
To be more precise, it's the *bundling of flash* which is unavailable with chormium.
Support for PPAPI can be compiled in Chromium, and if a suitable separate binary is provided, you get working flash version 19.
(Again, Packman's and OpenSUSE's build is done so)
For that matters, it's the same situation with Firefox: there's a plugin called "freshplayer" that enables support for PPAPI plugins in Firefox (it's basically a NSAPI to PPAPI wrapper).
Again with a a suitable binary provided, you get working flash verison 19 (instead of version 11 which was the last version that flash provided for NSAPI).
Though you don't get all the advantage of Google's sandboxing model.
It's povided in OpenSUSE and Packman.
(I don't have experience with Ubuntu, but I strongly suspect that they do the same. Or in any other way, it should definitely be available in some PPA)
"Sufficiently advanced satire is indistinguishable from reality." - [Tips: 1DrYakQDKCQ6y52z6QbnkxHXAocMZJE61o ]
The most important feature of the closed-source Chrome is it's the way to stream Netflix on Linux.
Indeed, Widevine CDN is currently the only supported DRM for Linux users.
And currently, there are howtos floating on the web explaining how to enable support for Widevine CDN plugin in Chromium.
Mozilla has announced that they'll eventually support Adobe's CDN under Linux which should give other alternative to support Netflix here.
"Sufficiently advanced satire is indistinguishable from reality." - [Tips: 1DrYakQDKCQ6y52z6QbnkxHXAocMZJE61o ]
It's ridiculous that in 2015 someone is selling a video service where you can't just use whatever player you want to.
Then what non-ridiculous method of conditional access to video would be acceptable to the companies that fund production of feature films?
I'm not sure one of the examples you chose is the best:
A company is in the business where they get their revenues.
And Amazon Web Services gets its revenues from leasing resources to customers willing to run their software on someone else's computer.
calling Google a tech company is just as ridiculous as calling Amazon a tech company
I don't follow. Is AWS not "tech"? Or does revenue from Marketplace commissions and FBA services outweigh AWS revenue?
So what is Microsoft going to do for IE9 on Vista and Server 2008, both of which are EOL much later than January, 2016? Vista's EOL is April, 2017 while Windows Server 2008's EOL is January, 2020. I wouldn't want an unpatched IE9 running on either OS, where the OS continues to receive security updates, but the browser does not...
Windows Server 2008 is still widely used as it's the last Windows Server OS available as x86... (And Windows Server 2008 R2 is not a free update...)
Windows 3.1x calc: 3.11 - 3.10 = 0.00
I don't mind them dropping support for 32-bit builds so much. Just about any computer that is going to be used to run Chrome (or other heavy browsers like Firefox) is likely already capable of running a 64-bit OS. What does bother me is Google dropping support for Debian 7 and Ubuntu 12.04. Those platforms are still supported by their respective projects. Both only have about 4-5 years of support, so building Chrome packages for them isn't a super-long investment. Why not continue to support them for another year or two, until Debian and Canonical put them out to pasture?
From Internet Explorer Support Lifecycle Policy FAQ, linked in the featured article:
So yes, IE 9 security updates will continue. So will IE 8 updates for those Windows XP users who have applied the "Piece of $#!+ Ready" registry hack.
This is terrible news! My computer won't run the newest version of Internet Explorer. I hope I can find another browser out there...
It's foolish to run any 64-bit browser. A browser should'nt need more than 4gig
and especially since auditing the source is very difficult. I run a 32-bit version
in a 64-bit enviornment and have several windows / tabs going all of the time and
never had a problem. If / when the browser goes awol, my exposure is only a
small chunk of memory and not the whole virtual address space.
CAP === 'convicts'
This is also a blow to the low-cost computing push (RaspberryPi, etc). Virtually all the ARM SBCs are 32-bit today, and their claim-to-fame is having a real browser (Chrome). If they stop 32-bit compatibility, that will greatly harm lightweight browser consumers from smart TVs to 3rd-world computing.
Oh well, there's always Firefox.
Science & open-source build trust from peer review. Learn systems you can trust.
While they would *love* for it to be outright impossible to copy, their goal is to make it as much a pain in the ass to copy as possible.
Let's say they didn't do any of these DRM shenanigans. You could 'wget http://netflix.com/popular_mov...' and have it run in the background at whatever speed the internet provides. You might have a 90 minute film in less than 10 minutes.
If you screen record, then that means your computer is now watching this video and unable to do anything else for the full duration of the feature. For most folks that's just too much trouble, they would just as soon wait til they want to watch it and stream it live if the computer's going to be tied up anyway.
That's the goal of all this gunk, trying to find a way to maximize inconvenience for those who want to use it in a manner they didn't want while delivering what they deem an acceptable experience. Note that a blu-ray rip of a film or series to mkv and then streaming to Kodi I find a much better experience than Netflix, and I find it frustrating that Content and the delivery channel are being linked (have to use a 'netflix' app for some things, a 'hulu' for others, etc). Basically I don't find the situation 'acceptable', but there aren't enough of me to make a difference in the market. Also so long as I have an application that lets me rip media, I can buy media and circumvent the DRM.
On the other hand, for things like Netflix, where the model is explicitly 'rental', it makes some sense. However always-online DRM for *purchased* content that restricts my choice of playback device/application annoys the piss out of me.
XML is like violence. If it doesn't solve the problem, use more.
I already dropped support for Chrome.
Microsoft says that all versions older than the latest one will no longer be supported starting Jan. 12, 2016.
In January my company will upgrade to IE 11, because of this, and probably stay on a current version from then on. It feels so weird. I'm used to having to code for a version of IE that is several years old. It's a good time to be a web developer!
Well, this is disappointing. My mom & dad are on an antique Dell with a 32-bit processor. First OpenSUSE announced they were abandoning 32-bit, and I thought "OK, I'll install Lubuntu or Xubuntu or something." Now Google does this. I had them on Chrome because of the baked in Flash support. I suppose I could get away with Chromium... I think the only site my folks ever visit with video is Youtube. Still, just one more annoying thing.
> "To provide the best experience for the most-used Linux versions"
Ho-hum.
Diminishing returns: https://en.wikipedia.org/wiki/Diminishing_returns
4- to 8-bit: holy mf! a real computer!
8- to 16-bit: wow! we can manage the entire company with that!
16- to 32-bit: that will enable us to solve a lot of technical problems: excellent.
32- to 64-bit: why do we need 64-bit, after all? Oh, yes, the videos, more gradients -- that's nice, I suppose.
64- to 128-bit: glares in games are more real... and something else, I believe... maybe orbit calculation?
128- to 256-bit: meh.
And stop that with more registers, ok? I changed all light bulbs in my house to leds and my electric bill is not 10% of what it used to be.
What's the downside of [just selling WebM or MP4 files with no digital restrictions management]?
The inability to sell more than one such file, as it takes next to no expertise and effort to casually infringe the copyright in a DRM-free file in pristine quality, especially compared to the expertise and effort that the studio needs to investigate such casual infringement.
If a production company comes back and says "no, DRM-free standard files over a standard protocol is unacceptable" then we should ask them just what the hell their agenda is
The agenda is being able to sell more than one copy.
If you stupidly standardize on "use Diffie Hellman for key exchange" and then it turns out that there's a critical flaw in Diffie Hellman, then you're basically an idiot who's written a useless standard.
For the record, the current problems isn't that there's a critical flaw in the Diffie Hellman key exchance itself - there's no fundamental problem in the way Diffie Hellman works.
The problem are the implementation (who are rather lazy in their approach to pick random prime).
Or to put an example: it doesn't matter if AES is the currently most un-crackable and resistant encryption algorithm when everybody repeats one of the vowel 8 times in a row to pick an 8 caracter password:
you'll just defeat it by bruteforcing using a dictionnary only containing 6 entries (on for each vowel).
Same actually happened for DH:
DH works, but some implementation only use small primes, and nearly everbody uses one of the few precomputed prime that comes out of the box.
And the largest part of the work for cracking depends on this prime, so if there's only small number of primes used in the wild, you just need to spend your cracking efforts on those few primes, and bam! you've insta-cracked the communication of everyone clueless enough to use the same prime.
Same also happened with DSA a few year back. It also depends on prime number, cracking DSA also relies on guessing the prime. If everybody picks just one of the few prime of some default list instead of computing a completely random prime, this dramatically reduce the size of the dictionary you need to use to brute force the key. It's possible to crack the private key just by trying the few common prime used by everyone.
"Sufficiently advanced satire is indistinguishable from reality." - [Tips: 1DrYakQDKCQ6y52z6QbnkxHXAocMZJE61o ]