No, I get binaries from wherever I want and it works.

I can't live happily without shared libraries. They were invented for good reasons tens of years ago and have been used extensively ever since. Think about the "bloat" of statically linked executables and the fact that they don't get updates of the linked-in library code (including security fixes).

The libc is not a library like all the others. Proposing a binary- and source- incompatible replacement for glibc, as is being done here, means to partition the Linux userspace, both binaries and source code, into two isolated subsystems. Something that we are already suffering with Android. This is not a benefit, this is a damage for the Linux community as a whole, and it will hurt me even if I don't want to switch. Casual PC users already run into enough problems when switching to Linux; asking them to check which libc is required before installing a program is the kind of nuisance that makes them run away. I don't contest musl developers' freedom to code whatever they want, and I welcome their efforts. I do contest the stance to replace glibc with an incompatible library, whomever it comes from.

Forking the Linux userland yet again should have some serious motivations behind it. I can't find them neither in the benchmarks nor in the feature comparisons provided here.

Linux is a modern system, yet that's a problem in Linux. I just had to recompile dozens of libraries because one of them had littered the namespace with its own unprefixed symbols, one of which clashed with another's library's -init function, which didn't get called - so I got a segfault on exit of any application that was using that library. Fortunately the library in question was open source and its binary wasn't stripped, so the problem was easy to spot.

You can use versioned symbols on Linux, but that's not a design requirement, and not a majority of the developers do that.

Not in Java, because all symbols are namespaced by design. It would be a problem if you had two versions of the same library and wanted to use both of them at once.

Meh, I wrote my own replacement for freeglut3 in a weekend. It's not hard to have a platform abstraction layer, and many already exist (I just needed my own lightweight one for my games). Since I started out with cross platform toolchain, I have no issue writing code that runs on multiple platforms.

Writing your code is only part of the problem. Things become funny when you have to use code that has already been written by other people. For example, you're using a shared library which exports a symbol which clashes with another library used by another library that is dynamically loaded by another library that you use. Without you knowing.

I get a native application without Java's huge runtime dependencies

What are Java's huge runtime dependencies? For instance the Linux version only requires the X11 libraries if you want to display graphics. It will run on a Pentium 1 machine with 16 MB of RAM.

Providing binaries for every current modern chipset including ARM and MIPS takes me about 30 minutes total to build with my cross compilers.

This is assuming that you write code that doesn't interface with any existing software on the target, which is a rare occurence. Do you talk directly to the hardware? Your cross compiler won't spare you from having to write hardware-dependent code for each of the flavours of your target.

However, saying that cross platform C/C++ is more of a headache than Java is ridiculous. They're all "write once, debug everywhere" options.

With C and C++, you get in the best case to fix up your application to port it into a new operating environment, which is what Java requires you to do in the worst case. And we're not even considering the case of mutually incompatible runtime dependencies.

I think that in that case the JRE will try to install the toolbar the next time it auto-updates.

This measure is not experimental, it has been used in Europe since the 80s. People won't buy another car to bypass the restriction because owning a car is very expensive (insurance, taxes, ...) and if you can afford that then probably you could as well pay the fines for ignoring the law. Less environment-friendly vehicles often can't enter the city centres at all, because there it's common to put restriction on car access depending on their "euro rating".

Everybody runs into problems with ACPI. I've never seen it work properly, on any OS, on any machine that I've owned.

Sir, by accepting to partition the Web into a subset for the customers of Google, Adobe, Apple and Microsoft and another subset for everyone else, you have lost any credibility to my eyes when you're talking about my rights online.

Government surveillance? The technology you have supported can be the best means to bring more surveillance to the web - for instance, by allowing you to view certain subsets of the web only if you're using a proprietary browser with spyware built-in.

The emacs vs vim flamewar is about which one is the best (that is vim, of course), not about the legitimacy to exist of either. I've never heard anybody suggest that people should stop developing vim and contribute to emacs instead.

That's true, but how much can that bloat amount to? 20 MB? 100 MB? It won't be much relevant for today's standards. Code duplication is what happens regularly in the closed source world, where applications ship with a private version of all the libraries they use, and not only for the UI - with few people complaining.

https://mail.gnome.org/archive... - don't know if things have changed in the last two years.

GTK+ 3 is LGPLv2, not GPLv3; it is not developed by the FSF, and never has been. And the GPLv3 is arguably more friendly for businesses than the GPLv2, with its explicit patent provisions, the lack of the termination provision, and the explicit system libraries exception.