@josephholsten @Lulukaros @_bapt_ @chrisoffner3d @vaartis
Similarly, I'd not work on my own #toybox+#musl / #Linux distro if I felt there was a good, minimalist embedded Linux that could do what I want from a single 1440kB 3,5" FDD to boot from…
Feel free to make a clone based off a #BSD if you want to...
OK - as of last night moss supports being built with static #musl libc :O
Note, this is required as be build libsqlite3-sys and co into a single binary to prevent disastrous update scenarios.
Granted, its a "fat" binary (approx 7mb?) but its also fully self contained and has an async runtime, TLS implementation, etc.
TLDR if you have a moss binary you can produce entire Serpent roots + containers. Same magic happening with boulder for bulletproof infra!
Cuz I think this would work great and #decentralization would definitely reduce the burden of hosting and allow to further adapt it.
I.e. adding an #OnionService because I'm the kind of #MadLad that shoves vintage systems running #Lynx on OS/1337 (#toybox + #musl / #linux) behind a #OPNsense to provide them with @torproject / #Tor connectivity until I have ported that to #OS1337 as well...
There needs to be something easier and better than #Python with up-to-date bindings that can support building #Qt stuff with #musl libc. I really don't like using Python and only do because C++ (or rather, #CMake) is too hard to do new stuff in for me and CXX-Qt won't build with musl (could target a #glibc distro like #DanctNix #Arch, but then I'd be ignoring the entire set of devices supported by #postmarketOS). Why can't I just use #VB transpiled to #Rust?
The future Musl libc roadmap is for glibc-ABI-compat handling to be shifted out of #Musl libc to the gcompat package. Musl Libc could do some sort of shims (and which musl ldso would assist it in shimming by letting a delegated
library interpose on modules that have http://libc.so.6 dep) #clangbuiltlinux https://openwall.com/lists/musl/2023/08/23/2
@HopelessDemigod The current goal is to get a 0.1 release that fits on a 1.400kB 3,5" FDD and includes #Linux (ideally 6.6.6 for maximum meme factor) #Toybox and #dbclient (#Dropbear #SSH as SSH-Client only) compiled against #musl-cross and bootable on any #i486 and up.
> still reachable: 73,728 bytes in 1 blocks
(When running a simple hello world c++ project)
From what I can tell the musl c++ library leaks memory (as does glibc) but valgrind doesn't properly ignore it (which it does for glibc)).
However, all my attempts to get valgrind to ignore it failed this far... :blobcatsadreach:
After debugging for a little over a day, it seems that the issue has something to do with #musl and how it works with libraries?
Sadly, this means that I cannot try out iced as I wished...
Edit: I just created a Void Linux glibc podman container, built the app in that, ran it, and it worked!
Whilst a bit dated I think the talk is still valid...
I want a really #BareBones #Linux distro as an exercise in #minimalism and because I think we should embrace #FrugalComputing and that people should still be able to use a system just with a 1440kB Floppy to boot.
Even if that means they'll only have an #SSH-#Terminal using #Dropbear as #client...
But I don't expect them to do so no matter if there are 1 or 1.000.000.000 devices running #OS1337...
And ofc all the tools I need daily like #SSH (#OpenSSH), #OpenVPN, #WireGuard, #IPsec, #pfSense, #OPNsense, #ipFire, #LUKS/ #dmcrypt and the whole #toolchain needed for OS/1337 like #gcc, #musl, #toybox, #dropbear and so on.
Error: Missing Dependency: glibc
Thought I could cheat the system. Long story short, installed the GLIBC variant of Void on a USB, booted into it, and redid the process of converting and installing (guide coming soon).
Uutils Rules: Yeeting GNU Coreutils from my System
On my first blog post, I explain how I installed uutils on openSUSE Tumbleweed - completely removing gnu coreutils. Everything went surprisingly smoothly!
I’ve read somewhere a while ago about how GNU was secretive about documentation for some parts of glibc, making it harder for alternatives like #Musl to achieve full intercompatibility. I think I saw this maybe on one of musl’s websites or something, but I can’t seem to find this anymore. Does anyone know where I can find this piece of information again?
Just when I feel like I'm ready to throw in the towel with email, I discover a solution that actually sounds sensible:
« #mxclient is not a normal MTA. Rather, it's a minimalist client for sending mail direct to the recipient's MX, or mail exchanger, in contrast to the widespread practice of sending through a "smarthost" or "outgoing mail server".
In combination with sufficient cryptographic measures, this ensures that no one outside the receiving domain's mail system can intercept or alter the contents of the message, making mxclient suitable for:
- Private bi-directional communication between individuals (with personal domains) or organizations that mutually implement this kind of delivery.
- Delivery of sensitive data like account access or password reset tokens without them passing through third party mailer systems.
- Avoiding dragnet surveillance of outgoing mail in otherwise conventional mail setups.
mxclient is not an outgoing mail queue. It delivers mail synchronously, to a single recipient, reporting success, temporary failure, or permanent failure via the exit status (using sysexits.h codes). It can be used as the backend for the separate queuing frontend to yield a full "sendmail" command for use by MUAs or scripts that expect asynchronous delivery.
Ability to send mail directly to the recipient's MX depends on having unblocked outgoing port 25 (many residential and mobile ISPs firewall it) and on not being on one of several "dialup"/residential IP address lists that many sites' mail systems use to block likely spammers. To get around this while still maintaining the security and privacy properties of interfacing directly with the recipient's MX, future versions of mxclient will support performing the actual TCP connection through a (SOCKS5 or ssh -W child process) proxy while keeping the actual TLS endpoint local. »
I hacked the latest Oracle Instant Client libraries (libocci.so and other crap) and SQL*Plus CLI (the most awful DB client ever), which are only distributed as binaries linked against glibc, to work on #musl libc and #AlpineLinux. It’s available in my https://github.com/jirutka/user-aports/. Packages: oracle-instantclient-oci, oracle-instantclient-sqplus, oracle-instantclient-dev etc.
Great example of Fork Considered Harmful just came up on #musl: a program that spawns children via fork+exec spending inordinate time in kernelspace (accounted as minor page faults) slowing down computation.
@ncommander Granted that's not common for #Distros to do so, and my goal with #OS1337 was to make something more practical than #Floppinux which can barely output some text on screen - at least connect to somethng else that is useful.
OFC I'll release it once tested and satisfactory in useability for what I want to achieve with it.
But yeah, there isn't much beyond #musl being shared among those processes, so it's mostly a tradeoff that'll cost storage or RAM in more extensive setups...
This is awesome...
@whitekiba yeah, I do intent on putting those a bit in order and add the .config for the kernel.
If necessary to get that 1440kB FDD target I do consider having only dbclient (dropbear but as SSH client) or just toybox (with wget enabled) to download the latter into a ramdisk.
Or using busybox.
The idea is to use that sleek baseline to expand.
I am currently working on a #minimalist #embedded distro based off #toybox / #Linux + #musl, because #Glibc is a shitty mess that bricks stuff at random in minor version updates for no good reason!
Strongly considering trying out a new form of release condition for #musl, that really should have been obvious: rolling a release whenever there's been a bugfix for something reasonably user-facing (vs like silent/"harmless" UB or weird corner cases nobody but me cares about) and there's not anything release-blockingly unstable in main.
(The latter condition could be dropped if there were a "stable branch" of course, but for the most part I don't think it's an issue at present.)
@foone See the code in #musl for evaluating plural form expressions in gettext translation files. It's extremely small: https://git.musl-libc.org/cgit/musl/tree/src/locale/pleval.c?id=v1.2.4
A really common form of the second error, and one just encountered on #musl debugging a buffer overflow mallocng caught, is where T2 is inadvertently T1 * rather than T1.
Due to issues with how this instance is run and who is permitted to be here and influence moderation decisions, #musl's social media presence will likely be moving off Fosstodon.
Recommendations for an appropriate instance friendly to hosting project accounts, and with agreeable values, would be welcome!
@bitpirate @gamingonlinux and as much as I'd love to see every game getting updated, it's illusional that publishers and devs will invest the time to do so on one-time-purchase titles that are over 2 years old, don't sell any significant numbers or don't get any other revenue to pay for workarounding the shit that #flibc does.
There's a reason Distros like #AlpineLinux, #ChimeraLinux and almost all #embedded systems using #Busybox or #Toybox want to get rid of #glibc if not replace it with something like #uClinux, #musl,or another #libc...
Just got a bug report in #musl that appears to be this hot garbage. 🤦 https://nitter.net/RichFelker/status/1357733309737021444 Reporter left before identifying the system but it's the only plausible explanation I see for statx failing with EINVAL instead of ENOSYS on old kernel...
I love rediscovering places in #musl where someone's brought up a scary corner case that almost surely has wrong behavior and... nope! that was handled right a decade ago!
Why donate to the #musl libc project?
A blog post by the author of the #Zig language
I found a cool #linux #distro the other day called "Oasis Linux" that I wanted to get more people to learn about bc it's intriguing.
It's completely statically built using #musl and various other alternatives to typical tools.
It seems they make efforts to simplify the file system as well, which is nice.
Check it out: https://github.com/oasislinux/oasis
here is a discussion to use it by default
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
Original tweet : https://twitter.com/phoronix/status/1646973014443978753
Alpine Linux als Desktop
Die leichtgewichtige und auf Sicherheit getrimmte Distribution Alpine Linux lässt sich mit wenig Aufwand auch als Desktop-System nutzen. In dieser Anleitung erfährst du Schritt-für-Schritt, was dazu nötig ist.
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
「 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).
Wonder if anyone has any ideas why the new Alpine Linux musl/ARM64 Node.js build is failing and/or can help fix it.
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.
(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.)
this particular claim is provably bullshit.
pkgconf, when built with knowledge of the system toolchain, which every distribution does, does absolutely understand that /usr/include is a system include path.
otherwise it would be printing -I/usr/include a gazillion times.
and one of the main people who, has, for whatever reason, decided this is the battle he wants to fight in the year of our lord 2023, is just chilling on #musl with nobody calling him on his fuckery.
In this case, trying to compile against glibc and link against #musl. 🤦 And claiming musl is broken when it doesn't work.
I'm yet another transplant from twitter.
I'm a software developer, mostly using TypeScript, C#, and ObjectScript at my dayjob, though I prefer C at home. I mostly work on personal projects for fun or to scratch an itch, but I've contributed to #musl and #ffmpeg in the past.
I also occasionally dabble in 3d printing.