GNU C Library 2.17 Announced, Includes Support For 64-bit ARM 68
hypnosec writes "A new version of GNU C Library (glibc) has been released and with this new version comes support for the upcoming 64-bit ARM architecture a.k.a. AArch64. Version 2.17 of glibc not only includes support for ARM, it also comes with better support for cross-compilation and testing; optimized versions of memcpy, memset, and memcmp for System z10 and zEnterprise z196; and optimized version of string functions, on top of some quite a few other performance improvements, states the mailing list release announcement. Glibc v 2.17 can be used with a minimum Linux kernel version 2.6.16."
Re:Christ... (Score:4, Interesting)
really don't understand why a few people here attack anything to do with Linux. Linux is different, not a threat.
It is a threat. A threat to MS developers, a threat to MS shareholders, a threat to those who earn their living cleaning malware off of folks' computers.
For the rest of us, though, it's a blessing.
eglibc (Score:5, Interesting)
Looks like the eglibc fork was a good thing for the project. Rather than having one maintainer that resists and fights an architecture for personal reasons, the project is now being proactive in integrating a new ARM architecture.
Now if we could only get away from having so many Android-only bionic-targeting blobs.
Bleh (Score:3, Interesting)
Re:Christ... (Score:3, Interesting)
Linux is no threat to anyone, its just an excuse people like to use.
Programers, even MS ones can move elsewhere. Linux won't 'take over the world' ever if the $7/hour programmers can't write code for it. Most companies are unwilling to spend large sums of money for programmers who have their head up RMSes ass and think they're worth ridiclous sums of money, so its not a threat. Programming isn't all that difficult if you have the proper info. Not everyone can deal with the requirements of C, but then thats why you see companies like Google coming up with new languages to solve that problem so they can waste less time with programmers who are meticulous about memory management and more time getting shit done.
MS Shareholders, meh, thats debatable. MS writes apps for other OSes already and makes a fortune off of them, hell Office is the best Office for OSX, Apple doesn't even bother making a truely competing product. Pages/Numbers are like MS Works, not Office. If the world really did jump ship to Linux, they'd move Office over as well. They aren't going to go out of business of some political ideal, thats what Linux people do. MS will follow the money, everything they do is about the money. Right now its more profitable to spend some of that money keeping people on Windows, but if that changes they won't roll over and die.
If Linux became main stream, it would just get malware as well. You don't need to exploit a machine to get malware on, you need to exploit a user. Its been easier to exploit users than it has been to exploit windows since AT LEAST XP SP2, probably a little before that. Windows Vista dropping admin as default pretty much ended the easy way to get an entire machine. But why do you need an entire machine? You don't. You just need to be able to run apps, and the less intrusive you are the longer you'll go without being detected. Windows gets targeted due to market share. Android sees some of the same issues due to its popularity, but lets not recognize that and pretend its perfect, shall we? Windows users don't notice malware until they've got 900 different variants installed that do something like change their home page. You are no different just because you run Linux. You wouldn't notice intelligent malware any faster than a Windows user would, you just think you are immune. You probably aren't stupid enough to download the wrong thing most of the time, but I'd be a months pay that you've only not been caught in a malware scam by dumb luck and obscurity. Eventually, something will come through that is so close to legit looking that it will/has got you and the only thing that stopped it was that it wasn't targeting your OS. Thats only because you're OS isn't popular enough to waste their time on, not because its saving you.
For the rest of us, though, it's a blessing.
While some people prefer to live in a world of obscurity (thats not exclusive to Linux fanboys btw, you aren't any more original than goths), its rather silly to call it a blessing. Instead of removing malware you spend your time dicking with things that were solved 20 years ago but everyone thinks they need to reinvent and do differently without ever asking why it should be done differently in the first place. Its no more a blessing then any other mental illness, you just don't recognize it.
Re:Take THAT (Score:5, Interesting)
In fairness, this is complicated a lot by two issues:
1. Many of the optimizations that help things like memcpy, memcmp, etc. are utterly wrong and backwards in any loop that actually DOES SOMETHING in its body; they only end up being optimal in the degenerate case where everything but the load and store is loop overhead and the optimal result is achieved by eliminating overhead. And on some CPU models such as most modern 32-bit x86's and some 64-bit ones, the optimal result is actually attained with a special instruction that's not usable in general for more complex loops (i.e. "rep movsb"). Factors like these make optimizing these specific functions in the compiler a task that's largely separate from general-case optimization, and when the main target libc is already providing the asm anyway, there's little demand/motivation to get the compiler to do something that won't even be used.
2. Distros want a binary library that can run optimally on all variants of a particular instruction set architecture. Relying on the compiler to optimize functions for which the optimal variant is highly cpu model specific would only give a binary that runs optimally on one model, unless a lot of logic is added to the build system to rebuild the same source file with different optimizations. This is not prohibitively difficult, but it's also not easy, and it's not worthwhile when the compiler can't even deliver the desired optimization quality yet.
Overall I agree that machine-specific asm in glibc (and elsewhere) is a disease that results in machine-specific bugs and maintenance hell, but when there are people demanding the performance and pushing benchmark-centric agendas, it's hard to fight it...