I'm not sure what they're putting in the water there, but it's clearly working.

God bless her and all who sail in her...

I have been doing some numerical (ODE/chaos) work, using exclusively long doubles (please don't attempt to persuade me they are unnecessary!), but found that on aarch64 (which I run on my Raspberry Pi 400s) the trig functions are merely double precision. I can't find out whether this is ever going to be fixed . . .

From [1]Wikipedia

"In C and related programming languages, long double refers to a floating-point data type that is often more precise than double precision though the language standard only requires it to be at least as precise as double . As with C's other floating-point types, it may not necessarily map to an IEEE format."

There is nothing in the C specification that states that a long double has to be more precise than just a double, and actually specifies very little about the real size of data types. This is a long-standing feature for integer and floating point datatypes, all the way back to the original K&R.

It is also possible that the underlying hardware does not provide quadruple precision floating point arithmetic (come on, we're talking about a Raspberry Pi here!), so if they actually did it, it may have to be done (slowly) in software.

So no conflict with the standard, it's not a defect, and won't be 'fixed' any time soon.

[1] https://en.wikipedia.org/wiki/Long_double

Was that an attempt? ;) Doesn't matter. I want them, and I can get them on all GNU/Linux systems (and probably on BSD I haven't looked).

Technically, the extended precision is based on 80-bit HW floating point on "intel" systems, 64-bit HW on ARM 32 bit systems, and 128-bit software floats on aarch64.

MUSL on aarch64 does 128-bit floats fine inherently, it is just the math library that clobbers it.

Perhaps you will now want to explain to me that SW floats are slow? I still don't care - I want them ;)

I misunderstood your comment. I had not realised that you were saying that although MUSL does software 128 floating point arithmetic correctly on AArch64, some of the other maths functions in the library don't work to this precision. That does seem a bit of an omission.

I was commenting on something much more generic with C data types. Sorry.

long double is 64-bit on musl in general; i doubt this is going to be fixed, and IMO it's a good thing (as you can never really be sure what long double is going to be, it's never guaranteed to be better than double precision)

you can use explicit quad-precision types if necessary, at least then you have a guarantee that they are indeed quad-precision (though of course, you cannot use standard c library with it for math ops, so a separate library would be needed, gcc provides libquadmath but llvm does not, but perhaps this could be addressed at some point)

I can understand removing SystemD but why the push to remove GNU?

Just curious.

Maybe he doesn't like Stallman?

In his presentation he says one reason is to prove that Linux does not equate to GNU/Linux.

Good enough reason for me but then he describes one of the biggest pains for those who need to modify a distribution, the system daemon. For embedded, single board people, it really sucks being forced into using Ubuntu if your SOM maker only supports it (and has proprietary dependencies in their variant of it). I agree with his assessment that systemd was needed but just isn't that great, it's got problems, like all init systems. I'm excited by his init system being designed to be modifiable down to bare initramfs yet able to work with Gnome (not that I require Gnome usually, it's just a great validation step/forcing function for development). Systemd just gets more and more brittle and it feels like even with plenty of experience plumbing with it and reading the documentation, it still can break unexpectedly from subtle changes.

From my point of view, the GNU toolset is going in a direction that I don't like.

I was annoyed when they pulled netstat, route, ifconfig et. al. from the TCP packages, and I was extremely cross when they pulled pg from coreutils (I work on traditional UNIX systems for my job, and muscle memory is persistent). It seems that some decisions are made on the whim of the package maintainers who won't listen to counter arguments.

So, yes, having a free platform with alternate tooling is of interest to me, although I would ask why, if you want the FreeBSD tooling, why not run FreeBSD?

The reason why I'm currently sticking with mainstream Linux distros is the scope of the pre-built repositories, although the above changes and systemd are challenging that decision.

netstat, route, ifconfig et al on Linux were never provided by GNU; they are part of net-tools (which is likely still available for installing on your distribution). The biggest reasons most distros switched from net-tools to inetutils were maintainership (net-tools had very little activity at one point, and all user-space support for cool new kernel networking features was going straight for iputils); and for whatever reason net-utils broke the output format of ifconfig which "forced" many distros to carry old net-utils versions.

net-tools is marked as depricated by many distributions, but I knew that it could be installed if it was not in the standard set for a distro. Unfortunately, I don't have admin. access to all of the Linux systems I work with, and do not have total freedom on some of the ones I do, so it's difficult on those systems.

