It doesn't mean you can't use gdb, just that libc itself does not try to double as a debugging tool. This is actually a security consideration. For example, glibc prints debugging information if it detects corruption in malloc. But if there's already memory corruption, you have to assume the whole program state is inconsistent; the corruption may be intentional due to the actions of an attacker, and various function pointers, etc. may have been overwritten. Continuing execution, even to print debug output, risks expanding the attacker's opportunity to take control of the program.

FWIW, musl does detect heap corruption. The difference is that it immediately executes an instruction that will crash the program rather than trying to continue execution, make additional function calls that go though indirection (the PLT) and access complex data structures, etc.

If you don't want to switch, that's fine. You're still getting the benefits of musl, because competition has driven the glibc developers to fix, or at least study how to fix, a number of longstanding bugs in glibc.

The main effect of glibc being LGPL is not that companies don't use it, rather it's that nobody making non-free software is willing to static-link it, so you end up with versioning hell. glibc partially solves this problem with symbol versioning, but the solution actually makes the problem worse in other cases: for example, in order to provide a binary that runs on systems with older glibc, people making binaries intentionally link against an older glibc, using the outdated/bug-compatible symbol versions instead of the up-to-date ones.

Of course if your goal is to make sure non-free software is always breaking and giving people problems, that's a potential benefit of the LGPL.

With musl, all you have to do to make a binary that works with older versions of the shared libc is avoid using functionality that was introduced in later versions. Or you can just static link and have it work everywhere.

Unlike some projects, we fully disclose bugs that might be relevant to security. In this instance, the bug could only be triggered by explicitly requesting sufficiently many decimal places (16445 for ld80) and printing a denormal long double with the lowest bit set, as in:

printf("%.16445Lf", 0x1p-16445);

In addition, even when triggered, it only wrote past the end of the buffer by one slot, and we were unable to get it to overwrite anything important like a return address (of course, what it overwrites depends on the compiler, so in principle it could).

putw is a nonstandard functions and used by basically nothing, so a simple, obviously does-what-the-man-page-says solution in terms of another well-tested function is preferable to repeating the locking, buffer manipulation, etc. logic in a place that's unlikely to ever get tested.

At the time the comparison was made, glibc was essentially unmaintained and Debian-based distributions were using the eglibc fork. Now that glibc is under new leadership, eglibc is being discontinued and the important changes have been merged back to glibc upstream. So when I update the chart's quantitative comparisons, it will be for glibc rather than eglibc. The main things that will change when I do are significant increases in size (especially since I seem to have under-measured eglibc's totals) and possibly some improvements in performance. In terms of all the other qualitative comparisons, glibc remains about the same place it was before.

We have people working on aarch64, someone interested in doing a sparc port, and interest from the OpenRISC folks in musl too (and I've offered to help them with a port). There's also someone who wants to port to LM32-mmu (which, as I understand it, doesn't have any userspace infrastructure yet and only a very experimental kernel port).

Yes. These days glibc seems to have "un-deprecated" static linking (they're accepting bug reports for problems that only affect static linking), but it's still something of a second-class citizen. I believe there's still a good deal of pthread breakage, and no attention to making the size of static binaries acceptable.

In musl, I've made efficient and bug-free static linking a priority from the beginning. The empty program isn't quite as small as some of our extreme anti-bloat userbase would like (it's around 1.8k now), but it's still very low compared to anything except dietlibc (which has a number of issues). More interestingly, we can do a static-linked multi-threaded "hello world" in under 4k.

Some figures can be seen in the libc comparison I did back when musl was first released.

There is: see my post just above.

No, and the ACA eliminates the primary motive for snooping on your medical records: denying you coverage.

Increase my coffee intake from 1-3 cups per day to 10+ cups per day: http://www.ncbi.nlm.nih.gov/pu...

I wonder if these default passwords printed on labels are generated securely, or if they're a hash of the MAC address or something like that. The latter would be a lot cheaper to implement since there would be no need to install the securely generated passwords on the routers at the factory (they could just generate the password from their MAC on the first boot) and no need to tie this in with the label-printing system.

The XSS, etc. only work if the machine you use for browsing is logged in to the router, which is generally a bad idea (for this exact reason). Accessing the router control panel via incognito/private/porn browsing mode when you need it is a good workaround, but of course replacing the firmware with OpenWRT is even better.

Nailing MS for bundling IE was like nailing an organized crime lord for tax evasion. Nobody with a clue actually cared about the browser bundling. They cared that Microsoft had been engaging in behavior which essentially amounts to bullying and corruption for the entire time they've existed. The Microsoft that exists now is not reformed; it's just a lot less powerful. It's still part of a very backwards tradition of corporate behavior where you get ahead not by making the best product but by setting up obstacles and shutting down everybody else who's trying to make something better. (See also: entertainment industry, fossil fuels industry, car industry, ...) Corporations which behave that way should be treated like the dinosaurs they are, and shown the door to extinction.