Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

GNU C Library Alternative Musl Libc Hits 1.0 Milestone

Unknown Lamer posted about 6 months ago | from the pry-glibc-from-my-cold-dead-ld.so dept.

Open Source 134

New submitter dalias (1978986) writes "The musl libc project has released version 1.0, the result of three years of development and testing. Musl is a lightweight, fast, simple, MIT-licensed, correctness-oriented alternative to the GNU C library (glibc), uClibc, or Android's Bionic. At this point musl provides all mandatory C99 and POSIX interfaces (plus a lot of widely-used extensions), and well over 5000 packages are known to build successfully against musl.

Several options are available for trying musl. Compiler toolchains are available from the musl-cross project, and several new musl-based Linux distributions are already available (Sabotage and Snowflake, among others). Some well-established distributions including OpenWRT and Gentoo are in the process of adding musl-based variants, and others (Aboriginal, Alpine, Bedrock, Dragora) are adopting musl as their default libc."
The What's New file contains release notes (you have to scroll to the bottom). There's also a handy chart comparing muscl to other libc implementations: it looks like musl is a better bet than dietlibc and uclibc for embedded use.

cancel ×

134 comments

Sorry! There are no comments related to the filter you selected.

To infinity and beyond! (-1)

Anonymous Coward | about 6 months ago | (#46533745)

Hey guys I just finish making an Arduino-driven, vibrating buttplug. Is this awesome?!!

Re:To infinity and beyond! (-1, Offtopic)

Anonymous Coward | about 6 months ago | (#46533903)

only if you used a 3d printer.

Re:To infinity and beyond! (-1, Flamebait)

Anonymous Coward | about 6 months ago | (#46534265)

I did. It was based off a mold of St. Jobs' rotting cock.

Re:To infinity and beyond! (-1)

Anonymous Coward | about 6 months ago | (#46534435)

You mean you didn't use a 3D scanner? How disappointing!

Re:To infinity and beyond! (0)

DrPBacon (3044515) | about 6 months ago | (#46534813)

Flagellum and all?

Re:To infinity and beyond! (-1)

Anonymous Coward | about 6 months ago | (#46535765)

A mold of not a mold on his cock.

Re:To infinity and beyond! (0)

Anonymous Coward | about 6 months ago | (#46534631)

But did you use Bitcoins and Apple when building it? Then it would be 2^256 times more newsworthy.

Re:To infinity and beyond! (-1)

Anonymous Coward | about 6 months ago | (#46535427)

Yes. I also sat in a chair that had a dildo machine installed to ram my ass while working like a true Macfag.

Either gnu libc is hideously slow and bloated... (1)

Viol8 (599362) | about 6 months ago | (#46533831)

... which I don't believe because the guys at gnu know a thing or 2 about compilers and libraries - or this library has cut some corners and/or missed out some functionality.

Re:Either gnu libc is hideously slow and bloated.. (3, Insightful)

staalmannen (1705340) | about 6 months ago | (#46533917)

It might be easier to add than to remove, leading to bloat over time and glibc has been around for a while. Also, building on old code might mean that you are limited in what you can change. For example, the modular design of LLVM has been a pretty big success and is considered easier to work with/develop than gcc. For musl, I think they have decided to remove all legacy stuff + non-standard extensions.

Re:Either gnu libc is hideously slow and bloated.. (0)

Anonymous Coward | about 6 months ago | (#46533923)

libc is just old and not developed very much...

Re:Either gnu libc is hideously slow and bloated.. (0)

Anonymous Coward | about 6 months ago | (#46533927)

I'm guessing that it only targets x86, amd64, ARM, and MIPS. That sounds comprehensive until one considers sparc, HPPA, PPC, POWER, and various "embedded but not ARM or MIPS" architectures like Blackfin or CRIS.

Re:Either gnu libc is hideously slow and bloated.. (5, Insightful)

Improv (2467) | about 6 months ago | (#46534205)

Steps to a useless comment:
1) Speculate on the features of something
2) Note that that speculated feature set doesn't include something you want
3) Criticise based on your speculation

Re:Either gnu libc is hideously slow and bloated.. (0)

Anonymous Coward | about 6 months ago | (#46536483)

Let me fix that for you:

Steps to a typical Slashdot comment:
1) Speculate on the features of something
2) Note that that speculated feature set doesn't include something you want
3) Criticise based on your speculation

Re:Either gnu libc is hideously slow and bloated.. (1)

cream wobbly (1102689) | about 6 months ago | (#46537275)

I think we can safely skip steps 1 and 2, even if 3 references 1.

Musl's supported architectures (3, Informative)

uhmmmm (512629) | about 6 months ago | (#46534231)

You're right that musl doesn't support the same breadth of architectures that glibc does. They currently support x86, amd64, ARM, MIPS, PPC, microblaze, and they have experimental support for superh and x32.

One big advantage they do have is that it's much simpler to add support for a new architecture to musl than it is to add it to glibc. They are interested in supporting more architectures, so I'd expect their list of supported architectures to grow fairly quickly if there are people interested in that support.

Re:Musl's supported architectures (3, Insightful)

dalias (1978986) | about 6 months ago | (#46534595)

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).

Re:Either gnu libc is hideously slow and bloated.. (3, Insightful)

Anonymous Coward | about 6 months ago | (#46534185)

the guys at gnu know a thing or 2 about compilers and libraries

You obviously never worked on or looked at their source code.

glibc is horribly bloated (4, Informative)

uhmmmm (512629) | about 6 months ago | (#46534189)

The first priority on musl is correctness, and they will take a hit to size and speed if that's what's necessary to achieve it. But thus far, they've been doing a good job of achieving correctness without introducing too much bloat.

Take a look at their page on bugs found while developing musl [musl-libc.org] , and you'll find that they've found and reported quite a few bugs in glibc where glibc had been "cutting corners".

Re:glibc is horribly bloated (3)

Just Some Guy (3352) | about 6 months ago | (#46535259)

LOL Drepper. He had a free pass to be an abrasive jerk for years because of his supposed dedication to perfection and uncompromising quality. In retrospect, maybe he was just a jerk to shut down people who wanted to examine his work more closely than he liked.

Re:glibc is horribly bloated (4, Interesting)

dalias (1978986) | about 6 months ago | (#46535425)

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. ;-)

Re:glibc is horribly bloated (5, Funny)

Just Some Guy (3352) | about 6 months ago | (#46535513)

You're doing God's work, son.

Re:glibc is horribly bloated (0)

Anonymous Coward | about 6 months ago | (#46535565)

That was my thought when I saw this headline: did people get sick of Drepper?

Re:glibc is horribly bloated (1)

Samantha Wright (1324923) | about 6 months ago | (#46535685)

You know it's a problem when... [sourceware.org]

Re:glibc is horribly bloated (1)

Raenex (947668) | about 6 months ago | (#46538043)

Wait, it says "RESOLVED FIXED", does that mean Red Hat fired him and revoked his commit access?

Re:glibc is horribly bloated (1)

Tough Love (215404) | about 6 months ago | (#46538567)

He became a vp at Goldman Sachs. Where I suppose he fits in well.

Re:Either gnu libc is hideously slow and bloated.. (1)

Dr.Dubious DDQ (11968) | about 6 months ago | (#46534379)

The chart [etalabs.net] shows a few things, though I notice they don't include comparison to the full glibc itself.

Re:Either gnu libc is hideously slow and bloated.. (4, Informative)

dalias (1978986) | about 6 months ago | (#46534641)

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.

Re:Either gnu libc is hideously slow and bloated.. (0)

Anonymous Coward | about 6 months ago | (#46535541)

Thanks for the update. I used to hear about the drama around drepper, but I didn't understand what happened after he left.

Re:Either gnu libc is hideously slow and bloated.. (1)

jandrese (485) | about 6 months ago | (#46534879)

Debugging features: no no no yes

WTF does this mean? I'm sure as hell not developing against a libc that doesn't have debugging hooks. This can't be what it means.

Re:Either gnu libc is hideously slow and bloated.. (3, Informative)

dalias (1978986) | about 6 months ago | (#46535321)

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.

Re:Either gnu libc is hideously slow and bloated.. (0)

Anonymous Coward | about 6 months ago | (#46534663)

... which I don't believe because the guys at gnu know a thing or 2 about compilers and libraries - or this library has cut some corners and/or missed out some functionality.

NSA has not had a chance to sneak their stuff in yet?

Re:Either gnu libc is hideously slow and bloated.. (0)

Anonymous Coward | about 6 months ago | (#46535247)

Yeah, the guys at gnu must know a lot, it's thanks to them that we have autoconf hell and myriads of projects trying to save us from it. Or why others started LLVM, or why others start a libc.

Don't measure the knowledge of the gnu guys based on your own lack of it.

Re:Either gnu libc is hideously slow and bloated.. (1)

FatdogHaiku (978357) | about 6 months ago | (#46535377)

Don't measure the knowledge of the gnu guys based on your own lack of it.

Why not? It's exactly how we operate our political... oh, wait...

Re:Either gnu libc is hideously slow and bloated.. (0)

Anonymous Coward | about 6 months ago | (#46536045)

argument by status quo? surely you're not serious that
since gnu has been at it a while it follows that they are good?

what's this a remix of the old hungarian mathematics joke?

Re:Either gnu libc is hideously slow and bloated.. (1)

Darinbob (1142669) | about 6 months ago | (#46537795)

Just look at typical GNU code though. It's well written but it's not small, and often not efficient. Much of this is due to accretion over time, however there also is a certain style that the programs follow. Thus the parodied GNU HelloWorld program. Glibc makes an implicit assumption that it is being used on a fast computer with lots of memory (ie, a PC or minicomputer). This is perfectly normal, however it leads to a different sort of optimization than you would find for embedded systems or small computers for example, thus the popularity of alternative standard C libraries or lots of roll-your-own.

Yes some functionality may be missing, but is that necessarily required or standard functionality?

Re:Either gnu libc is hideously slow and bloated.. (0)

Anonymous Coward | about 6 months ago | (#46539005)

Some parts of glibc are definitely broken. For example, snprintf(3) does a ton of dynamic memory allocation, which means printing a formatted string to a static buffer could still fail with ENOMEM! That's because snprintf is a wrapper around fprintf() using a dynamic file object, among other niceties! Sane implementations like on OpenBSD are async-signal-safe for all the basic formatting specifiers.

The problem with glibc is they do too much dynamic memory allocation in general. Several functions you would think should never fail on a sane implementation could fail. Then you have just plain stupid stuff, like NL_TEXT being INT_MAX, because apparently the GNU folks expect that some time in the future strerror_r() may return system error messages gigabytes in length. It's really because they took too literally the GNU Coding Style requirement of using dynamic memory as much as possible to avoid arbitrary limitations. But sometimes arbitrary limitations are really nice, making simpler code which is more secure. Imagine dealing with DNS names of arbitrary length!

It's ridiculous. When you're boxed into a corner because of various _other_ failures (I/O, authentication failure, w'ever), the last thing you want to worry about in your failure path is having to deal with crap like OOM conditions.

Re:Either gnu libc is hideously slow and bloated.. (1)

dalias (1978986) | about 7 months ago | (#46539631)

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.

pkgsrc test results (4, Informative)

staalmannen (1705340) | about 6 months ago | (#46533835)

For those curious about which "5000 packages" that build with musl, there is the awesome automated pkgsrc tests published: http://wiki.musl-libc.org/wiki... [musl-libc.org]

Re:pkgsrc test results (1)

jandrese (485) | about 6 months ago | (#46536017)

% ./configure checking for C compiler... gcc checking whether compiler is gcc... yes checking whether to build musl-gcc wrapper... yes checking target system type... amd64-undermydesk-freebsd ./configure: unknown or unsupported target "amd64-undermydesk-freebsd"

:(

I thought this might be helpful in those cases where something doesn't like llvm libc, but no such luck. It also appears to lack c++ support, which is a pretty big caveat in this day and age.

Re:pkgsrc test results (1)

dalias (1978986) | about 6 months ago | (#46536881)

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.

Re:pkgsrc test results (1)

jandrese (485) | about 6 months ago | (#46538173)

Hmm, well that got it built, but it still doesn't work.

% /usr/local/musl/bin/musl-gcc hello.c
/usr/local/musl/lib/libc.so: undefined reference to `isinf'

I didn't see any obvious errors while it was building, but there were like a million lines of buildscroll to go through, and it would have been so easy to miss one. There's probably just enough issues with this to make it not worth it sadly.

Re:pkgsrc test results (1)

dalias (1978986) | about 6 months ago | (#46539393)

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.

Hi! (-1)

Anonymous Coward | about 6 months ago | (#46533859)

Hi mom! I'm doing well, how about you?

Re:Hi! (-1)

Anonymous Coward | about 6 months ago | (#46533899)

fin son - now come and get back into bed

Real benefit? (2)

Jizzbug (101250) | about 6 months ago | (#46533971)

What is the real benefit besides license? Is it correctness?

RE: Real benefit? (0)

Anonymous Coward | about 6 months ago | (#46535073)

For me the license is an anti-benefit. Without it, you get closed operating systems built on open source that aren't copy left, such as the various operating systems built on FreeBSD.

Re: RE: Real benefit? (0)

Anonymous Coward | about 6 months ago | (#46538057)

Good. Makes it freetard free.

define _GNU_SOURCE (2, Interesting)

cyberthanasis12 (926691) | about 6 months ago | (#46534077)

I downloaded the library to see some random code. Here is the very first file I (randomly) chose (putw.c):

#define _GNU_SOURCE
#include
int putw(int x, FILE *f)
{
return (int)fwrite(&x, sizeof x, 1, f)-1;
}

Cheers.

Re:define _GNU_SOURCE (1)

kthreadd (1558445) | about 6 months ago | (#46534173)

Sounds reasonable since this library is mostly focused on GNU/Linux and not just POSIX compliance.

Re:define _GNU_SOURCE (1)

dalias (1978986) | about 6 months ago | (#46534671)

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.

Re:define _GNU_SOURCE (2)

QuietLagoon (813062) | about 6 months ago | (#46534891)

and the problem with that code is...?

Re:define _GNU_SOURCE (1)

fph il quozientatore (971015) | about 6 months ago | (#46536027)

Clearly, it should've been _GNU_LINUX_SOURCE.

Re:define _GNU_SOURCE (2)

uhmmmm (512629) | about 6 months ago | (#46536959)

putw is a non-standard function that musl's headers only expose to programs when they define _GNU_SOURCE.or _BSD_SOURCE. The file that actually implements it, therefore, needs to define one of these in order for the header to expose the declaration, which allows the compiler to verify that the type signatures of the declaration and the definition match.

Why is libm.a empty? (2, Funny)

Sponge Bath (413667) | about 6 months ago | (#46534125)

From the FAQ:

On musl, the entire standard library is included in a single library file — libc.a for static linking, and libc.so for dynamic linking. This significantly improves the efficiency of dynamic linking, and avoids all sorts of symbol interposition bugs that arise when you split the libraries up — bugs which have plagued glibc for more than a decade.

Bringing it all together? That's why they call it the love musl.

DIE GPL DIE! (-1)

Anonymous Coward | about 6 months ago | (#46534245)

The GPL is communist.

buffer overflow in printf ... great for security!! (1)

Jizzbug (101250) | about 6 months ago | (#46534249)

bugs fixed:
- buffer overflow in printf when printing smallest denormal exactly

Re:buffer overflow in printf ... great for securit (4, Insightful)

dalias (1978986) | about 6 months ago | (#46534735)

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).

Brain damaged project (-1)

Improv (2467) | about 6 months ago | (#46534251)

I like how they place an emphasis on it being small, but they require you to link the whole damned thing into your app. And of c ourse that doesn't help you write correct software, because you won't figure out if you really need -lm unless you also test your app on a more correct libc.

Lightweight and correct indeed.

Re:Brain damaged project (3, Insightful)

pe1rxq (141710) | about 6 months ago | (#46534395)

Have you ever looked at static linking in detail?
A .a file is basicly a collection of .o files. The linker only links those that are needed.
So they have a single .a file instead of two or more .a files. This allows them to prevent difficult interdepencies between those .a files.
The end result might still be a very small subset of the complete library.

Re:Brain damaged project (1)

dam.capsule.org (183256) | about 6 months ago | (#46535523)

As far as I know, the whole .a file gets linked in each time unless you use -fdata-sections when compiling and -Wl,--gc-sections when linking.

Re:Brain damaged project (0)

Anonymous Coward | about 6 months ago | (#46536157)

If that were true, there would be no difference in size in static linking regardless of how many functions you used from the .a file. It's the entire original .o file that gets linked in, normally. This is why musl is split up into many .c files which are compiled into many .o files.

Re:Brain damaged project (2)

porges (58715) | about 6 months ago | (#46536235)

No. You're thinking of the fact that once the linker marks a .o as required, it brings in all of that .o file unless you provide those flags you mention. But the point is definitely that only the .o files that are needed get linked into the final object model. Just do a gcc of a simple "hello world" program and then look at the a.out's size; it won't be anywhere near as big as libc.a. Also, nm a.out will show you the relatively few symbols in the a.out file.

Re:Brain damaged project (1)

Qzukk (229616) | about 6 months ago | (#46536527)

The .a file is an archive of the individual .o files, only the individual .o files that are actually referenced get linked into the final executable. See also:

ar t libc.a

As far as I know (0)

Anonymous Coward | about 6 months ago | (#46538769)

You don't know much.

Re:Brain damaged project (0)

Anonymous Coward | about 7 months ago | (#46539645)

good lord. it has *never* been this way. even in the 70s.

re: Brain damaged project (3, Informative)

uhmmmm (512629) | about 6 months ago | (#46534455)

Where does it say you have to link the whole thing into your application? Musl supports dynamic linking just fine. The musl developers do have a preference for static linking, so they have better support for it than glibc (see their size comparisons [etalabs.net] of static linked programs on musl and glibc, for instance). But that doesn't mean you have to use it.

The bit about aiming for correctness is correctness of musl itself. Of course they can't, in general, guarantee that you will write your own code correctly. In theory, they could split the math library out and force you to link against it correctly. But what would be the point? To arbitrarily break broken programs, while having no impact on correct programs? It would also have several downsides.

Musl is the only C library I'm aware of which allows the entire C library ecosystem (C library, math library, threading library, dynamic linker, and some others probably) to be upgraded atomically, which eliminates a small window during upgrade where you might start a new program and have it break because it gets conflicting versions of these components.

There is also code within the main C library (for example, the code to format floating point numbers in printf) which benefits from being able to call functions that are part of the math library.

Re: Brain damaged project (1)

serviscope_minor (664417) | about 6 months ago | (#46535279)

Musl is the only C library I'm aware of which allows the entire C library ecosystem (C library, math library, threading library, dynamic linker, and some others probably) to be upgraded atomically,

GLIBC allows this. You can definitely bring in new versions of all of those.

Re: Brain damaged project (1)

dalias (1978986) | about 6 months ago | (#46535531)

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.

Re:Brain damaged project (0)

Anonymous Coward | about 6 months ago | (#46536941)

You are brain damaged and are commenting without knowing anything about linkers.

Is it all about the license? (1)

jimwelch (309748) | about 6 months ago | (#46534341)

The first thing I saw was MIT vs GPL. What is the difference between the two?

Re:Is it all about the license? (1)

Githaron (2462596) | about 6 months ago | (#46534519)

GPL requires you make your chances available under the GPL license while MIT makes almost no requirements.

Re:Is it all about the license? (1)

jimwelch (309748) | about 6 months ago | (#46534911)

My sarcasm tag did not get passed on!

Re:Is it all about the license? (1)

swv3752 (187722) | about 6 months ago | (#46537029)

MIT allows one to take your code and do what they will, including wrapping it up in a proprietary license. GPL requires that if one takes code, makes changes and distributes, they need to make the sourceof thsoe changes available to those they distribute the compiled or source code to. An example of taking MIT licensed code is what Microsoft did with BSD networking code and kerberos. The changes Microsoft did to BSd to make it work in Windows are lost to the community, including any potential bug fixes and security improvements. MS took kerberos and made it incompatible with the Open Source offerings.

The other issue is that if you mix GPL and MIT licensed code, the whole thing becomes GPL.

Re:Is it all about the license? (1)

unixisc (2429386) | about 6 months ago | (#46537849)

What is the essential difference(s) b/w MITL and BSDL?

Re:Is it all about the license? (1)

dalias (1978986) | about 7 months ago | (#46539689)

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.

Re:Is it all about the license? (0)

Anonymous Coward | about 6 months ago | (#46539485)

If you license under MIT or BSD you don't have to deal with the FSF children harassing you to rename it GNU+Project.

Reinventing GPL wheels (0)

Anonymous Coward | about 6 months ago | (#46534385)

Such a trend to reinvent wheels. Hidden intention seems to be to allow more "Mixed source" BS through the push for permitive licenses. And devs are falling all over it by providing free code to these projects. A shame.

Re:Reinventing GPL wheels (1)

LDAPMAN (930041) | about 6 months ago | (#46534687)

That Devs are "falling all over it to provide code" is the point. Permissive licenses are desirable to a lot of people.

Re: Reinventing GPL wheels (0)

Anonymous Coward | about 6 months ago | (#46535095)

Permissive licenses are only desireable to people who want to prevent end users from having the same freedom that developers have. Similar to how governments want to prevent citizens from having the same power that government agencies have.

Re:Reinventing GPL wheels (0)

marcello_dl (667940) | about 6 months ago | (#46536193)

Yes, people who want to avoid the requirements of the GPL, which asks simply for letting people get advantage of the code you distribute as you got advantage of the code you modify. "Freely you have received, freely give" (Matthew 10). Therefore if you love Jesus you follow the GPL, if you don't believe in god you follow the atheist Richard M. Stallman's license. Else you are obviously wicked.

Re:Reinventing GPL wheels (2, Insightful)

thevirtualcat (1071504) | about 6 months ago | (#46534725)

If you're a developer working for a company and you have your choice between an MIT|BSD library and a GPL library that, on a technical level, work equally well, it's a hard sell to choose the GPL library.

Consider...

"Well boss, if we use libfoo, we'll have to disclose our source code since it's GPL. There are ways around it by doing things like writing LGPL wrappers and dynamically linking it, but we'll have to distribute THAT source code, instead. Plus, you may want to run this by legal, since the developer has outright refused to sell non-GPL licenses..."

Versus...

"Well boss, if we use libbar, we can just use it since it's MIT. If we make changes to it, we should contribute them back, but we're not obligated to do anything except keep their copyright notice."

With that in mind, is it any wonder projects like llvm and musl are popping up and gaining the support of large companies that use them?

Re: Reinventing GPL wheels (0)

Anonymous Coward | about 6 months ago | (#46534999)

You do know that glibc is lgpl?

Re: Reinventing GPL wheels (1)

thevirtualcat (1071504) | about 6 months ago | (#46535149)

Ah, so it saves them the trouble of writing the LGPL wrapper around it. Good to know.

Re:Reinventing GPL wheels (3, Insightful)

dalias (1978986) | about 6 months ago | (#46535153)

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.

Re:Reinventing GPL wheels (1)

dalias (1978986) | about 6 months ago | (#46535837)

BTW, in case anyone thinks I'm making up the thing about intentionally linking to ancient glibc, see this: http://www.crankuptheamps.com/... [crankuptheamps.com]

Re:Reinventing GPL wheels (0)

Anonymous Coward | about 6 months ago | (#46535547)

Yes, doing something new and improving on the status quo is a horrible thing. Well, ill just go back to reboot my win3.0 box, Trumphet winsock is acting up again, brb.

And indeed the license does matter. Maybe not to you, but to many other people (and for many different reason). It is a shame you feel the need to tell people what is worthwhile to work on or that you are actually berating developers for adding code to open source projects in the first place. You shoes must be damn tight.

Link to comparison chart (4, Informative)

paulpach (798828) | about 6 months ago | (#46534387)

Here is a link to the comparison chart [etalabs.net] mentioned in the description.

Re:Link to comparison chart (0)

Anonymous Coward | about 6 months ago | (#46534397)

That seems to be from 2011 ...

Why should I drop glibc? (1)

peppepz (1311345) | about 6 months ago | (#46534571)

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.

Re:Why should I drop glibc? (4, Insightful)

dalias (1978986) | about 6 months ago | (#46535165)

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.

Re:Why should I drop glibc? (2)

peppepz (1311345) | about 6 months ago | (#46536519)

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.

Re:Why should I drop glibc? (1)

Anonymous Coward | about 6 months ago | (#46537843)

You get your binaries from distributions anyway and with musl your closed source bits can just statically link safely libc and live happy and isolated.

This is good (0)

Anonymous Coward | about 6 months ago | (#46534661)

I am glad to see an alternative to GNU's C library. I have run into a number of bugs with the GNU C library, or more specifically, incompatibilities which crop up between versions. Sometimes behaviour changes between one version of the library and another, causing end-user applications to stop working properly. If someone provides a more consistent library with similar performance, I would be happy to see it adopted.

Missing the only useful comparison. (1)

Anonymous Coward | about 6 months ago | (#46536055)

The compare page is missing the only other entry I wanted to see.... and that is, BSD libc. This is widely used by QNX (Blackberry) and probably all kinds of other vendors. I image Apple has their own fork.

The others aren't comparable because they're copylefted, so cannot be used everywhere like musl and BSD libc can.

Won't be any true open source left soon (-1)

Anonymous Coward | about 6 months ago | (#46536503)

Tragic to watch this happening! True open-source code is being slowly replaced by code that corporations can exploit to build walled gardens. They're slowly replacing the whole toolchain from top to bottom with code that they can use to make money. Apple is sitting on billions, and what benefit do any open-source contributors get? I wouldn't work for one of these projects and be exploited like this. If Apple wants to use part of the toolchain that makes them billions, they can pay for it.

Compared to Bionic (1)

SDPost (3490797) | about 6 months ago | (#46538209)

I wonder how small Musl is in comparison to Bionic which is really, really small.

Re:Compared to Bionic (1)

dalias (1978986) | about 7 months ago | (#46539733)

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... [github.com] 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.

Load More Comments
Slashdot Login

Need an Account?

Forgot your password?