

Tbh it’s linked to a ton of things (lots of cancers), so it’d be a pretty big deal in general if they’re able to scale it into something widely usable.


Tbh it’s linked to a ton of things (lots of cancers), so it’d be a pretty big deal in general if they’re able to scale it into something widely usable.


If you weren’t implying that people from those areas aren’t allowed to provide opinions because presumably in this context they’d be slanted against China, then your post had absolutely no relevance. So, why did you bother posting it?


This is kind of proving his point tbh.


I think this is true for all games that access the internet. However, it seems an especially large number of Chinese games that make it to the West require an internet connection to function. Sometimes it makes sense (multiplayer mechanics, gacha, etc.), sometimes it doesn’t at all (some relatively popular single-player RPGs with no online play require a connection just to make a save file, for example).
This is just to say I understand people being concerned if all they see are these Chinese online-required games everywhere when they can also find some random completely offline game made in America, Europe, Japan, etc. just as easily (or even a game with an optional online mode that can be disabled without the game breaking).


Shouldn’t my obvious willingness to engage with people about this topic serve as some sort of indicator that I’m serious and not “drive by”?
Shouldn’t the fact that I’m not being rude or crass like the other poster you brought up (to achieve rhetorical ends I’m not exactly clear on!) be an indicator that my input should be taken seriously?
Given that you replied quite positively to the dude who wrote about the maintainers being “cucks” and keep talking about the “perverse incentives of rust,” the answer is no.
I’m going to block you now, byebye.


The requirements are not at all strict. Submit even one bug report or issue, or do literally anything positive rather than show up for the first time and whine about the management of the project or whatever out of nowhere and then maybe people will take your opinion more seriously.
The threads are indeed filled with people like you given that in a number of your posts you went and complained about Rust as a whole. This is ignoring that the other highly upvoted (license-related) top-level post in this very thread (before it got deleted by mods) called the project maintainers cucks and so on.
Anyway, now I’m actually done.


You don’t need to be a programmer to contribute. That’s just your bias. Anyway, I’m done with this.


There’s a caveat that will apply in the future, but is completely meaningless right now, in that people born after some day in December 2025 need to have a “meaningful connection” to Canada or something, so like living in Canada for a certain amount of time. But for nearly everyone currently alive there’s no restrictions other than having a Canadian ancestor at some point in your direct line.


In a recent analysis, Adam Harvey found that among the 999 most popular crates on crates.io, around 17% contained code that do not match their code repository.
17%!
Let me rephrase this, 17% of the most popular Rust packages contain code that virtually nobody knows what it does (I can’t imagine about the long tail which receives less attention).
Given that he lied about the results of the analysis he is using to prove his point, I find it hard to trust anything in this article.
In the analysis, Harvey said only 8 repositories did not match their upstream repos. The other problems were issues like not including the VCS info, squashing history, etc.
EDIT: Also, I just noticed that he called it a “recent” analysis. It’s roughly a two year old analysis. I expect things have improved a bit since then, especially since part of the problem was packaging using older versions of Cargo.


I’m actually looking into this right now. Other than tracking down all the birth certificates and stuff, it seems pretty straightforward.
The bill is C-3, since the article didn’t seem to mention it.


It’s literally as far back as possible, as long as you can prove the chain of descent through birth certificates and marriage records and so on.
The bill is C-3, since apparently the article didn’t mention it.


Lol I guess everyone who uses Linux and has contributed absolutely nothing to the kernel should be taken quite seriously when they drive-by on the kernel mailing list and start complaining about the management of the project.


And that’s only 30% lol