I had assumed that because it was part of the fundamental networking in older GNU/Linux systems, that it was a part of GNU provided toolset. I must re-educate myself about exactly how much of the toolset is actually provided by the FSF.

Disclaimer: I'm not claiming the scenario I'm about to propose is the (or even a ) reason this project exists, but it is one reason why someone would create such a project:

Because of the (L)GPLv3 (although getting rid of as much GPLv2 as you can is also a plus for this scenario). Unlike the GPLv2, the GPLv3 requires hardware manufacturers distributing GPLv3-covered software to allow users to run said software on the hardware they sold, to stem what TiVO did (they gave the entire GPLv2 bits, but you couldn't run your own freshly baked OS image because it would only load signed images). IIRC, GPLv3 also closed a loophole regarding build systems (IIRC, you can arguably legally distribute your modified version of any GPLv2 stripped of the build system/"forgetting" to add the plumbing on the build system for your modifications).

Note that they didn't get here first; Android has been (L)GPLv3-free from day one, with their own ground-up implementation of Linux userspace (busybox is pretty much the only base component not written by google), and before that macOS stuck to the last stable GPLv2 versions of gcc, binutils/coreutils, bash, and samba until they got their own versions (invested heavily in LLVM, got coreutils from BSD, zsh to replace bash, and their own ground-up SMB implementation)

PD: Yes, Linux is GPLv2, but license enforcement efforts on the Kernel have been few, and there is seemingly lack of interest in enforcement within the project.

it's definitely not a reason, as this is a free software project and therefore concerns of random corporates about the gpl don't matter to me whatsoever

i do prefer less restrictive licensing for my own code, but there is absolutely nothing blocking (l)gpl3 stuff going to chimera (and there is plenty); the only real concern is agpl-licensed stuff because of potential legal concerns, but this is also of concern to mainstream distros

why the push to remove GNU

It helps to increase diversity. Like in life a monoculture of plants is more susceptible to devastation when hit by a virus or similar.

That is why I am pleased that the Intel x86/x86-64 architecture is seeing more competition.

the project faq answers this and a lot of other things

(one thing i will say is that there is no silly ideological reason behind it)

The Avro Shackleton is widely known to aviation buffs as "50,000 rivets flying in close formation" and is presumably the source of today's Linux wit.

Curiously, there is indeed a "Shackleton OS," though it ap[pears no more than a concept inspired by a mashup of Linux and iOS >shudder!<

Or several Unices flying in close formation.

I thought it sounded a nice idea until I read "Gnome on Wayland" :( Why?! I hate Gnome and Wayland is too new for me. A simpler DE and traditional X would have been nicer IMHO.

My thoughts too. Wayland is the systemD of graphical infrastructures.

Around 20 years ago, I went to see Stallman give a talk in London. To get a sense of the time, the crowd was full of black t-shirts including a selection from ThinkGeek, a large contingent of "Perl Monks", and a couple involving the BSD daemon apparently buggering Tux the penguin. If you've ever been to a Stallman talk you'll know that he has a Q&A at the end, during which there are usually a couple of edgelords who try to ask awkward questions. On this occasion a guy stood up and asked what Stallman thought about a project at the time that sought to replace all GNU software in Linux with BSD equivalents.

Stallman's response was "I'd say, what an enormous waste of effort."

Stallman's response was "I'd say, what an enormous waste of effort."

It appears to be one guy's pet project. Maybe it'll go somewhere, maybe it won't. But if he wants to try, why not?

If its BSD running on a linux kernel you should be able to run it as a container in a normal linux host.

Not sure myself why you would want to do that but I'm sure somebody will want to.

I know some corporates, e.g., Google, will not allow GPLv3 inside their code. Difficult to speculate why, perhaps it creates a hardware creep akin to Balmer's description of Linux, which seems to suggest GPLv3 does what it says on the tin and if there's no need to pick up the tin then don't.

Chimera is a pre-alpha by one person (see the appropriate XKCD) It might or might not be interesting, I've got no idea. Good luck to him scratching his itch.

I suppose the number of people involved will multiply based on the number of comments on this thread.

Perhaps one way to discover if any of this really matters is when Chimera gets to an RC and there are several developers.