> Safety controls may be lost – models trained on Claude's Outputs won't have our safety measures, potentially leading to harmful or dangerous AI systems. We also have no visibility into deployment, meaning we cannot monitor how these distilled models are used or prevent misuse.
So was that why your models caused three real-world security incidents?
The dilemma is hypothetical (because we now know the exact precision requirement for those functions over all 64-bit doubles) but let's assume that we don't know that and also we happen to use decimals instead. What if, some f(x) is known to be, say, 123.4999...9997 with 1,000 fractional digits? You have to calculate at least 1,000 decimal digits of f(x) in order to correctly round, before that we only know it's between 123.4999...999 and 123.5000...001. There seems no mathematical theory that specially prevents this annoying possibility, hence the dilemma.
> CORE-MATH Mission: provide on-the-shelf high performance open-source mathematical functions with correct rounding that can be integrated into current mathematical libraries (GNU libc, Intel Math Library, AMD Libm, Newlib, OpenLibm, Musl, Apple Libm, llvm-libc, Microsoft libm, CUDA libm, ROCm)
That's beautiful. Here's the Git repo with implementation.
Common sense testing only tells about the presence of common sense, that's it. It is clear from recent events that LLMs do definitely possess some sort of intelligence even though it might have been polarized to certain domains.
All of which have been challenged though. As the stake is high, any such reason (for or against LLMs, to be fair) has to be backed with Wikipedia-level evidences at the very least.
Many influential F/OSS projects started with a small number of users (and contributors), and will continue to do so for the foreseeable future. Codeberg effectively says that it only welcome mature enough projects that it feels worthy to host, and that's selfish. That's not a direct problem by itself but still a good reason to get criticized.
Do yourself a favor and look at the actual HN thread [1] when Codeberg was widely discussed for the first time. It is crystal clear that Codeberg was seen as a direct alternative to GitHub at that time, and even the founder's quoted statement gave a nod to that I think?
> [...] But as developers of free software we fell into a trap – we poured invaluable source code, documentation and last not least a huge and steady stream of data about our personalities, interests and social networks into proprietary platforms. [...]
(And no one knew Codeberg had a right to determine which source code and documentation is invaluable.)
I just did, in fact I vaguely remembered it from back then, and after reading the announcement blog post and the quote, I still think that anyone who expected Codeberg to replace their private use of GitHub was fantasizing. They already stated their mission is to be a community-led forge for FOSS.
Maybe we could blame them for having lowered their ambitions around "lesser" FOSS, but then again the economics are changing.
Even looking at the comments from that thread and the Codeberg page at that time in archive.org, I don't really see much that points to it as a proper GitHub alternative, other than the editorialized (I think) post title.
Which I think might be the cause of confusion here. I suspect that there was never an official statement (or intention) of Codeberg being a full GitHub replacement, but since a lot of people recommended it as an alternative to GitHub, it started to be seen that way.
I'm happy to be proven wrong, though, as I'm quite confused about the outrage about Codeberg's decision. At least in my mind, Codeberg was already a highly opinionated forge (with the private repo ban and all), so this was not much of a surprise.
Free services owe no one, anything. If you are joining a community, be respectful.
If you're not, and you get banned, that sucks. If it causes a whole category of your peers to be banned that sucks too.
…but its a bit rich to say, oh yeah, the promises you made before LLMs were a thing didn't include a note saying “except if you spam AI generated code”.
Come on.
They dont owe anyone anything.
Certainly not for some comment from ten years ago.
This could entirely legitimately be a case of “was this decision made the right way according to their own decision making process?” … but “is it ok for then to have made this decision?”
Yes. Its fine. It’s their platform. They can do whatever they want.
The OP said the Mandela effect [1] which is definitely about the past event. Anyhow, I'm okay with Codeberg's decision (I'm not even its stakeholder, so what can I say about that anyway) but it has to be honest about the intent. If its definition of "F/OSS" has changed, do say so.
I think an even better advice is that everyone should know array programming, because you generally need that mindset for SIMD optimizations as (packed) SIMD-specific techniques are surprisingly rare. And array programming gives you a generally performant code even without SIMD because it is much easier to auto-vectorize.
I'm no fan of closed-source languages, and lord knows MATLAB has its warts. But I can't deny that it was pretty seamless to write efficient vectorised code for numerical simulations at uni. I don't have much experience with it, but my understanding is that Julia is the closest thing to a more modern and expressive language that has similar vectorisation capabilities.
I learned R for statistical programming at uni, where there was less emphasis on vectorised computation, so it didn't jump to mind, but yes! I've never quite felt like numpy 'clicked' for me in the same way, though. It always felt a bit bolted on, which I suppose it is, as a library (though @ operator overloading etc makes things somewhat nicer now).
Array programming where we compare first and look for the first failure later will not help much here if runs are short because by itself it doesn't give you early termination and you may spend a lot of time on wasted comparisons.
Actually yes, the malloc/free API (inherited from the ALLOCATE and FREE statements of PL/I) is too simple.
The metadata that malloc always attaches to the allocated memory would normally be useful for the user (i.e. having access to values like the currently allocated size and the total size of the allocation).
Very frequently, the user must duplicate inside the allocated memory the same information that already exists in the metadata, wasting memory. Also time may be wasted with requests for reallocation, instead of just adjusting the currently allocated size, when this is sufficient.
With a better API, the metadata would have been visible for the user. Being hidden from the user is not a protection in a language like C, where using pointer arithmetic can trash any memory location. Being exposed as non-mutable would have been a better protection.
Moreover, a better metadata structure for malloc should have always included a reference count, to be handled automatically by the compiler, and the malloc/free functions should have been invoked only implicitly, never explicitly.
To play devil's advocate, the problem with exposing more info is you limit the allocator design space.
1) If the app knew about and could use the additional underlying capacity, memory checkers wouldn't be able to find small overflows
2) Calling realloc instead of knowing existing capacity doesn't really provide better performance, at least not asymptotically.
3) If you need to know the requested allocation size, usually its for a dynamic array. Constantly requesting the size from the allocator would often have horrible performance if the size wasn't stored in adjacent metadata, but instead required a lookup operation, as is the case with hardened allocators. In practice hardened allocators probably wouldn't be a thing, or alternatively it would be idiomatic to store the size separately anyhow.
4) Reference counts would impose significant space and layout limitations despite most allocations never needing it.
There's another group who would argue the allocator should require passing the size and alignment to the free function, so allocators can be optimized better. Most of the time this is known statically. I think C2y will add APIs like this, though there's also a proposal to standardize an interface to query allocation capacity. Altogether I wouldn't be surprised if someday people appreciated the balance struck by malloc/free/realloc, especially as a minimal interface for overlaying application-specific allocators or injecting instrumentation. It has a certain elegance, in the sense of nothing left to remove.
Yes, Drew did a much better job managing this, and his reasoning was more excusable (people were using the build system to mine crypto and eating up resources). I still don’t like it, but I get it, and at least it was handled professionally.
> Safety controls may be lost – models trained on Claude's Outputs won't have our safety measures, potentially leading to harmful or dangerous AI systems. We also have no visibility into deployment, meaning we cannot monitor how these distilled models are used or prevent misuse.
So was that why your models caused three real-world security incidents?