The “completely random person with no relevance to the project” specifically in reference to uutils-coreutils, but I will stand on the assessment for every other rust/mit rewrite of a c/gpl package, is in every instance a contributor, maintainer or user of the gpl package it’s based on and therefore neither random or irrelevant.
There are constantly random people complaining who literally have never been involved with GNU coreutils (or frankly any GNU project at all) or uutils. If all the people complaining worked on GNU projects, they’d have a truly astounding supply of contributors.
They are always people saying “hey, we wanna help but your license is standing in the way, why not change it so we can more easily work together?” Or “this project is great but the license is too permissive, since the thing it’s based on got by great with gpl, couldn’t the license be changed to gpl?”
People say this in the other direction as well.
Forking over license would be counterproductive and silly when the thing in question is a reimplementation of a gpl package. Literally just use the license that the original work had!
From my perspective the people asking rust/MIT rewrites of gpl/c stuff to go back to gpl are being perfectly reasonable and have every possible definition of standing to make that request and always get treated as interlopers.
I suppose you complain about this when the BSD folks reimplement functionality present in Linux or other GPL projects. To put it bluntly, uutils isn’t GNU coreutils. It’s an implementation of the utilities trying to get as close as possible to the same functionality, but it will likely never truly “replace” GNU coreutils (as long as the latter is still being developed, at least).
We havent even touched on the violation of the gpl aspect, where no programmer and certainly not one using a llm could be reasonably thought to be ignorant of the gpl coreutils inner workings and doing a clean room implementation which is what is legally required to not be considered a derivative work!
This is completely ridiculous. How does “no programmer … could be reasonably thought to be ignorant of the gpl coreutils inner workings” even make sense to you? Under this thought process, it’s impossible to make a clean room implementation at all because you cannot be “ignorant of the [XYZ project] inner workings” if you implement the same functionality. I suppose all the BSDs are in violation of the GPL since they have implemented roughly the same functionality. Not to mention Toybox.


Do you make your learning projects that you don’t really care about GPL? I don’t.
The reason people don’t want to GPL stuff like this is it’s bothersome to change it and get support from the existing contributors who are actually, you know, contributing to the project. The “get your politics out of my code” thing (for the license) is at this point because some completely random person who has no relevance to the project coming by, screaming about the GPL, and subsequently spawning a massive MIT vs. GPL debate/mudslinging contest is incredibly annoying. I’d frankly be tempted to keep it non-GPL just to spite anyone who does that. It’s a different thing if people who are actually relevant to the project consider doing it.
EDIT: I noticed this is a different subthread than I was thinking it was, so for context the project was started as a single person’s way to learn Rust using relatively easy to implement programs (with easy to access docs). Also, elsewhere someone mentioned forking. In that vein, I largely think this entire discussion is completely unserious because there has been a over a decade for someone to fork it in one of the drive-by license complaints, or even through complaints like here, yet no one has done anything.


A significant number are slight differences from GNU behavior that likely wouldn’t impact users or just random miscellaneous project tasks like “this is inefficient” or “clean up this thing.” Not saying there aren’t problems to be addressed, just that the number looks more concerning than it actually is. Wouldn’t be surprised if some are outdated as well.


Being able to take someone else’s code used as a learning exercise for your own learning without worrying about it being GPL’d is quite useful. You seem to be arguing permissive licenses should never be used, which I think is ridiculous. A project meant to just learn about XYZ language/framework/whatever by implementing “simple” tasks is one of the most basic examples of a project that should be under a permissive license.
The only thing that could realistically be done is to license all changes going forward as GPL. If someone wanted to fork the project to do something like that, they could. But of course no one will bother, because the people who are terminally rabid online about this project not being under the GPL contribute to neither this project nor GNU coreutils.
It is not a major issue. It’s only really an “issue” at all because people who don’t contribute and likely would never contribute anyway constantly complain about it. I will state this again: there are multiple already existing implementations of the coreutils programs, so there is practically nothing keeping companies tied to it. There is little actual benefit to the coreutils programs in particular being under the GPL.


Because it was started as a project to learn Rust by one dude.
Also, that was back when Rust had bad documentation (at least a couple years before 1.0), so by far the easiest way to learn was by making something like this and looking through other existing projects like the compiler or Servo.


That’s great, except they could already just use a permissively licensed implementation. This is in fact what a lot of companies already do. For instance, Android uses Toybox, macOS uses utilities originally ripped from NetBSD (mostly), etc.
Generally, a lot of companies also don’t contribute back fixes upstream. They’ll often just dump the code in some hidden away corner of their site as a giant source blob.
For something like coreutils, where a significant change is sort of unlikely in the first place, thinking the GPL makes a difference is bizarre to me.
What exactly do you mean by “permissions” here? It sounds like you’re just talking about basic Unix-style permissions. Also, what do you mean by “only the one based on BSD?”
Unless you’re talking about Mac OS 9 and earlier (like more than 20 years old), all their OSes have permissions and are based on BSD at this point.
Standard Unix permissions also aren’t gonna save you when you run an exploitable program as your home user and it can then access everything in your home directory (in other words, pretty much all of your important files for most users).