In comparison, my systems use about 10W when powered up and running, and the Minnowboard uses about 3W running. So using 10-15W in sleep/standby it utterly ridiculous. A reasonable amount would be something like 100mW.
First of all, touchscreen is a horrible interface in a car. But leaving that aside, capacitive touch screens are dirt cheap. You can get replacement units (glass and touch sensors) for Chinese Android phones for a few bucks on Alibaba. So there's utterly no reason to prefer an inferior technology for the sake of price.
If you bothered to read the story, the problem is that the result is not correct to 1 ULP. Even for small inputs it has significant errors and the worst case has only 4 bits correct (so, roughly 2^49 ULP error). As for deprecation, you're right and wrong. It's not officially deprecated, but it's slower than computing sin correctly in software, and between the performance issue and the fact that experts in the field have known about this bug for a long time, nobody with a clue uses the FSIN instruction.
Ext 2/3/4 and any filesystem that records file ownership (especially numeric uids/gids) is not suitable for storage that's not associated with a particular system's user account database (/etc/passwd or otherwise). Linux could attempt to support such usage by virtualizing/remapping uids for "external" ext2/3/4-formatted drives, but it doesn't. Instead, you have a situation where file ownership is just silently wrong when you plug the drive into a different computer. So removing support is a big hammer, but I see how they could see it as a justifiable one when the status quo is broken like this.
No bloat and easy to customize for different needs. Focused on server use and virtualization but also makes a nice light desktop. Active development community.
Whatever the purpose, presentation matters. If the text on websites is blurry and unreadable, the device looks like crap, regardless of what other positives aspects it might have.
Perhaps you missed the part of my comment where I noted that devices with high-end displays are possible in the $150-250 range and cited specific examples...
Why is anyone still making devices with sub-300-dpi screens? Especially when you're trying to launch a new OS -- this is the best way to make your OS look like crap, even if it's otherwise great. Price is definitely not a show-stopper here; the ASUS ZenFone has a high-end screen in the ~$200 range, and cheap Chinese phones like Zopo have had them for a long time at much lower prices. If they're really worried about cost, scrap the 5 MP camera which is a complete joke when your screen is 0.4 MP...
Toy microscopes don't work at all. Their focus knobs are loose so that you constantly lose focus while trying to see the sample, and they only have one focus knob which makes it essentially impossible to focus to begin with (real microscopes have coarse and fine knobs). And the magnification rating is always fake. If they advertise 400x, expect resolving power so poor that they're essentially 20x or less. I once got one of these pieces of junk and ended up going back to eBay for a $80 vintage Bausch and Lomb scope which I'm very happy with, but sadly I think that was a rare find and I just got lucky.
"Climate change" is not a "downgrade" to global warming. It's simply better wording to avoid denial from idiots who don't understand math (i.e. means) and say "wow it's really cold this winter, global warming is bs!" Nothing has changed; we still know the mean temperature is increasing and that the increase is caused by human activity. But the new wording is less susceptible to idiotic misinterpretation.
If your FOSS application interacts with a web-based service that requires an API key, the correct way to implement it is to instead have it interact with your own servers, and in turn have your servers interact with the web service via the API key. You should of course then publish the source to the server-side part of your application as well, and advanced users can then (if they really want to) setup their own server, with their own API key for the web service; this also protects users from the possibility that you disappear and shtudown your server or let it rot.
Of course this design assumes it's a web service your users are accessing anonymously. If they have to login to their own accounts, then this model is usually wrong. They should never be providing their account credentials to you, and it can only work correctly with more advanced authentication methods that avoid the need for them to provide credentials to you, which the web service is unlikely to support.
I really want to add a Bionic comparison, but in order to be comparing apples with apples (or non-apples with non-apples, pardon the pun) we need an x86 build of Bionic, or need to re-do all the other libcs' figures for arm. I've been looking for a way to build Bionic outside of the Android build system and use it on non-Android systems, and the gentoobionic repository at https://github.com/gentoobioni... looked promising, but I couldn't get it to work. It also may be much larger than the official Bionic.
If anyone is willing to help us figure out how to setup x86 Bionic for testing, please stop by the IRC channel (#musl on Freenode) or send a message to the mailing list.
If you're talking about modern BSD licenses, basically there's no difference but the wording. Some older BSD licenses were mildly more restrictive, most notably the ones with the advertising clause that technically conflicts with the GPL.
Someone with mod points, please mod up the parent post. Even if you disagree with it, it's informative about one of the big issues in glibc that musl does differently: musl's snprintf and dprintf, for example, are async-signal-safe. Roland McGrath, who holds claim to being the "inventor" of dprintf and author of the original implementation in glibc, has stated that he intended for the function to be async-signal-safe or at least close to it, and that later introduction of dynamic allocation is a bug (which I later filed as #16060) that glibc should fix.
There is no isinf symbol or reference to one in musl, so I think this is something to do with your toolchain (a BSD-packaged version of LLVM that tries to make itself look like gcc?). Pretty much all of your concerns (including "lack of C++") could be solved by building a toolchain to target musl (note: uClibc and glibc make you do this anyway; musl is fairly unique in providing a way, albeit sometimes clunky, to use the new libc without a new compiler toolchain). If you want to do that or proceed trying to get the wrapper to work on your system, you'll find people who can help in Freenode #musl or on the mailing list. On the other hand I understand if you don't want to go to the trouble, but keep in mind you're using a non-native setup that's probably never been tested.
The problem appears to be that "x86_64" is identified by your compiler as "amd64" in the machine tuple. This is easily fixed by adding --target=x86_64 (the name musl knows it by) on the configure command line. I don't see any reason we can't add "amd64" to the detection logic in configure too, so this should work better for you in a future release.
There is a way to upgrade glibc atomically, but it's a big hack, and even still it doesn't achieve the goal. The way it would work is to have/lib be a symlink to a versioned directory, and atomically replace (via rename()) the symlink with a symlink to the new directory. However, even if the replacement is made atomically, you still have the situation that the dynamic linker can load libc.so before the replacement is made and libpthread.so after it's made, resulting in mismatching versions.
I've submitted at least two bugfix patches to glibc where the diff was 100% "-" lines for things Drepper added. I believe they were all eventually committed. And thankfully this is the one type of glibc patch submission that doesn't require having a copyright assignment on file with the FSF.;-)
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).
Slashdot Mirror
In comparison, my systems use about 10W when powered up and running, and the Minnowboard uses about 3W running. So using 10-15W in sleep/standby it utterly ridiculous. A reasonable amount would be something like 100mW.
First of all, touchscreen is a horrible interface in a car. But leaving that aside, capacitive touch screens are dirt cheap. You can get replacement units (glass and touch sensors) for Chinese Android phones for a few bucks on Alibaba. So there's utterly no reason to prefer an inferior technology for the sake of price.
Post it on a torrent site. That's about the best possible PR they could do.
If you bothered to read the story, the problem is that the result is not correct to 1 ULP. Even for small inputs it has significant errors and the worst case has only 4 bits correct (so, roughly 2^49 ULP error). As for deprecation, you're right and wrong. It's not officially deprecated, but it's slower than computing sin correctly in software, and between the performance issue and the fact that experts in the field have known about this bug for a long time, nobody with a clue uses the FSIN instruction.
Ext 2/3/4 and any filesystem that records file ownership (especially numeric uids/gids) is not suitable for storage that's not associated with a particular system's user account database (/etc/passwd or otherwise). Linux could attempt to support such usage by virtualizing/remapping uids for "external" ext2/3/4-formatted drives, but it doesn't. Instead, you have a situation where file ownership is just silently wrong when you plug the drive into a different computer. So removing support is a big hammer, but I see how they could see it as a justifiable one when the status quo is broken like this.
No bloat and easy to customize for different needs. Focused on server use and virtualization but also makes a nice light desktop. Active development community.
Whatever the purpose, presentation matters. If the text on websites is blurry and unreadable, the device looks like crap, regardless of what other positives aspects it might have.
Perhaps you missed the part of my comment where I noted that devices with high-end displays are possible in the $150-250 range and cited specific examples...
Why is anyone still making devices with sub-300-dpi screens? Especially when you're trying to launch a new OS -- this is the best way to make your OS look like crap, even if it's otherwise great. Price is definitely not a show-stopper here; the ASUS ZenFone has a high-end screen in the ~$200 range, and cheap Chinese phones like Zopo have had them for a long time at much lower prices. If they're really worried about cost, scrap the 5 MP camera which is a complete joke when your screen is 0.4 MP...
Toy microscopes don't work at all. Their focus knobs are loose so that you constantly lose focus while trying to see the sample, and they only have one focus knob which makes it essentially impossible to focus to begin with (real microscopes have coarse and fine knobs). And the magnification rating is always fake. If they advertise 400x, expect resolving power so poor that they're essentially 20x or less. I once got one of these pieces of junk and ended up going back to eBay for a $80 vintage Bausch and Lomb scope which I'm very happy with, but sadly I think that was a rare find and I just got lucky.
"Climate change" is not a "downgrade" to global warming. It's simply better wording to avoid denial from idiots who don't understand math (i.e. means) and say "wow it's really cold this winter, global warming is bs!" Nothing has changed; we still know the mean temperature is increasing and that the increase is caused by human activity. But the new wording is less susceptible to idiotic misinterpretation.
Perhaps you should read this: https://twitter.com/solardiz/s...
If your FOSS application interacts with a web-based service that requires an API key, the correct way to implement it is to instead have it interact with your own servers, and in turn have your servers interact with the web service via the API key. You should of course then publish the source to the server-side part of your application as well, and advanced users can then (if they really want to) setup their own server, with their own API key for the web service; this also protects users from the possibility that you disappear and shtudown your server or let it rot.
Of course this design assumes it's a web service your users are accessing anonymously. If they have to login to their own accounts, then this model is usually wrong. They should never be providing their account credentials to you, and it can only work correctly with more advanced authentication methods that avoid the need for them to provide credentials to you, which the web service is unlikely to support.
I really want to add a Bionic comparison, but in order to be comparing apples with apples (or non-apples with non-apples, pardon the pun) we need an x86 build of Bionic, or need to re-do all the other libcs' figures for arm. I've been looking for a way to build Bionic outside of the Android build system and use it on non-Android systems, and the gentoobionic repository at https://github.com/gentoobioni... looked promising, but I couldn't get it to work. It also may be much larger than the official Bionic.
If anyone is willing to help us figure out how to setup x86 Bionic for testing, please stop by the IRC channel (#musl on Freenode) or send a message to the mailing list.
If you're talking about modern BSD licenses, basically there's no difference but the wording. Some older BSD licenses were mildly more restrictive, most notably the ones with the advertising clause that technically conflicts with the GPL.
Someone with mod points, please mod up the parent post. Even if you disagree with it, it's informative about one of the big issues in glibc that musl does differently: musl's snprintf and dprintf, for example, are async-signal-safe. Roland McGrath, who holds claim to being the "inventor" of dprintf and author of the original implementation in glibc, has stated that he intended for the function to be async-signal-safe or at least close to it, and that later introduction of dynamic allocation is a bug (which I later filed as #16060) that glibc should fix.
There is no isinf symbol or reference to one in musl, so I think this is something to do with your toolchain (a BSD-packaged version of LLVM that tries to make itself look like gcc?). Pretty much all of your concerns (including "lack of C++") could be solved by building a toolchain to target musl (note: uClibc and glibc make you do this anyway; musl is fairly unique in providing a way, albeit sometimes clunky, to use the new libc without a new compiler toolchain). If you want to do that or proceed trying to get the wrapper to work on your system, you'll find people who can help in Freenode #musl or on the mailing list. On the other hand I understand if you don't want to go to the trouble, but keep in mind you're using a non-native setup that's probably never been tested.
The problem appears to be that "x86_64" is identified by your compiler as "amd64" in the machine tuple. This is easily fixed by adding --target=x86_64 (the name musl knows it by) on the configure command line. I don't see any reason we can't add "amd64" to the detection logic in configure too, so this should work better for you in a future release.
BTW, in case anyone thinks I'm making up the thing about intentionally linking to ancient glibc, see this: http://www.crankuptheamps.com/...
There is a way to upgrade glibc atomically, but it's a big hack, and even still it doesn't achieve the goal. The way it would work is to have /lib be a symlink to a versioned directory, and atomically replace (via rename()) the symlink with a symlink to the new directory. However, even if the replacement is made atomically, you still have the situation that the dynamic linker can load libc.so before the replacement is made and libpthread.so after it's made, resulting in mismatching versions.
I've submitted at least two bugfix patches to glibc where the diff was 100% "-" lines for things Drepper added. I believe they were all eventually committed. And thankfully this is the one type of glibc patch submission that doesn't require having a copyright assignment on file with the FSF. ;-)
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).