#MUSL
@tobtobxx #nixpkgs has experimental #musl support
https://github.com/NixOS/rfcs/blob/master/rfcs/0023-musl-libc.md
here is a discussion to use it by default
https://github.com/NixOS/nixpkgs/issues/90147
you can use dynamic linked packages with e.g.
nix-shell -p pkgsMusl.hello
see also pkgsStatic
#nixos can run from ram with
boot.kernelParams = [ "copytoram=1" ];
(as the installer does)
it would be interesting to see native packages with sandboxing and granular permissions, integrated in the desktop. then nix might be able to make #flatpak obsolete
#Wine 8.6 Released With Bundled #Musl Libc Math Library
https://www.phoronix.com/news/Wine-8.6-Released
Original tweet : https://twitter.com/phoronix/status/1646973014443978753
Uhg, sorry this release cycle has taken so long. 😫 Trying to get things together ASAP now for the #musl 2.39 release...
🪤 Why I Will Never Use Alpine Linux Ever Again
— @martinheinz
「 Usually, you would not notice this difference, because most of the time a single UDP packet (512 bytes) is enough to resolve hostnames... until it isn't enough and your application (running on Kubernetes) that previously worked completely fine for months suddenly starts throwing "Unknown Host" exceptions for one particular (very critical) hostname 」
In case anyone's wondering, this has come up again because, if all goes well, #musl is finally going to be getting first-class IDN support! 🥳
Sadly, it looks like no one was able to solve the issues around creating a Node.js binary for Musl on arm64, so it looks like Kitten¹ won’t be available on @postmarketOS on mobile phones, etc., in the foreseeable future (unless someone with the necessary knowledge and time can step up right away before this commit is reverted).
https://github.com/nodejs/unofficial-builds/pull/59#issuecomment-1451256522
Good news reported on #musl mailing list: Linux time namespace behavior is now fixed! https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=2b5f9dad32ed19e8db3b0f10a84aa824a219803b
OK, back to some #musl stuff: it's always interesting to me how some folks' reaction to it revealing a bug in calling code has been "can you make it stop doing that?" rather than being thankful and fixing the bug in the calling code. 🙃
Wonder if anyone has any ideas why the new Alpine Linux musl/ARM64 Node.js build is failing and/or can help fix it.
https://github.com/nodejs/unofficial-builds/pull/59#issuecomment-1436328696
If we can get this fixed soon-ish (before it’s reverted) it’ll mean – among other things – that Node.js will run on @postmarketOS on phones and other mobile devices.
#NodeJS #postmarketOS #musl #alpineLinux #arm #arm64 #helpWanted
With pending bugs/patches mostly done (push coming soon), working up slowly towards a #musl 1.2.4 release now! Gigantic WHATSNEW summary in draft.
If you're using #docker images for #testssl.sh you should do a "git pull".
#musl libc seems to have performance problems wrt #glibc .
Thanks to polarathene (https://github.com/drwetter/testssl.sh/issues/2299)
Anyone know anyone on the NodeJS team that might have time to merge this pull request?
https://github.com/nodejs/unofficial-builds/pull/59
#nodeJS #postmarketOS #alpineLinux #arm #musl #JavaScript #SmallWeb #SmallTech #mobile #education #foss #openSource
Imagine Node.js running on a @PINE64 PineBook or PineBook Pro with @postmarketOS… could be very useful for education (not to mention make development more accessible in general).
https://github.com/nodejs/unofficial-builds/pull/59
(If this pull request gets merged, Kitten – https://codeberg.org/kitten/app – will be able to run on the PinePhone and be used for Small Web development on it.)
#nodeJS #postmarketOS #alpineLinux #arm #musl #JavaScript #SmallWeb #SmallTech #mobile #education
@jbzfn AIUI @alpinelinux's Firefox package disables malloc replacement and is thus using #musl's mallocng, one of the most hardened allocators available.
Happy ending to a disturbing bug report with #musl: application was calling free() from a signal handler, introducing a sort of allocator state corruption I hadn't seen before. https://www.openwall.com/lists/musl/2023/01/27/1
Yay, #musl mallocng just found yet another buffer overflow, this time in iwd. Which apparently nobody runs under valgrind... 🤦
@snaums @postmarketOS It's possible, but highly recommended against. You're fundamentally changing what #AlpineLinux and #postmarketOS are. I'd recommend using a different distro instead.
What problems do you have with #Musl?
In this case, trying to compile against glibc and link against #musl. 🤦 And claiming musl is broken when it doesn't work.
I know #musl has a lot of places where code is doing stuff to satisfy hidden constraints/requirements, like inability to allocate resources (at all or after a point of an operation having caused irreversible side effects) and I think it would be nice for these to be more obvious to readers.
Ok, idea for a fun game I'm going to play/host when I'm back home: folks reading #musl point out places where it's not obvious *why* something is being done the way it is, and I get to either add comments, clarify/simplify the code, or cite an existing explanation somewhere in the repo.
New round of test case failure reports against #musl fnmatch and they're all from systemd-originating tests asserting wrong behavior from glibc and undefined behavior matching glibc. 😂
New WONTFIX hall of shame entry courtesy of #musl folks: https://bugs.openldap.org/show_bug.cgi?id=8988
I'm running Ubuntu servers with LTS versions, from 16.04 to 22.04. My development system runs on the latest version, so building #Rust executables for x86_64-unknown-linux-gnu will not run on older versions due to the GLIBC dependency.
Instead of building the executable in a #Docker container with the same OS version as the target system, I opted for the #MUSL target instead. It adds a little overhead, but the whole process is much simpler.
What would you do? What do you think is better? Why?
Happy to report that the entirety of our #AlpineLinux gccgo compatibility patchset for #musl libc has now been integrated upstream. If you are using Go on a musl-based Linux distribution, consider bootstrapping it using gccgo: https://github.com/golang/go/issues/51280#issuecomment-1362855803
@rwlowry Mostly because there are no simple, fast, no-bullshit options that vaguely resemble #RHEL.
It's something I've really missed at work where certain colleagues insist on staying at least somewhat compatible with RHEL. Besides, I like how #DNF handles transactions and history even if the spec files are written in a terrible DSL.
I don't particularly condone VMware's business practices but #tdnf is one of their simpler, more open projects.
#AlpineLinux and #musl also, in my opinion, can focus a bit too much on correctness to the point where it impacts usability, compability and freedom of choice.
Today I tried to upgrade my #Pleroma instance up to the version 2.4.4. For some time past I use OTP version bundled with all libraries. But the crucial point is #Alpine #Linux running in #LXC container. Official guide recommends to use v3.10, but I stick with 3.11 since it’s the last version with some additional erlang packages which are absent in more recent versions.
So, as usual, the upgrade went smoothly with pleroma_ctl update --branch develop. But after pleroma_ctl migrate I’ve got very strange result:
Error relocating /var/lib/pleroma/release/erts-10.7.2.18/bin/beam.smp: pthread_getname_np: symbol not foundWell… I checked the binary with ldd and confirmed that it depends on libc.musl-x86_64.so.1. Quick search led me to #musl repo, where I found the particular commit where pthread_getname_np function was added. It turned out that this commit was added 3 months after release 1.2.2 and almost a year before release 1.2.3. Mentioned musl versions were integrated in Alpine versions 3.15 and 3.16 accordingly. So the easiest way was to upgrade my Alpine container to 3.16 and enjoy. But I don’t look for easy ways. Instead I downloaded Pleroma release 2.4.3 archive with erts version 10.7.2.17, unpacked erts directory only, added it to release folder in Pleroma installation and changed in source files all references to erts binary path from 10.7.2.18 to 10.7.2.17. And voilà, my pleroma server works again!
The #LinuxKernel has 2 #ELF loaders: one for executables and one for the interpreter (PT_INTERP). The latter is rather simple and expected only the last PT_LOAD to need zero padding. #LLD linking #musl's libc.so started doing this with multiple PT_LOADs...
Hopefully this will fix the bug
@dalias noticed:
https://lore.kernel.org/linux-hardening/20221111061315.gonna.703-kees@kernel.org/
I hope to merge these loaders in the future, but first we need better unit tests.
@Fu @agx His phone OS is, but there is also #postmarketOS which I wouldn't call GNU (being based on #alpinelinux and #Musl and #Busybox) but also isn't Android.
@kdrummond i wiped out mxlinux for a minimal voidlinux based on musl instead. And made a custom xfce-look to it. I am very pleased. #voidlinux #musl #xfce big fan of the Dracula themes.
YESSSS, I sucessfully cross-compiled a rust gui application from Archlinux x86_64 to postmarketos aarch64 (pinephone) without emulation and thus quite acceptable performance!
I'll write up the process and publish a blog or sth. for other poor souls soon.
Linux Standard Library Implementations: X32 can be 10% faster, but musl Libc 40% slower: https://www.youtube.com/watch?v=wq-a8juPFzs #linux #glibc #musl #libc #performance #comparison #standardlibrary #x32
Adélie Linux calls for assistance!
The people behind this promising distro are looking to expand their community of users & developers.
Adélie Linux is based on musl runtime library focusing on reliability, security, compatibility, portability, usability.
They even aim eventually to operate smoothly without any GNU components, utilizing Busybox or similar.
Please contact them if interested.
==> https://blog.adelielinux.org/2021/08/31/power-to-the-people
_
#Adelie #Linux #musl #libre #help #testing #developers #community #GNU
@tobtobxx @linmob Yepp, I gave up on getting the current version of #anki running on #postmarketos #musl. I changed to 2.1.15 which was the last version with a build system that I could at least remotely comprehend: https://pkgs.alpinelinux.org/package/edge/testing/x86/anki
Is there any advantage to using something like this (for static builds) https://github.com/utdemir/ghc-musl over just installing all the haskell depends via APK in alpine the normal way and building from there? like how fossa/haskell-static-alpine does it. I don't understand what the advantage of musl would be in this context.