#glibc

[kokosila]

sona pi toki pona li lon ilo glibc a!

mi pana e sona pi toki pona tawa kulupu pali glibc. tenpo suno ni la ona li kama tawa ilo glibc a! pana sin li lon la sina ale li ken kama jo!

ni la ilo Linux mute li ken sona e nanpa sike e ijo ante lili pi toki pona a!

awen la sona ni li lon la ilo lon ilo Linux li ken sona e ni: "toki pona li toki lon. mi o alasa e sitelen pi toki ni a!"

> env LC_ALL=tok.UTF-8 date 2024#)#01)#09 tenpo 21:45:11 lon -0500

glibc now has a toki pona locale!

i sent a patch with locale information to glibc, and it got committed today! it'll find its way into the next release.

with this, many Linuxes can understand locale formatting for toki pona.

additionally now that it has a locale, many Linux programs will be able to identify toki pona as a language, and furthermore, this allows many more programs to be able to be translated into toki pona.

> env LC_ALL=tok.UTF-8 date 2024)#01)#09 tenpo 21:45:11 lon -0500

[zeckma]

autism

(lfs w/ glibc-2.39 and mixed version of packages to ensure a proper working system, plus wifi access [no gnat/gcc-ada or mingw-w64 quite yet], and i streamed it all on my youtube channel)

[digitalcreationsllc]

New ‘Looney Tunables’ Linux Bug Gives Root Privileges on Major Distros

The flaw, introduced in glibc 2.34, highlights the severity and widespread nature of the vulnerability, emphasizing the need for immediate patching by system administrators.

[xnu-official]

But actually you would use

char* array = alloca(n * sizeof(array));

wherever you can! Because memory safety is important!

[tomanato]

My favorite operating system is River/Nix/SystemD/GNU/Linux, or as i've recently taken to calling it, River+Nix+SystemD+GNU+Linux

[andmaybegayer]

Any recommendations/cautions about using Alpine Linux on the desktop? It's always intrigued me and you're the only person I've seen post about it

Alpine is pretty good for desktop, very stable, good security practice, professional development philosophy, broad package availability. You will run into some very obvious pitfalls, although they can mostly be obviated by using some modern applications.

The Alpine wiki is a little sparse and at times can be weirdly focussed, like spending a lot of the installation page talking about the very specific usecase of a diskless install. Nonetheless, it's quite good and should be your first port of call. A lot of the things I'm mentioning here are well covered in the article on Daily Driving for Desktop use. I'm basically just editorializing here.

The installation procedure is command-line only, but pretty straightforward, you run setup-alpine and follow the prompts, assuming you want a basic system. If you need special disk partitioning, you'll usually have to do it yourself. There's a whole whackload of helpers to get you set up, like setup-desktop which will help you install any of 'gnome', 'plasma', 'xfce', 'mate', 'sway', or 'lxqt'. Most of these are called by setup-alpine for you, but not the desktop one. You can call it at any time though.

Most obviously, musl libc, no glibc. Packaged software will work fine. There's a compatibility shim called gcompat that will usually work, but might fall apart on more complicated software expecting glibc, for example I've had no luck running glibc AppImages. For more complex software, Flatpaks are a good option, e.g. Steam runs great on Alpine as a Flatpak, I run the Homestuck Companion Flatpak. Your last ditch is containerization and chroots, which are fortunately really easy to handle, just install podman and Distrobox and you can run anything that won't run on Alpine inside a Fedora or Debian or Whatever container seamlessly with your desktop.

Less obviously: no systemd. Systemd underpins some really common features of modern Linux and not having it around means you have to use a few different tools that are anywhere from comparable to a little worse for some tasks. Packaged applications will work smoothly, just learn the OpenRC invocations, Alpine has a really great wiki. For writing your own services, it's a lot more limited than SystemD, you're not going to have full access to like, udev functionality, instead you get the good but kind of weird eudev system.

If you're mainly installing things from the repos you'll barely notice the difference, other than that every package is split up into three, <package>, <package>-docs, and <package>-dev. This is a container-y thing, to allow Alpine container images to install the smallest possible packageset. If you need man pages you'll have to install them specifically.

Alpine has a very solid main repo, and a community repo that's plenty good, and worth enabling on any desktop system. It'll generally be automatically enabled when you set up a desktop anyway, but just a notice if you're going manual. You can run Stable alpine, which updates every six months, or if you want you can run Edge, which is a rolling release of packages as they get added. Lots of very up-to-date software, and pretty stable as these go. You can go from Stable->Edge pretty easily, going back not so much.

There's also the Testing repo, only available on Edge, which I don't really recommend, especially since apkbuild files are so easy to run if you just need one thing that has most of its dependencies met.

Package management is with APK, which is fast and easy to work with. The wiki page will cover you.

Side note: if you want something more batteries-included, you could look at Postmarket, an Alpine derivative mainly focussed on running on smartphones but that is a pretty capable desktop OS, and which has a fairly friendly setup process. I run this on an ARM Chromebook and it's solid. Installation requires some reading between the lines because it's intended for the weird world of phones, so you'll probably want to follow the PMBootstrap route.

[gentoo-official]

