281–290 of 341 posts
Earlier quoted context omitted.
OIC. Rust doesn't guarantee optimizing tail recursion. How unfortunate for a language that's getting widespread adoption.
Do any widely used languages guarantee tail call optimization? It's a pretty niche feature.
Earlier quoted context omitted.
Neither. They basically see Rust as the future. They want to be able to attract young contributors and to hire young employees who are excited about Rust and who want the safety features. Bear in mind, the average age of the Linux developer is increasing. They also see technical benefits in Rust. And they are increasing test coverage of both the Rust tools and the tools written in C, IIRC. My source is this interview…
In reality, I think it much more about taking more control over parts of the ecosystem - the license change is part of it, but also getting rid of the old stubborn communities and maintainers.
So what is the way forward for Linux to have sandboxi g as strong as Android? Appimage everything? I know it's possible now hacking together things, but I mean by default and integrated.
Earlier quoted context omitted.
It's a stack overflow which means it's using recursion and for historical reasons that don't make sense any more, stacks are teeny tiny on 64-bit Linux - apparently only 8 MB on Linux! I'm not sure why they don't raise it to something reasonable like 4 GB. I guess because they want consistency with 32-bit? Maybe we can finally change it if/when they phase out support for 32-bit Linux. Apparently it might not be that…
8MB is the default per-thread stack size from glibc, also seems to be the default "ulimit" from pam or the kernel, I'm not sure. So for the main/default thread (or if not using threads) the process can use setrlimit() and for threads it can use pthread_attr_setstacksize() to get bigger stacks if it knows it may need them. 8MB is pretty huge though; musl libc is famous for defaulting to much smaller per-thread stack s…
But I don't really buy that for the same reason most programming languages don't limit loops to 8 million iterations (or whatever) by default - it would make catching infinite loop bugs easier!
I say most, because I know of at least one language that did do that - QuakeC! It made lots of sense in that context though.
Earlier quoted context omitted.
> The reason for existence of uutils is ideological, not technical. which ideology? Are people saying that there's an ideology of pushing rust for things without concern for quality? Sincere question, because I'm seeing that on this thread and I wasn't aware that that was a thing beyond the "re-write it in Rust" meme.
> Are people saying that there's an ideology of pushing rust for things without concern for quality? Yes, there is. There are people who genuinely think quality does not matter as log as it is written in Rust as Rust is memory safe.
Is this hyperbolic? Such people are in leadership places?
Earlier quoted context omitted.
Once they have a more permissive license, cui bono?
Businesses. There is a reason all FOSS OS alternatives for embedded systems like Zephyr, NuttX, FreeRTOS, IDF, Arduino,... are not GPL based, while Google has purged Android and ChromeOS from it, with the Linux kernel being the only GPL piece left.
Arduino is "just" repacked gcc in a nutshell, so it is GPL-based.
So what is the way forward for Linux to have sandboxi g as strong as Android? Appimage everything? I know it's possible now hacking together things, but I mean by default and integrated.
Amutable. Building an immutable and image based system which even the installer can't modify, a-la macOS. One systemd patch at a time.
Earlier quoted context omitted.
yeah, this is a bug. And yes, it should be fixed. But I don't think it will affect many users, I mean who has a 32000 -evels deep directory on their system?
> But I don't think it will affect many users, I mean who has a 32000 -evels deep directory on their system? When the GNU coreutils version doesn't have this bug and thus affects zero users, why should I bother with the Rust version?