Uutils 0.0.24 Advances Rust-Written Coreutils Implementation

[gavron]

The Kernel drivers, are GPL. These "drivers" are mostly memory management code and command processing to the card. The MESA drivers *ARE* MIT licensed, since MESA ITSELF is MIT licensed. So nobody steals anything from anyone in this case.

GPL is only restrcitive to those people that wants to close the code and get money from it. From the rest of the world is still the best decision, if you care about your work. If you really don't care, MIT or APACHE are really good licensing: "I don't owe nothing to you , you don't owe nothing to me, use to whatever you want". For experience, closed code is quite close to crap nowadays, since there are dealines to the work, and noboady cares about quality on closed systems, just the bare minimum to get things "work". (Granted, there's always some open projects that do the same, but it's not so obvious until the next code crash)

Now the problem with this version of Coreutils, is that takes GPL code and gets rewritten in Rust, and since it's rewritten the guy doing the port changes the license. That's quite unethical (If you do a port of a closed code in another language, and then change the license and distribute it, do you really think you can get away with it??), but in the end, Coders rarely do ethics things in Real Life. They do for the money or the fun, or both. And of course, this attracts the attention of all kind of vermin out there, but then again, their choice.

And about the BSD being robbed, sorry, is not. They offer the code for free, use whatever you want, close it if you want, just mention in some file that you use the code. That's all. and that's not stealing.

But if you talk about porting GPL code to another language, and relicensing it, that's a grey area, and only a court can judge in that case. And that's will open a really nasty can of worms in case somevbody sues.

Pretty much anything you said about licensing isn't true, and "only a court can judge" means "come sue me" not "I'm doing the legal thing."

Whatever helps you sleep at night, sweetheart.

Steal code, get caught, have no deep pockets, get stopped.

[oleid]

I just built both according to the instructions provided by each project. In terms of binary weight, uutils (12,810,970 bytes) is actually about half the size of gnu coreutils (29,224,332 bytes).

Now that's funny, thanks for checking.

I assume the difference is largely due to the fact that uutils compiles down to a single binary, cutting way back on redundant code.

So they are not using any shared libraries?

[jstoik]

Now that's funny, thanks for checking.

Yeah, I was surprised! Now had I gone to the trouble of compiling each uutils app individually I'm sure it would have been a very different story…

So they are not using any shared libraries?

I wasn't counting libraries earlier — just the executables produced — but both are pretty light on shared links when built with the default flags (on Debian Bookworm), assuming ldd can be trusted:

Uutils

linux-vdso.so.1
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6
/lib64/ld-linux-x86-64.so.2​

The Various GNU coreutils (deduped)

linux-vdso.so.1
libacl.so.1 => /lib/x86_64-linux-gnu/libacl.so.1
libattr.so.1 => /lib/x86_64-linux-gnu/libattr.so.1
libcap.so.2 => /lib/x86_64-linux-gnu/libcap.so.2
libcrypto.so.3 => /lib/x86_64-linux-gnu/libcrypto.so.3
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6
libpcre2-8.so.0 => /lib/x86_64-linux-gnu/libpcre2-8.so.0
libselinux.so.1 => /lib/x86_64-linux-gnu/libselinux.so.1
/lib64/ld-linux-x86-64.so.2​

[Quackdoc]

Yeah, I was surprised! Now had I gone to the trouble of compiling each uutils app individually I'm sure it would have been a very different story…

using the make file instead of cargo to build it will build the individual executables, not sure how linked they are, you can also build them individually using cargo with cargo build -p UTIL1 -p UTIL2. you can generate this list easily with a simple script to read from the makefile

[dlq84]

Oh legalese, great! Are you happy that the BSD community works for free and the big corps make billions selling their software?

Try harder

[stargeizer]

I haven't kept up on uutils. Do you have proof that they're reading the GNU coreutils source code, as opposed to just using the manpages and test suite to define the interface that clean-room'd code needs to implement?

Ok, my bad. I overlooked the warning at Documentation.md in the source code. So they are doing things the "WINE" way. Good for them.

No, they're not. The AMDGPU driver is MIT...

Again, my bad. I'm talking about AMDKFD kernel driver, which i believe is required by modern AMD GPU's nowadays for command submission to the hardware and HSA compilance. (and is dual licensed)

[pabloski]

Everything you say is irrelevant because you fail to acknowledge the NOT GPL that's in the kernel

Why are you deflecting? I am not talking about the Linux kernel, but about permissive licenses. You say that AMD can contribute code through its MIT licensed projects, but I am saying that the PS4 drivers are MUCH better than the ones found in Linux/FreeBSD/etc... And the big problem is that Orbis OS IS FREEBSD!!! So why the driver used by Sony hasn't been upstreamed into FreeBSD? Why is FreeBSD forced to port the Linux driver? Obvsiouly because they ( AMD and Sony ) can avoid adding the code to FreeBSD! And this is the big problem with permissive licenses. With GPL the big corp is forced to release the code!