Just checked out the installation manual for Gentoo, and what the fuck.

The manual has 55 sections and 207 sub-sections. The above screenshot of the table of contents is 5275 pixels tall. Tumblr won't let me upload the full image without downscaling it until it's utterly unreadable.

Don't we have better things to do with our time?

Yes, the manual is long, but that's because it is thorough, not because it's arduous.

You can skip a good chunk of the beginning by downloading a stage3 tarball instead of a usual iso.

Beyond that, most sections are actually really short, usually giving you a set of options as subsections, which are about 2 to 5 commands long.

The only lengthy parts would be emerging (which you can shorten with binaries and/or a good make.conf), kernel configuration (which you can skip with genkernel or a kernel binary), and maybe glibc. Everything else is just "this is my subsection, i run this command, and onto the next section."

[torbers]

Got sunvox running on the uconsole! The key is to go to the older versions and get version 2.1c because the os doesn’t have the latest glibc.

[linux-opinions]

GNU sucks, the coreutils suck, glibc sucks, GCC half sucks, emacs sucks, I hate GNU

this is who you're being mean to. if you even care.

[birthdaysongs]

glibc/2.03_5/binutils would be a beautiful name for a baby boy

[zeckma]

glibc-2.39 has just released!

Tomorrow morning will be the start of my LFS streams! See you guys, then!

[cyber-sec]

New Linux glibc flaw lets attackers get root on major distros

Source: https://www.bleepingcomputer.com/news/security/new-linux-glibc-flaw-lets-attackers-get-root-on-major-distros/

More info: https://blog.qualys.com/vulnerabilities-threat-research/2024/01/30/qualys-tru-discovers-important-vulnerabilities-in-gnu-c-librarys-syslog

[reasonableapproximation]

A thing I've been looking into at work lately is collation, and specifically sorting. We want to compare in-memory implementations of things to postgres implementations, which means we need to reproduce postgres sorting in Haskell. Man it's a mess.

By default postgres uses glibc to sort. So we can use the FFI to reproduce it.

This mostly works fine, except if the locale says two things compare equal, postgres falls back to byte-comparing them. Which is also fine I guess, we can implement that too, but ugh.

Except also, this doesn't work for the mac user, so they can't reproduce test failures in the test suite we implemented this in.

How does postgres do sorting on mac? Not sure.

So we figured we'd use libicu for sorting. Postgres supports that, haskell supports it (through text-icu), should be fine. I'm starting off with a case-insensitive collation.

In postgres, you specify a collation through a string like en-u-ks-level2-numeric-true. (Here, en is a language, u is a separator, ks and numeric are keys and level2 and true are values. Some keys take multiple values, so you just have to know which strings are keys I guess?) In Haskell you can do it through "attributes" or "rules". Attributes are type safe but don't support everything you might want to do with locales. Rules are completely undocumented in text-icu, you pass in a string and it parses it. I'm pretty sure the parsing is implemented in libicu itself but it would be nice if text-icu gave you even a single example of what they look like.

But okay, I've got a locale in Haskell that I think should match the postgres one. Does it? Lolno

So there's a function collate for "compare these two strings in this locale", and a function sortKey for "get the sort key of this string in this locale". It should be that "collate l a b" is the same as "compare (sortKey l a) (sortKey l b)", but there are subtle edge cases where this isn't the case, like for example when a is the empty string and b is "\0". Or any string whose characters are all drawn from a set that includes NUL, lots of other control codes, and a handful of characters somewhere in the Arabic block. In these cases, collate says they're equal but sortKey says the empty string is smaller. But pg gets the same results as collate so fine, go with that.

Also seems like text-icu and pg disagree on which blocks get sorted before which other blocks, or something? At any rate I found a lot of pairs of (latin, non-latin) where text-icu sorts the non-latin first and pg sorts it second. So far I've solved this by just saying "only generate characters in the basic multilingual plane, and ignore anything in (long list of blocks)".

(Collations have an option for choosing which order blocks get sorted in, but it's not available with attributes. I haven't bothered to try it with rules, or with the format pg uses to specify them.)

I wonder how much of this is to do with using different versions of libicu. For Haskell we use a nix shell, which is providing version 72.1. Our postgres comes from a docker image and is using 63.1. When I install libicu on our CI images, they get 67.1 (and they can't reproduce the collate/sortKey bug with the arabic characters, so fine, remove them from the test set).

(I find out version numbers locally by doing lsof and seeing that the files are named like .so.63.1. Maybe ldd would work too? But because pg is in docker I don't know where the binary is. On CI I just look at the install logs.)

I wonder if I can get 63.1 in our nix shell. No, node doesn't support below 69. Fine, let's try 69. Did you know chromium depends on libicu? My laptop's been compiling chromium for many hours now.

[avladov]

Installing Node.js 18+ on CentOS 7: Fix glibc Compatibility Issue

Recently I had to install node 18 on an old CentOS 7 machine. Upgrading was not possible. Considering node 18 is relatively old, I didn’t expect any issues. Turns out, node 18+ is not officially supported in CentOS 7. CentOS 7 doesn’t have the necessary glibc library version for me to install newer node versions. If you try to install node 18 you get the following error: node:…