 Hej alla! Jag heter Natan Al-Kopan och jag jobbar med Alpine Linux. Jag jobbar för docker nu och jag ska tala lite om muslimsyn. Hur många av dig har gjort Alpine Linux en gång eller andra? Wow, det är många av dig! Det är coolt! Hur många av dig har gjort Alpine Linux för mer än 5 år? Hur många av dig? Coolt! 10 år? Ja, väldigt bra! Okej, den här screenen ser bra ut. Så lite om originaldesign, om Alpine Linux. Det var för att röra med en hårdisk. Det var en basic idé. Vi bootade upp, installade systemet i RAM och du kan ta ut bootmedier om du vill. Det betyder att du vill att systemet är väldigt små. Du vill inte att systemet är blott. Det var original idé. Us cases var som firewalls, VPNs och så. Men nu är det väldigt populär för container. Docker. Hur många har du gjort docker? Bra! Bra! Jag tror att det gör väldigt mycket sätt att röra med Alpine Linux i containers. När du rör från RAM, installerar du bootup och deströjer den när du ställer den. Det är ganska simulant med vad du gör i en container. Disposable systems. Vi började med Gen2. Vi byggde Alpine Gen2 original. Vi stod på att göra det självfostigt. Vad intressant är att använda Lipsy? Hur många är familjer med Lipsy? Vi användade det originalt. BC Box är en stor del. I 2013 hade vi den senaste avdelningen med Lipsy. I den här tiden hade vi nästan 3 000 porter. 2800. Det var några problem med Lipsy. De behövde några patcher för att få den till upstream. I den här tiden hade vi 39 patcher. Vi kunde inte få dem till upstream. En viktig sak var att använda Lipsy. VLC kraschade eller hängde i alla fall när vi exaktade. Det var för att använda Lipsy. Det var inte riktigt fiktigt. Vi trodde att vi skulle behöva move on. Koldbasen var jäkligt för att säga det. Det kom från agentsystemet G-Lipsy. Det var inte riktigt bra att jobba med. Vi trodde att det var en muscle Lipsy. På webben sa vi att det var ny. Det var coolt. Det var liten. Det var liten. Det var korrekt när det kom till säkerhet. Det matchade ganska bra med Alpine. Det var en aktiv utveckling. En liten, fin koldbasen. En stabil ABI. Lipsy inte har det. Det har också en typ av ABI-kompatibeltid med Gnu Lipsy. A dobbflash player arbetar med muscle Lipsy. I Alpine Linux. Det arbetar. Det var några bra saker med muscle Lipsy. Det var lite förvånningar. Inte många distros har gjort det. Det har byggt en komplet distro med muscle Lipsy. Hur mycket beror det på? Hur mycket jobb var det för att patcha saker? Att uppstrymda? Att läsa patcher? Det är en viktig fråga. Det är inte så stor som Gnu Lipsy. Hur många hidden bugs är där som vi inte vet om? Vi var förvånade om det. Men att uppstrymda Gnu Lipsy var inte en avdelning. Så vi... Så vi decide just to jump. Hur har det gått? Surprising. Jag tror att det är 4% som var specifik muscle base. Vi har mer patcher. Not many patches actually to make it work. Most of it just works. I just move on because of time. So some of the nice things with muscle Lipsy, experiences we had with muscle Lipsy, is that the code is very nice. We did some changes in muscle Lipsy, submitted patches upstream. Very nice work with. 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. 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 Lipsy, almost always the code gets better. And I will show some experiences with that. And upstream always, almost always they will accept patches to support. Because it's, we send a patch. This breaks POSIX and they will just accept it. There are a few exceptions. Yeah. That's true. System D is one of them. So if you want to go this road, what do you need to watch out for? If you have an application that you want to build with muscle Lipsy, what are the things you need to watch out for? There is no define, muscle define. You cannot test in your C code. This runs on a muscle system. You cannot do that. 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. 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 free BST, net BST, open BST, if you run Android, blah, blah, blah. Then you do like this. Imagine if there was actually 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, 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. Open BST is 256K. Maybe free BST 512 depending a bit on the architecture. G-Lib C default stack size for threads is 8 megabyte. So if you spawn 10 threads in G-Lib C system, it will just use 80 megabyte 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, K out size, how big is that buffer that ends up in the stack? 128K. What do you think happen if you try to allocate 128K when you only have 80K? It goes boom. So Firefox started to crash 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. So generally you don't do that. You don't allocate 128K on the stack. Just don't do it. That's kind of 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. There are some issues with the format strings. In general, just read the man page. You will see something like this. G-Lib C provides some extensions. If you see that, pay attention, because if you use those extensions, it may work, it may not work. You have no guarantee that it will work. It may work on a recent muscle-lib C. It maybe doesn't. Probably will not work on an older muscle-lib C. So pay attention on what the man page says. Watch out for the extensions. We will take a look at this one. 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? 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. 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 and the reason was it tells that if you're running on Linux, then use the Gilib C version. At some point someone finds out that on some platform NLM, I don't know what that is, but probably it runs on Linux. Android also runs on Linux. So they added different platforms. The real fix is check for the extension. And if you're not the exception, assume the standard behavior. That's the fix for that. How am I on time? How many minutes? Oh, then I don't need to stress. Thank you. Another issue you may have noticed already is the DNS resolver. The man page says how things work. The muscle doesn't work the way the man page says. So if you have this example, what would you expect? You might expect that it would first ask the 192 server and after that go to the next one. And muscle lib C does not do that. It will actually send a request to all of them and the first one responding will have the answer. So you might get surprises there. On the upside, you get faster resolving. But there are also other benefits doing this because then you cannot assume 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. So if your software runs on muscle lib C, you are doing good. If it doesn't, you're probably doing something wrong. The same thing with this search keyword. Not too long ago in muscle lib C. If you have this and you search, you do ping foobar. Will you search for foobar 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. 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? Well, things may break, right? And there are some documents from the DNS people saying, how do you avoid this kind of conflicts? And if you run muscle lib C, you don't have this problem. If your software runs on muscle lib C and it works, you don't have that problem. You can be sure that you always get the same response. It will always only search for foobar. If you don't get response on that, it will not give you anything at all. 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 for the full name. 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. I have some conclusions here at the end. Muscle lib C, I would say it's ready for the mainline. I would say it's already its mainline for some things. It works surprisingly well to build a complete distro. Most of the things just works. Firefox works. We do have some patches for it. LibreOffice works. It works pretty well actually. A lot of things works just out of the box. We have Xen hypervisor working. Built with Muscle Lib C. QMU works. We have a lot of things that just... Open GDDS works. Open GDDS works. Open. 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 Muscle Lib C. Almost always the code ends up better. So that's a kind of nice thing. Because it improves the overall code quality in the open source community. So my conclusion is Muscle Lib C is just awesome. Do we have any questions? Here we have many questions. Yes? I think it's good to have more than one lib C. But you said that GDDS is not an option for Alpine. Why is not? Because it was... Why is GDDS... Was GDDS 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 GDDS, what different would Alpine be from others? You could just run a Bunt or Red Hat or whatever, you know? So... Yes? Is Muscle Lib C faster than GDDS? Is Muscle Lib C... Is Muscle Lib C... Is Muscle Lib C... Is Muscle Lib C... Is Muscle Lib C faster than GDDS? Is Muscle Lib C... Yes, that's a good question. Is Muscle Lib C faster than GDDS? Depends on your workload. Some things is faster, some things I expect is not. But I don't know really, overall. Can you give an example of a workload on which it is faster? I don't know. I haven't done much. Does anybody know workload where Muscle Lib C is faster? Lots of dynamic linking. Ja, that's... I believe that. Yes, I don't know how up to date that is. I think it's pretty old, actually. But there are some... The main things that are known to be slower are the lack of highly optimized men copy. The main things known to be slower are the lack of highly optimized men copy. Which may make a difference. If you really care, use your own. Yes, optimized men copy can be the situation where it's slower. In your example here you got rid of the re-entrant version of Stirrer and just went with the non-re-entrant one. That doesn't necessarily seem safe in some cases. Actually, it is re-entrant. Den här, vadå? Ja. Ja, det är det. Men problemet är att de är så olika att de är re-entrant. De är exakt samma. Men de rör bara olika saker. Man kan enda med en påsikts-version eller enda med en Lib C-version. I patch är det re-entrant. Så det ska vara säkert. Ja, tack. Några frågor? Varför förberederar du att man bara rör i ram? Det är en bra fråga. Varför rör vi bara ram? Varför rör du inte bara ram? Varför rör du inte bara ram? Vi håller på att hålla på det. Varsågod, vi håller på ram. Du kan, i teoriet, bjuda upp varsågod, ta ut varsågod och fortsätta att röra. Det rör fortfarande. Men vi håller på diskar nu också. Man kan installera diskar också. Som du sa, varsågod varsågod, och frågan är hur länge du tar dig för att få en bra patch. Hur mycket bjuda är det? Som du ser, har du problem med det? Hur mycket bjuda? Hur mycket problem är det att få i en patch i en muslim? I min experience? I en patch i en muslim hade vi en specifik problem. Jag har frågat dem. Vad tycker du om det på IRC? Normalt är det de som kommer upp med det. Och jag gör patchen så att de gör det. Det har varit en stor problem. Om du vill ha nåt, så gör du det. De vill säga att vi inte vill göra det. Om du har en bra visning för det, kanske du kan ha det. Men normalt är det inte en stor problem i min experience för att få patchen där. Har du mer? Har du sagt att OpenJDK har en sådan muslim? Jag har inte mycket experience med OpenJDK, så jag vet inte riktigt. Jag har hört att du behöver dynamic linking, sorry, lazy loading, med det som inte verkar, det är inte supportat med muslim. Det är inte supportat alls. Så du kan få problem med det. Om du dependerar på det. Men åtminstone hello world works. De applikationer som jag har kommit till works, det kanske verkar, det kanske inte. Jag vet inte riktigt. Har du bättre optioner för att följa med Java? Problemet med Java är att Oracle förbereder pre-compiled binaries till G-Libby. De har bara att supporta det. Om du försöker göra något annat, det kanske verkar, det kanske inte. Du kan prova att paya Oracle för att supporta muslim, men du måste paya dem. Vi hade en issue med det, någon frågade för det, och responsen var att du måste paya Oracle guys för att göra det. Det är problemet med G-Libby och Alpine, och det har inget problem. Jag visste inte att det var någon problem. Det är också ett stort problem med Alpine. Det är inte problem. Det är en stor problem. Det är en stor problem med Alpine. Det är inget problem. Det är inget problem. Det är bara ingen länge borrowed kan du give till en evad señor Det futurollerR heroic Det är complaint for the unbelievable Time is at the thank you very much everyone