Building a distro with musl libc
This is a modal window.
The media could not be loaded, either because the server or network failed or because the format is not supported.
Formal Metadata
| Title |
| |
| Subtitle |
| |
| Title of Series | ||
| Number of Parts | 611 | |
| Author | ||
| License | CC Attribution 2.0 Belgium: You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor. | |
| Identifiers | 10.5446/41909 (DOI) | |
| Publisher | ||
| Release Date | ||
| Language | ||
| Production Year | 2017 |
Content Metadata
| Subject Area | ||
| Genre | ||
| Abstract |
|
00:00
WebsiteCodePatch (Unix)Letterpress printingFirewall (computing)Information securityControl flowEllipseMessage passingBitCASE <Informatik>SubsetDirect numerical simulationPhysical systemMathematicsBootingSemiconductor memoryCore dumpString (computer science)Multiplication signDemosceneHypermediaSoftwareFile formatMassCartesian coordinate systemTouchscreenCellular automatonStability theorySoftware testingPower (physics)ImplementationException handlingError messageComputer configurationExtension (kinesiology)Flash memoryHard disk driveLatent heatStandard deviationProper mapQuicksortVirtuelles privates NetzwerkSoftware bugAndroid (robot)Software developerGoodness of fitKeyboard shortcutComplete metric spaceStack (abstract data type)Default (computer science)Real numberFamilyXML
08:32
Web pageBuffer solutionRevision controlLine (geometry)Letterpress printingDependent and independent variablesComputer architectureBoom (sailing)Android (robot)BitDirect numerical simulationRight angleDifferent (Kate Ryan album)Patch (Unix)SoftwareThread (computing)Server (computing)Default (computer science)Extension (kinesiology)String (computer science)Computing platformDomain nameLevel (video gaming)WindowFunctional (mathematics)Point (geometry)Water vaporOpen setComputer configurationMultiplication signStack (abstract data type)Exception handlingFile formatConfiguration spaceSearch algorithmError messageSoftware bugPhysical systemIntegerService (economics)Software testingForm (programming)Binary codeStress (mechanics)Message passingResolvent formalismMemory managementGoodness of fitSource codeXML
17:00
WorkloadMultiplication signMusical ensembleRevision controlPatch (Unix)SoftwareCodePoint (geometry)Data storage deviceMiniDiscBootingTheoryComputer configurationFunctional (mathematics)Right angleMassCartesian coordinate systemPrinciple of maximum entropySemiconductor memoryBinary codeAlpha (investment)Java appletMetropolitan area networkQuicksortCuboidDifferent (Kate Ryan album)OnlinecommunityOpen sourceComplex (psychology)Wave packetDependent and independent variablesMathematical optimizationBenchmarkGoodness of fitAlgorithmDynamical systemDemosceneLink (knot theory)BitOpen setWebsiteWeb pageComputer animation
25:27
Computer animation
Transcript: English(auto-generated)
00:06
Hi everyone. I am Natan Alkopam. I work with Alpine Linux. I work for Docker right now. And I will talk a little bit about Masolibsy.
00:21
So how many of you have used Alpine Linux one way or the other? Wow, that's a lot of you. That's cool. How many of you have used Alpine for more than five years? Awesome. Some of you? Cool.
00:42
Ten years? Good? Very good. Okay. And the screen looks nice, I see. So a little bit about the original design about Alpine Linux.
01:02
It was designed to run without hard disk. That was the basic idea. So we boot up, install the system in RAM memory, and you could take out the boot media if you wanted. That means that you want the system to be very small. You don't want to blow the system.
01:24
That was the original idea. So use cases was like firewalls, VPNs, and that. Nowadays it's very popular for containers. Docker will win. How many of you use Docker?
01:42
Good. Good. I think it makes very much sense to run Alpine in containers because of, you know, and you destroy it when you power it down. That's pretty similar to what you do in a container.
02:01
Disposable systems, right? Let's move on. We started with Gen2, so we built Alpine with Gen2 originally. Then we moved on to make it self-hosting. What's interesting is we use libc. How many families use libc?
02:21
Good. So we used that originally. BusyBox is a core thing. And in 2013 we had the last release with uselibc. At that time we had almost 3,000 ports, 2,800. I'll just move on.
02:42
There were some problems with uselibc. They required some patches to get it upstream, patches upstream. We had at that time, I think, 39 patches, and we couldn't get them upstream. One important thing was the threading issue, uselibc.
03:03
VLC crashed, or actually it hanged every time we exited due to threading implementation. It was not really fixable. So we thought we need to move on. Also the code base is really ugly, sorry to say that. But it's because it comes from Asian system glibc.
03:24
So it was not really nice to work with. So we saw this muscle libc thing. And on the website it says it's new. That's cool. It's lightweight. It's simple. And it's correct when it comes to security.
03:41
So it matches pretty well with the goals with Alpine. There's an active development. Clean, nice code base. Stable ABI. uselibc doesn't have that. It also provides some sort of ABI compatibility with GNU libc.
04:02
Actually, the Adobe Flash player works with muscle libc in Alpine Linux. So it kind of works. So that was some of the nice things with muscle libc. So of course there were some worries. Because not many distros have done this before.
04:23
Built a complete distro with muscle libc. So how much would break was a big question. How much work was it to patch things? Would upstream accept patches? Important questions.
04:43
It's not as major as GNU libc. So how many hidden bugs are there that we didn't know about? We were worried about that. But switching to glibc was not really an option. So we decided to just jump.
05:02
And how did it go? Surprisingly well. I think it's about 4% that was specific muscle base. We have more patches, but not many patches actually to make it work. Most of it just works.
05:20
I just move on because of time. So some of the nice things with muscle libc, experiences we had with muscle libc is that the code is very nice. We did some changes in muscle libc, submitted patches upstream. Very nice work with.
05:40
Nice community. They try to be correct. Sometimes that can be a bit annoying. Because you just want to move on. You have a real world application that breaks. And you ask them and say, hey, why don't we just, you know. And they say, no, we don't.
06:03
And it can be annoying, you know. But in most cases, that is actually good. And I am thankful to the muscle community that they are strict with that. And an interesting thing I noticed, when we patch software to make it work with muscle libc,
06:22
almost always the code gets better. And I always show some experiences with that. And upstream, always, almost always, we'll accept patches to support. Because we send a patch, this breaks POSIX,
06:43
and they will just accept it. There are a few exceptions. Yeah. That's true. systemd is one of them. So, if you want to go this road,
07:01
what do you need to watch out for? If you have an application that you want to build with muscle libc, what are the things you need to watch out for? There is no define, muscle define. You cannot say, you cannot test in your C code. This runs on a muscle system. You cannot do that.
07:20
The default stack size is 80k. There are some extensions in print format strings. There is no lazy binding. And there is one very nasty thing there. If you want to print error messages. And the DNS resolver. I will take them one by one.
07:43
So, there is no muscle define. This is a patch from MISA. They got upstream. And they test, oh, if you run, they did that before, if you run an Apple system, or if you run FreeBSD, NetBSD, OpenBSD, if you run Android, blah, blah, blah,
08:02
then you do like this. Imagine if there actually was a muscle define. What do you think would happen with the code here? So, because they don't have that define, they just say, okay, you know what? If you are not an exception,
08:21
just assume you are following the standard. And then you can just remove all this garbage and the code gets better. That's a proper way to do it. The problem is the stack size 80k windows, I think you have one megabyte. OpenBSD is 256k, maybe.
08:43
FreeBSD 512, depending a bit on the architecture. glibc, default stack size for threads, is 8 megabytes. So, if you spawn 10 threads in glibc system,
09:01
it will just use 80 megabytes. Doing nothing. This one is actually the smallest one I know, default stack size. We had an interesting patch in Firefox. If you see at the out buffer,
09:21
koutsize, how big is that buffer that ends up in the stack? 128k. What do you think happens if you try to allocate 128k when you only have 80k? It goes boom. So Firefox started to crash,
09:40
and this was the issue. When I searched bugzilla for Firefox, I actually found another bug on Windows, which has one megabyte stack size. They crashed for the same reason. Generally, you don't do that. You don't allocate 128k on the stack.
10:04
Just don't do it. That's kind of a stupid thing to do. So, they accepted the patch. I think this went upstream. You don't see it, but they will allocate it on the heap instead.
10:21
There are some issues with the format strings. In general, just read the man page. You will see something like this. glibc provides some extensions. If you see that, pay attention. Because if you use those extensions, it may work.
10:42
It may not work. You have no guarantee that it will work. It may work on a recent muslibc. It maybe doesn't. Probably will not work on an older muslibc. So pay attention on the what the man page says. Watch out for the extensions.
11:06
And we will take a look at this one. And this one is really nasty. So you have this function to print error message. Can you guys see a problem with the two different versions up there?
11:20
One returns an integer. The other one returns a string. How do you know which one do you have? If you have a pre-compiled binary, and you want to be ABI compatible, how do you know which one you get? You cannot really know that actually. So that's kind of annoying.
11:43
You shouldn't really use this. Try to avoid it if possible. I will show you a patch that is from vmware. Not too old actually. Open vm tools crashed.
12:02
And the reason was they test that if you're running on Linux, then use the glibc version. And at some point someone found out that on some platform NLM, I don't know what that is, but probably it runs on Linux, right?
12:25
And Android also runs on Linux. So they added different platforms. The real fix is check for the extension, the exception.
12:40
And if you're not the exception, assume the standard behavior. That's the fix for that. How am I on time? I'm on a minute. Then I don't need to stress. Thank you.
13:00
Another issue you may have noticed already is the DNS resolver. The man page says how things work. Muscle doesn't work the way the man page says. You need to be aware of that. So if you have this, in this example, what would you expect?
13:20
You might expect that it would first ask the 192 server and after that go to the next one. And muslibc, it does not do that. It will actually send a request to all of them. And the first one responding will have the answer.
13:46
So you might get surprises there. On the upside, you get faster resolving, right? But there are also other benefits doing this because then you cannot assume
14:03
that you get different responses from different DNS servers. If your software relies on different responses, on different name servers, then you are likely doing something wrong. You shouldn't be doing that in the first place.
14:22
So if your software runs on muslibc, you are doing good. If it doesn't, you're probably doing something wrong. The same thing with this search keyword. It was added not too long ago in muslibc. If you have this and you search,
14:42
you do ping fubar, will you search for a fubar example.com? Will you or not? Depends a little bit on your configuration, right? And it depends a little bit on who's giving you the response.
15:01
But if you rely on that behavior, that you will first search for one and then the other one, what happens if the bar becomes a TDL, the top level domain, TLD?
15:23
Well, things may break, right? And there are some documents from the DNS people saying how do you avoid these kind of conflicts. And if you run muslibc, you don't have this problem. If your software runs on muslibc and it works,
15:42
you don't have that problem. You can be sure that you always get the same response. It will always only search for fubar.
16:00
If you don't get response on that, it will not give you anything at all. Does the search thing work? It doesn't really work. You can actually add an option, an opt. There is an option for it. You can do a configuration option. And then it will always only search with the full name.
16:21
So it will always add the suffix. It will not do both of them, either one of them. That can cause some problems, so it's good to be aware of that. Some conclusions I have here at the end.
16:44
muslibc, I would say it's ready for the main line. I would say it already is the main line for some things. It works surprisingly well to build a complete ISTRO. Most of the things just work. Firefox works. We do have some patches for it.
17:02
LibreOffice works. It works pretty well, actually. A lot of things work just out of the box. We have XEN hypervisor working built with muslibc. QEMU works. We have a lot of things that just... Open GDK also works.
17:20
Open GDK also works. Open? GDK. GDK. GDK. Yes, yes. Works. Sort of, at least. And when you need to adjust your software, when you need to patch some software to make it work with muslibc,
17:41
almost always, the code ends up better. So that's kind of a nice thing, because it improves the overall code quality in the open source community. So my conclusion is muslibc is just awesome.
18:03
Do we have any questions? Here we have many questions. Yes? I think it's good to have more than one libc, but you said that GDK is not an option for Alpine. Why is it not? Because it was... Can you repeat the question?
18:20
Why is GDK not an option for Alpine Linux? Back at that time, we were running from RAM. It was too big. It was just too big. We didn't want that big. And also, if we went to glibc, what difference would Alpine be from others?
18:43
You know, you could just run Ubuntu or Red Hat or whatever, you know? Yes? Is muslibc faster than glibc? Is muslibc...
19:01
Because you say there's some training issues with glibc and microlibc... Yes. Yes, that's a good question. Is muslibc faster than glibc? Depends on your workload. Some things it's faster, some things I expect it's not.
19:21
I don't know really, overall. Can you give an example of a workload on which it is fast? I don't know. I haven't done much... Does anybody know a workload where muslibc is faster? Lots of dynamic linking. Lots of dynamic linking. Yeah, that's a...
19:41
I believe that. There's a benchmark page in the muslibc website where they list a few functions and benchmark a few different things. I think there are also some sorting algorithms where muslibc is faster. Yes, I don't know how up-to-date that is. I think it's pretty old, actually.
20:01
But there are some... The main things that are known to be slower are the lack of highly optimized memcpy. The main things known to be slower are the lack of highly optimized memcpy, which may make a difference in some way. Okay, yeah. If you really care, use your own. Yes. Optimized memcpy can be the situation where it's slower.
20:21
Yes? In your example here, you got rid of the reentrant version of strerror and just went with the non-reentrant one. Yes. That doesn't necessarily seem safe in some cases. Actually, it is reentrant. Even the... This one, you mean? Well, the one, yeah. Yes, it is. But the problem is that there are two different that are reentrant.
20:44
Right. They are exactly the same thing. Right. But they just return different things. So you may end up with a POSIX version, or you may end up with a glibc version. Right. And in the patch, it's reentrant.
21:02
Oh, I see. So it should be safe. Yeah, thank you. Any more questions? Why did you forget the idea to only run in RAM? Ah, that's a good question. Because... What was the question?
21:21
Why we only run in RAM? Okay, why don't you... Why you don't run anymore only in RAM? Why we don't? Why did you stop running only in RAM? Actually, we support that. We still support that. So the live CD will run from RAM. You can, in theory, boot up the live CD,
21:42
take out the CD, and it will continue to run. So it runs still from memory. But we support disks now as well. So you can install it on disk as well. Like you said, the user community is usually pretty good. And the question is, I think, in your experience,
22:01
how long does it take you to get in a non-trimmed patch? Like, how much bike shedding is actually going on? Because, you know, some libc's have problems with that. So how much bike shedding, how much trouble is it to get in a patch in Maslibc?
22:20
In my experience, well, the times when I needed a patch in Maslibc, we had a specific problem. Then I have asked them, what do you guys think about that on IRC? And normally it's they who come up with a solution. And then I make the patch that does the way they do it.
22:42
So that has been not a big issue. The times where it can be an issue is if you want to hack something, do something ugly, then they will say, no, we don't want to do that. If you have a good reason for it, they might accept it. But normally it's not a big problem,
23:04
in my experience, to get patches in there. Do we have more time? You mentioned OpenJDK runs soda with the user. Can you explain why you use soda? I don't have much experience with OpenJDK,
23:21
so I don't know really. I have heard that you need the dynamic linking, sorry, the lazy loading with that, which doesn't work, it's not supported with Maslibc. It's not supported at all at this point. So you might get problems with it,
23:43
if you depend on that. But at least Hello World works. The applications I have come into works. It may work, it may not, I don't know really. Are there better options for running Java with the user?
24:01
The problem with Java is that Oracle provides pre-compiled binaries against glibc. So they only support that. If you try to do something else, it might work, it might not. You can probably pay Oracle to support Maslibc,
24:21
but you have to pay them. We had actually an issue with that. Someone asked for it, and the response was, you have to pay Oracle guys to do it. I don't know what the applications are on OpenJDK and offline, and doesn't have any problem too far.
24:41
Actually I didn't know that there's some problem, and there are also complex applications like Alpresco, and it seems a bit too far. So I think it's not a big issue. Big issues are people who just need scenes from running Oracle PDK on the offline.
25:03
It's just not possible, because Oracle does not provide binaries, provide programs, so on and so on. Yeah, it doesn't work. Thank you. So most things will work. Most things will just work. Jacob, time is out.
25:23
Thank you very much everyone.