So in other Julia geometry-related projects that may be true, but for this particular corner of the ecosystem the main author (Júlio Hoffimann) has actually implemented much of the underlying geometry and other code from scratch (to the best of my understanding) in pure Julia in a whole set of packages, including e.g.
For this crowd, "machine learning" should really be read as parallel Bayesian inversion via MCMC (Metropolis modified with a form of "parallel tempering"), but that was a bit much to explain to a popular audience.
The underlying paper is https://doi.org/10.1126/science.adh3875:
Cox, Alexander A., and C. Brenhin Keller. "A Bayesian inversion for emissions and export productivity across the end-Cretaceous boundary." Science 381.6665 (2023): 1446-1451.
That paper is more focused on the general concepts than the implementation, but FWIW the new code is in Julia and in the supp mat, and calls an existing C program called LOSCAR for the forward modelling.
I suspect there's a bit of an Eternal September effect going on as a wider audience ends up here (possibly fleeing the continuing "enshittification" of most all for-profit online fora)
@cbkeller: Though MPI is dominant in HPC by a very large margin, it's definitely not the only game in town. SHMEM is an MPI alternative with a smaller but very dedicated following. UPC, Fortran 2008, UPC++, and Chapel are all alternatives that support inter-node communication without relying on MPI or explicit library communication calls. Chapel has the additional advantage of not imposing the SPMD programming model on the user and supporting asynchronous dynamic tasking.
It's my understanding that Julia aspires to join this group of languages if it is able to do so, which is why the Petaflops announcement was originally enticing to me, and then became somewhat less so once I learned that it was relying on MPI.
The most IDE-ish experience is probably currently the vscode plugin. I haven’t used pycharm specifically for comparison, but I suspect “probably not” as compared to a polished paid IDE in general. There’s progress being made though.
> While the details of CCS provisioning vary in the different versions of the GPL agreements, the general principle is that CCS need to be provided either (a) along with the binary distributions to those who receive, or (b) to those who request pursuant to a written offer for source.
Since the written offer is apparently mandatory [1], does this mean that a potential way forward (if Red Hat intends to not break the GPL) is for Rocky and Alma to make regular written requests for source?
> If you commercially distribute binaries not accompanied with source code, the GPL says you must provide a written offer to distribute the source code later. When users non-commercially redistribute the binaries they received from you, they must pass along a copy of this written offer. This means that people who did not get the binaries directly from you can still receive copies of the source code, along with the written offer.
> The reason we require the offer to be valid for any third party is so that people who receive the binaries indirectly in that way can order the source code from you.
My understanding: Let's say Alma & Rocky purchase one RHEL subscription, and start programmatically downloading Source RPMs (SRPMs). Red Hat finds out. Red Hat says "as per the subscriber agreement, we are unilaterally cancelling your subscription."
Now, let's say Alma & Rocky go back to Red Hat and say "We want the source for these packages we obtained while we had a subscription." I think Red Hat could respond by saying "OK, you last had a subscription on X/X/202X, here are the versions of SRPMs that were in activate at the time your subscription ended. Oh, you want newer SRPMs? Well, too bad, you don't have an active subscription."
Could Red Hat do this? Sure. Would they do this? At this point, probably. Does that go against the letter of the GPLv2? My thinking is no. Does it go against the _spirit_ of the GPLv2? Yes.
I don't think this does violate the spirit of "free as in freedom" GPL.
GPL is pretty straight forward - it sets out to give users of software the freedom to modify and run the software themselves. That's the spirit, and I think Red Hat.
It does violate the spirit of "free as in beer" "open source", however.
> sets out to give users of software the freedom to modify and run the software themselve
No, not just “modify and run”, it's about “modify, run and redistribute without any other restriction than publishing the redistributed code under the same licence”. That's exactly what makes creative common-NC a non-free license by the way.
> Since the written offer is apparently mandatory [1],
It is mandatory if you commercially distribute binaries not accompanied with source code. More precisely, the GPL says you only need to do one of 3a) accompany binaries with the complete corresponding source code 3b) accompany binaries with a written offer valid for any third party 3c) pass over the written offer you received but only if your distribution is noncommercial.
Based on this there are two important points.
First, Red Hat always accompanies binaries that it distributes accompanied with source code, therefore they do not have to provide a written offer. Also note that only the written offer option is valid for any third party, the "accompany binaries with source code" option is not.
Second, it is important that the rights you have according to the GPL start and end with the binaries that you received, they cannot be extended arbitrarily to future releases.
