You can call rm safer manner, but you’ll need to fork and use one of the execl functions directly. That way you don’t have to worry about escaping the path. The old implement would potentially delete unrelated data if the path contained whitespace, and could even execute arbitrary commands, since it essentially runs bash -c "rm -rf $path"
This looks like a colossally bad idea:
if (!strcmp(platform, "windows") && !isSpecificPlatform) {
debugLog("Falling back to rm -rf", 2);
debugLog(strfmt("rm -rf exited with code %d",system(strfmt("rm -rf %s", path))), 3);
}
In addition,
However, their even though their client doesn’t allow vibe coding, it is still written in Python, which itself takes ai contributions.
Per the Makefile, this project is built using GCC. GCC itself accepts AI contributions, provided that the code is “legally insignificant” (meaning less than around 15 lines of code) or is part of test cases: https://gcc.gnu.org/ai-policy.html
They released 3.2.6 on the 10th per the blog post.
Which, given the size and complexity of GIMP, likely means that they were already in the process of wapping it up by the time OP made this post
I meant that OP was quoting themself. I’d be rather surprised if they have anything to do with the GIMP project
I think they are quoting themselves. I’m fairly sure they’ve posted this exact thing before, for other versions of GIMP
This is horrible in my view. All types that implement Deref and/or DerefMut can be called smart pointers, and everything is “thread-safe” in safe Rust.
If I had to call something “Rust’s thread-safe smart pointer”, it would be the actual references &T/&mut T where T: Send + Sync.
Not everything is thread-safe in safe rust; while safe rust prevents you from using thread-unsafe constructs in a threaded context, most types are not thread-safe. That’s why you have both Rc and Arc, since it is not safe to use non-atomic reference counting in a threaded context, but you don’t need the overhead of atomics in a non-threaded context.
Nor are references &T/&mut T where T: Send + Sync considered smart pointers in Rust. Those are just references to something that itself implements the traits required to make that type thread-safe.
See also https://doc.rust-lang.org/stable/book/ch15-00-smart-pointers.html and https://doc.rust-lang.org/std/sync/struct.Arc.html#thread-safety
I guess that the purpose of the one-line summary is to communicate the spirit of the policy. The details that you are asking for, is what constitutes the majority of the the policy document itself. While you could probably summarize the body of the policy in more detail, having multiple lists with different levels of details would likely lead to confusion. So I think that the approach they’ve taken makes sense
In practice, that would require buy-in from the apartment/house association board, since the average resident would be unlikely to care about whether or not the software was open source or owned by the association. Cost would likely be a more important metric for most members, and here a company that serviced multiple associations would likely have an edge, especially since they could also provide general support to the end-users.
If it did get approved by the associations members, then the board would then likely have to hire a third party do carry out the actual development. If you’re (very!) lucky, then one or more members might be willing to do it cheaper than a third party, but that would likely only last for however long they lived in one of the apartments or houses.
I would put this scenario down as possible in theory, but very unlikely to work out in practice. The vast majority of such associations would go with an existing (closed-source) SAS provider, since that would be a lot less work and since it would survive the constant turnover in such an association.
I honestly have an even harder time seeing how it would work out for OSS in general, since most software does not come with an existing organization, nor a community that is as directly invested as residents in an associations. For most projects, the work involved in setting up and managing such an association would greatly exceed the work involved in developing the software itself, which, similarly to the above, most of the users would not be able to contribute to
EDIT: A more plausible scenario for an house/apartment association, would be somebody setting up a company structured as a co-op and then recruiting multiple associations as co-owners/customers. Is that what you had in mind? Though that of course requires that somebody has both the funds and the interest to get it off the ground, which is unlikely to be an existing association
Neither of those terms seem problematic to me; a plain reading would be “mostly” means more than half of the code, and “tolerated” would mean that the ban is not enforced on such projects. Of course, if you are already operating under the assumption that Codeberg is acting in bad faith, then it doesn’t matter what the terms of service says nor how they they might say that they interpret them.
It is, however, not surprising that their terms of service are subject to interpretation. That was already the case before they added these particular terms. For example, the Codeberg TOS already included a prohibition against “content that harms the reputation of Codeberg” before the recent changes. Codeberg simply added projects related to cryptocurrency as an example, when the ban was voted through. It is furthermore the case that most, if not all, terms of service are subject to interpretation. We are talking about documents describing human behavior, not machine code.
If this kind of thing is not acceptable to you, then your only real solution is to self-host
Banning “AI” is too broad and too shortsighted.
They haven’t done that. The actual terms are
You must not share projects that mostly consist of code written by “generative AI”-tools (including services such as Claude, OpenAI Codex). Such projects having an unclear copyright status (see requirements § 2 (1) 1 and § 2 (1) 3) and furthermore have little safeguards to ensure that they do not include harmful code (c.f. § 2 (1) 5).
See also their blog post, where they specifically mentions experiments as “tolerated”:
Side projects and experiments with little resource usage
To add to the last comment, I’d also suggest not mixing logging and business code. That is to say that you should put the
systemcall on its own line, so that it is clear that it’s not just a logging call:if (!strcmp(platform, "windows") && !isSpecificPlatform) { debugLog("Falling back to rm -rf", 2); int result = system(strfmt("rm -rf %s", path)); debugLog(strfmt("rm -rf exited with code %d", result), 3); }It may just be a me problem, but I have a tendency to skim over the logging lines unless I’m intentionally reading code carefully, in which case the system call may get overlooked