sudo-rs is a different project than uutils
The problem is not the conclusion*. The problem is that the method used to reach it is terrible.
As you say, you could look at license popularity on GitHub, and the author should have done something like that, but even those statistics have to be interpreted carefully:
Each data point corresponds to the rank of a license based on the count of unique developers who uploaded code to a repository subject to the terms of that license during a given quarter.
In other words, this measures how many developers are commiting code under each license, and thus is more of a reflection of the popularity of software under each license, rather than the licenses themselves.
Perhaps a more meaningful measure would be how many (unique) repositories are created with each license, since a developer commiting code to a repo does not mean that they favor the license of that repo. I couldn't find numbers for 2025, but amusingly these totals from 2020 suggest that no license is the most popular license, followed by MIT and then Apache
* The majority of my own code is MIT, by a large margin-
Loop labels are rare, but they lead to much simpler/clearer code when you need them. Consider how you would implement this kind of loop in a language without loop variables:
'outer: while (...) {
'inner: while (...) {
if (...) {
// this breaks out of the outer loop, not just the inner loop
break 'outer;
}
}
// some code here
}
In C/C++ you'd need to do something like
bool condition = false;
while (...) {
while (...) {
if (...) {
condition = true;
break;
}
}
if (condition) {
break;
}
// some code here
}
Personally, I wouldn't call it ugly, either, but that's mostly a matter of taste
C++ is even worse, due to templates and the so-called most vexing parse. Initializing with {} mitigated the latter somewhat, but came with its own set of woes
With Rust you safe 1 char, and gain needing to skip a whole line to see what type something is.
Honestly, the Rust way of doing things feels much more natural to me.
You can read it as
- Define a function,
- with the name
getoffmylawn, - that takes a
Lawnargument namedlawn, - and returns a
bool
Whereas the C function is read as
- Do something with a
bool? Could be a variable, could be a function, could be a forward declaration of a function, - whatever it is, it has the name
getoffmylawn, - there's a
(, so all options are still on the table, - ok, that' a function, since it takes a
Lawnargument namedlawn, that returns abool
It’s unfortunate that it has come to this, since BCacheFS seems like a promising filesystem, but it is also wholly unsurprising: Kent Overstreet seemingly has an knack for driving away people who try to work with him
For example, the dd problem that prompted all this noise is that uutils was enforcing the full block parameter in slow pipe writes while GNU was not.
So, now uutils matches GNU and the “bug” is gone.
No, the issue was a genuine bug:
The fullblock option is an input flag (iflag=fullblock) to ensure that dd will always read a full block's worth of data before writing it. Its absence means that dd only performs count reads and hence might read less than blocksize x count worth of data. That is according to the documentation for every other implementation I could find, with uutils currently lacking documentation, and there is nothing to suggest that dd might not write the data that it did read without fullblock.
Until recently it was also an extension to the POSIX standard, with none of tools that I am aware of behaving like uutils, but as of POSIX.1-2024 standard the option is described as follows (source):
iflags=fullblock
Perform as many reads as required to reach the full input block size or end of file, rather than acting on partial reads. If this operand is in effect, then the count= operand refers to the number of full input blocks rather than reads. The behavior is unspecified if iflags=fullblock is requested alongside the sync, block, or unblock conversions.
I can also not conceive of a situation in which you would want a program like dd to silent drop data in the middle of a stream, certainly not as the default behavior, so conditioning writes on this flag didn't make any sense in the first place
Besides this change not breaking user space, the "don't break user space" rule has never meant that the kernel cannot drop support for file systems, devices, or even entire architectures
I did enjoy this comment:
C code with a test suite that is run through valgrind is more trustworthy than any Rust app written by some confused n00b who thinks that writing it in Rust was actually a competitive advantage. The C tooling for profiling and checking for memory errors is the best in the business, nothing else like it.
In other words, a small subset of C code is more trustworthy than Rust code written by "some confused n00b". Which I would argue is quite the feather in Rust's cap
IMO, variables being const/immutable by default is just good practice codified in the language and says nothing about Rust being "functional-first":
Most variables are only written once, and then read one or more times, especially so when you remove the need for manually updated loop counters. Because of that, it results in less noisy/more readable code when you only need to mark the subset of variables are going to be updated later, rather than the inverse. Moreover, when variables are immutable by default, you cannot forget to mark them appropriately, unlike when they are mutable by default
It is normal usage. Though personally I'd probably make another "main" function, to avoid declaring a bunch of global variables
fruitcantfly
joined 2 years ago
He has made a large number of questionable comments, including the argument that the solution to human trafficking includes legalizing child prostitution:
https://www.stallman.org/archives/2015-mar-jun.html#27_April_2015_(Human_Traffickting_Act)