Slashdot Mirror
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.
It means that they just won't bother to compile a 32-bit build of the closed-source Chrome.
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.
The chromium open source tar ball will continue to be updated and support 32-bit x86 and ARM for at least the next 5 years.
The proprietary Chrome binaries which include features listed below will not longer be updated after March 2016:
- AAC, H.264, and MP3 Support
- Adobe Flash (PPAPI)
- Google Update
https://groups.google.com/a/ch...
Someone you trust is one of us.
And? Is Chrome supported on Win10 for 32 bit? Ah nope, as the summary states, Google stops delivering 32bit versions of Chrome for all OS. On a side note: Linuxes come with Firefox which works perfectly on 32bit hardware.
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.
The most important feature of the closed-source Chrome is it's the way to stream Netflix on Linux.
That's the only reason I've ever used Chrome on any desktop computer.
They're talking about platforms that get updates.
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 ]
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
As a software developer who has worked for companies supporting multiple active platforms both 32-bit and 64-bit, 64 bit isn't the point. It's the massive burden of maintaining multiple build streams, tool-chains, test servers, release images, etc. for a dying platform (32-bit). 32-bit needs to die so this waste is eliminated.
I guess if you are a software shop that doesn't develop a single application that can benefit from 64-bit, it may make sense to stick to 32, but is that really even a possibility? Memory use is -not- the only consideration. 64-bit CPU modes often bring along larger register files and advanced instructions, which alone is a good reason many applications may want to become 64-bit vs 32.
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.
The browser may not need more than 4 GB of memory but it sure wants the extra registers in 64 bit x86, and on ARMv8 you definitely don't want to power up the 32 bit module if you can avoid it.
People keep blaming Netflix for decisions enforced upon them by production studios.
I'm god, but it's a bit of a drag really...
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.
Not really true.
Only addresses/pointers [and longs] double in size. Most generated code uses the lower 8 regs were possible, so no prefix byte. Also, offsets can be smaller due to RIP relative addressing. Because the ABI specifies the first six function arguments are in registers, no wasteful pushes on calls. Also, because of the extra registers, this reduces "register pressure". That is, you don't have to store the value in a register to the stack frame just to make room for another value because you don't have enough registers to go around ["stack spill"]. So, you do fewer extraneous memory accesses. Because of the 64 bit wide registers, you can do real 64 bit multiply/divides.
The CPU instruction execution unit is much smarter than you imagine. Some of the instructions may be larger, but they're fetched a cache line at a time. They then get predecoded and put into a cached instruction execution queue.
The execution unit doesn't just "look at one instruction, execute it, then forget about it". While executing an instruction, it's looking ahead at several instructions to see which ones can be executed simultaneously with the current one. Within a given function, the execution unit just refetches from the queue and doesn't even need to redecode instructions from the L1 cache
With more registers, it is easier for the execution unit to detect parallelism and perform out-of-order, parallel, and speculative execution that make things go faster. If something gets "spilled" back to the stack, the compiler knows it did this, but the execution can't [and shouldn't] because it can't discern whether the stack write was for "spill" or whether a function that will need the data in memory will [soon] be called.
I regularly write and build programs and I regularly disassemble them to see if the code is efficient enough. They are quite compact.
And, given all of the above, overall, 64 bit is about 30% faster. Based on what I've read, and what I've benchmarked.
Like a good neighbor, fsck is there