I think what's in the kernel is just as important as the rest of the graphics stack....and Mesa is MIT, too.

Yes it is. And guess what? Not a single bit of the PS4/PS5 code has gone into the FreeBSD kernel/userland and/or Mesa!!!!

[skeevy420]

Why are you deflecting? I am not talking about the Linux kernel, but about permissive licenses. You say that AMD can contribute code through its MIT licensed projects, but I am saying that the PS4 drivers are MUCH better than the ones found in Linux/FreeBSD/etc... And the big problem is that Orbis OS IS FREEBSD!!! So why the driver used by Sony hasn't been upstreamed into FreeBSD? Why is FreeBSD forced to port the Linux driver? Obvsiouly because they ( AMD and Sony ) can avoid adding the code to FreeBSD! And this is the big problem with permissive licenses. With GPL the big corp is forced to release the code!

Yes it is. And guess what? Not a single bit of the PS4/PS5 code has gone into the FreeBSD kernel/userland and/or Mesa!!!!

I'm not deflecting, I just don't give a shit that Sony doesn't share back because they're following the rules that AMD put forward when AMD released their open source graphics stack. While it'd be nice if Sony would share back, at the same time it doesn't matter. If this really does bother you, raise a stink over on their Twitter or Facebook. Try to publicly shame them into doing what you think is the right thing to do, both Sony for not sharing back and AMD for not using the right kind of free; American Free versus European Free.

Don't argue with someone whose position is simply, "I don't give a shit because they're following all the rules." Is my view a bit NAZI? Yeah, but we're not talking about following final solutions, we're talking about code that's as freely licensed.

I shouldn't have to say this, but quit using the PS4 as an example of a good product that you'd want the code from. It has the shittiest, worst responding, buggiest UI of any game console I've ever used. You can BSOD a PS4 just by viewing game trailers in the PS Store. Scroll too fast? You just crashed a PS4. It might play some games OK, but the product as a whole sucks and it does not inspire confidence in what the Sony devs would contribute to Linux, Mesa, or anywhere else.

If you wanna use the PS5 as an example, sure, I've never managed to make one BSOD from a game trailer or browsing the game store as well as the UI is 10x more reactive and responsive than the 4. Granted, PS4 to 5 was Excavator and GCN 1.1 to Zen 2 and RDNA 2: A massive hardware upgrade that's just as likely to fix their unresponsive UI as their programmers

So not only does AMD have to release open source graphics drivers that are compatible with Linux and Windows, you also want them to release them for FreeBSD? After FreeBSD is done are they supposed to hook up ReactOS, Haiku, or NetBSD with AMDGPU?

At least AMD releases a open source cross platform driver that OS devs are able to adopt and work with so when things like AMDVLK end up not existing or sucking, alternatives like RADV can exist in their place.

[skeevy420]

Again, my bad. I'm talking about AMDKFD kernel driver, which i believe is required by modern AMD GPU's nowadays for command submission to the hardware and HSA compilance. (and is dual licensed)

// SPDX-License-Identifier: GPL-2.0 OR MIT
/*
 * Copyright 2016-2022 Advanced Micro Devices, Inc.
 *
 * Permission is hereby granted, free of charge, to any person obtaining a
 * copy of this software and associated documentation files (the "Software"),
 * to deal in the Software without restriction, including without limitation
 * the rights to use, copy, modify, merge, publish, distribute, sublicense,
 * and/or sell copies of the Software, and to permit persons to whom the
 * Software is furnished to do so, subject to the following conditions:
 *
 * The above copyright notice and this permission notice shall be included in
 * all copies or substantial portions of the Software.
 *
 * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
 * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
 * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
 * THE COPYRIGHT HOLDER(S) OR AUTHOR(S) BE LIABLE FOR ANY CLAIM, DAMAGES OR
 * OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,
 * ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
 * OTHER DEALINGS IN THE SOFTWARE.
 */​

That's from AMDKFD. The key thing in there is GPL-2.0 OR MIT in the first line. That OR means that a company can yank AMDKFD out of the kernel and only abide by the MIT part of it; completely ignore that the GPL 2.0 even exists. If it was GPL-2.0 AND MIT then it'd do what you are assuming it is doing where they'd have to also follow the GPL 2.0's rules, too. If you want to know more....

[kloczek]

I just built both according to the instructions provided by each project. In terms of binary weight, uutils (12,810,970 bytes) is actually about half the size of gnu coreutils (29,224,332 bytes).

I assume the difference is largely due to the fact that uutils compiles down to a single binary, cutting way back on redundant code.

Just checked and in my case coreutils package is 17155657 however size of the /usr/bin is only 5867368.
BTW: coreutils allows build everything as single binary and set of symliks as well