The Case for Rust (in the base system)

cracauer@ said:
I want to pick up the current fight going on in the Linux community about Rust in the kernel.
Click to expand...
Why?!
Click to expand...
Is it not the same like the fight about systemD(estroyer), Pulseaudio, and Pipewire, XWayland which just does not work especially on high-end GPUs like Nvidia ?
Is Xwayland not especially Xorg on Wayland?
So, why even bother?

I am tired of reading, Nvidia is at fault, or the Xwayland team is....
Red hat is red hat, and I really disrespect them and the whole distribution maintainer to adopt SystemD(estroyer).
The unix philosophy actually has some truth behind it.
One part, a function or a library, should reflect its purpose, and one function should do one thing, and do it well....
You can have pure functions, or not, but atleast they should be independent, right?

Congratulations to harry poettering for inventing destroyware, with the comment "my Linux should work like that.
What about other people ?
What about the people who build on systemD but got theiry system destroyed due to systemD developers carelessnes wiping out the home paritition, because it nowadays count as a temp directory?
Well, for me this are new news.
And what do the developer say, read the manual.
Ok, I read the manual, and wanted to clear tmp directorys.
Is it still my fault, that the devs do not mention being /home a temp directory?
Are tmp dirs not directorys mounted in RAM?

First point: Linux is Linus property, and his alone... (I believed that, and how wrong I was with naive 25 or 26 years.)
Mimicking Unix and calling it Linux is just hilarious. Congratulations to Linus Torvalds copying a system and calling it its own. What did he add, to make Unix to Unix lvl2 or lvl3 which stands out from *BSD ?
A mess with harry poetterings magical pulsemagic?
I recall the unix philosophy is to make "one thing and do it well", is it not?
So why does harry poettering degrade Linux, and allow cringe systemD(egrador) even more in the system?
His kind of view, he says?
What kind of view, being a doctor magical somewhat does not give him the right to cringe Linus work.

Everyday I just get news about how linux that, or linux this, or Micro$$$oft likes Linux....... Who cares ?...

Second
I gave up fighting for things, I did it once, and the people I needed that time just did not care for me anymore.
At that point I just realized the important point "do what you want to do", and I do what I want to do.
If something does not match my needs, I will search an alternative.

Linux just got everything what made me go away from it.
 
bakul said:
In contrast to Rust or Go, the V language has done a pretty decent job of support for interfacing to C. See https://docs.vlang.io/v-and-c.html
Click to expand...
Interesting. But it seems NOT YET to be 1.0, which is stated to be "feature frozen" in a decade.
If their (disclosed) intentions are achieved and become 1.0, with the architecture "build into C" is kept, it could be good (better than current form of Rust) candidate. (Not dug into deep enough, so not sure it could be considered "memory safe" language by US gov [not current unsane one, but after becoming sane] and so on or not.)
 
Screw it. We're spending far too much time worrying about what Linux is doing and less time about what FreeBSD is doing. If Linux wasn't stirring up their usual stink about things, no one would give a rat's ass.

There's no reason for us to care. So why are we caring? Cause Linux is spinning themselves around about it? Yes! And no other reason.

Yeah, yeah, the government wants us all to use Rust for safety. They also want us to use Go and a couple of other languages but I don't see everyone here screaming about using them for their work.

One of the FreeBSD devs gives a list of programs that should be rewritten in Rust. One he states "can't be written in C"! How stupid of a statement can you make more than that?!

Elsewhere I read that, perhaps, the reason Linux won't make a call on Rust usage is cause he can't offend the corporate sponsors who have their teats feeding off government funding. I would not be surprised.

I'm a C programmer and proud of it.
 
cracauer@ said:
Keep in mind that OSS and ALSA in Linux do not have an in-kernel mixer like FreeBSD does. They only allow one client at a time - which most people choose to be a sound server out of necessity. FreeBSD users get away without that.

As for sound server stacking, due to the aforementioned problem you cannot have - say jack and pusleaudio directly on the same device. So you stack pulseaudio on top of jack, which interfaces to ALSA or OSS. I do the same thing on FreeBSD, BTW.
Click to expand...
I do not know about OSS in Linux, since I wanted to set it up once, but did not get it to work as it is, or was a an interface to ALSA ?

As for ALSA, I know it has a software mixer available, cannot recall the name right now, but I managed to get it to work with multiple sound inputs from different sources, for example firefox, and audio player.
 
astyle said:
Dunno, I just don't wanna spend my time trying to research this sound system, that sound system, features, drawbacks, and what not. For me, it's easier to just turn everything on, and NOT spend hours trying to connect the dots between lack of ALSA support and Firefox not working right. Besides, those sound systems compile fine, they don't need updates, they don't take up a truckload of disk space or CPU power... If one system is not working quite right, that's OK, I want Firefox to move on to the next one and not bother me.

If Firefox cannot move from ALSA to sndio (simply because it was compiled with support for one but not the other), and that starts causing CPU spikes, then yeah, I got a problem on my hands, especially one that could be avoided if FF were compiled with support for both.
Click to expand...
I managed to get ALSA to work with Firefox just fine back then when I was using Arch Linux.
It just needed apulse to be installed.

Another thing with different sound systems is, you need to set up every sound system to your liking, if you care about sound quality, etc.
That can become very tedious, but once set up correctly, you can switch easily between them, I guess.
 
astyle said:
When I compile ports, I make sure to turn on support for any and all sound systems (OSS, ALSA, Pipewire, Jack, PortAudio, sndio, you name it). Never had a problem with sound as a result. If I install something that is supposed to make sound, then making sound is NOT a problem, even if it only supports a limited number of Open Source sound systems.
Click to expand...
I take the exact opposite approach and turn off everything except OSS. I did have trouble with sound in Firefox once, but it was an easy fix.

drhowarddrfine said:
Elsewhere I read that, perhaps, the reason Linux won't make a call on Rust usage is cause he can't offend the corporate sponsors who have their teats feeding off government funding. I would not be surprised.
Click to expand...
I think most people don't know just how much corporate politics affect Linux development. It's the downside of having a lot of programmers on corporate payrolls working on your project.
 
Jose said:
I take the exact opposite approach and turn off everything except OSS. I did have trouble with sound in Firefox once, but it was an easy fix.
Click to expand...
I do not know about firefox, but librewolf has OSS enabled by default.

Jose said:
I take the exact opposite approach and turn off everything except OSS. I did have trouble with sound in Firefox once, but it was an easy fix.


I think most people don't know just how much corporate politics affect Linux development. It's the downside of having a lot of programmers on corporate payrolls working on your project.
Click to expand...
Corporates can for sure contribute/commit to a project, but it is not that Linux is indebted to them so, it does not make any sense to bow down to their claims.
The corporations with paid programmers need Linux or else it would not make any sense to invest into it.
 
LillieNB said:
Corporates can for sure contribute/commit to a project, but it is not that Linux is indebted to them so, it does not make any sense to bow down to their claims.
The corporations with paid programmers need Linux or else it would not make any sense to invest into it.
Click to expand...

The problem is that all these employees need completed projects for their next employee review. You can't say "it is good as it is, we should leave it alone" in that situation.

That is much in contrast to volunteers who just go hack on something else when one thing is working. Generally of course.
 
drhowarddrfine said:
Elsewhere I read that, perhaps, the reason Linux won't make a call on Rust usage is cause he can't offend the corporate sponsors who have their teats feeding off government funding. I would not be surprised.
Click to expand...
Jose said:
I think most people don't know just how much corporate politics affect Linux development. It's the downside of having a lot of programmers on corporate payrolls working on your project.
Click to expand...
Nothing of the sort. I recently came across a Phoronix article that published an LKML email of what Linus himself had to say. And it looks like a simple matter of API maintenance.

It was a question of whose job it is to maintain the APIs -
  • Is it a responsibility of the C programmers to maintain an API for Rust devs to use? or
  • Ist it a responsibility of the Rust programmers to maintain an API that can be used to call C subroutines?
It sounds like the C programmers were not fans of Rust, and therefore did not want to be saddled with maintaining an API to make things a bit easier for Rust devs.

Which is actually just fine, Rust programmers would just end up maintaining their own APIs to call C subroutines if need be. Exactly why? Leaving API maintenance to somebody else means you're at their mercy when the other dev introduces breaking changes.

Bone of contention seems to have come over understanding the direction of the API call. Is it gonna be a Rust program calling a C subroutine or the other way around? It's not out of question for a C program to need to call a hardware driver that is written in Rust.

C subroutines are callable from lots of other languages. It's usually the other languages that maintain their own C API anyway. As an example, one can write a Java program that mounts a USB stick under UNIX. In this case, it would be a Java program calling a C subroutine to do the actual mounting.

C does have an API to call a program that was written in another language - and it's usually enough to call nearly anything (I'm using a Google AI-generated code to show how to call /usr/bin/awk as an example):
Code: 
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <sys/wait.h>

int main() {
    pid_t pid;
    int status;

    pid = fork();

    if (pid == -1) {
        perror("fork");
        exit(EXIT_FAILURE);
    } else if (pid == 0) {
        // Child process
        execl("/usr/bin/awk", "awk", "{print $1}", "/etc/passwd", (char *)NULL);
        perror("execl"); // This line will only be reached if execl fails
        exit(EXIT_FAILURE);
    } else {
        // Parent process
        if (waitpid(pid, &status, 0) == -1) {
            perror("waitpid");
            exit(EXIT_FAILURE);
        }

        if (WIFEXITED(status)) {
            printf("Child process exited with status %d\n", WEXITSTATUS(status));
        } else if (WIFSIGNALED(status)) {
            printf("Child process terminated by signal %d\n", WTERMSIG(status));
        }
    }

    return 0;
}

In related news, a Linux kernel dev was making a case for including Rust in Linux kernel... And it made me realize something. Rank-and-file users like us can make proclamations about about how that is nonsense that is driven by money and corporate politics. But in reality, we're quite uninformed.

GKH does speak from a position of credible expertise. The Phoronix article only mentioned that a lot of the kernel bugs are corner cases that are difficult to deal with in C, but would be completely gone if the same module were written in Rust.
Straight quote from the LKML post:
The majority of bugs (quantity, not quality/severity) we have are due to
the stupid little corner cases in C that are totally gone in Rust.
Click to expand...
 
Yeah, given all the attitudes, misunderstandings, and whatnot, especially in misguided recursive iterations, it's pretty amazing that Open Source projects like Linux and BSD exist at all.

Maybe being anal about lining things up is not so bad.
 
So you got this big pile of code written in C. A couple of million lines or so, probably more. Worked on by hundreds of people, probably more. Worked on for 30-odd years, probably more. It's so 'bespoke' they even have their own custom version of the C library.

Now some guy shows up and says he wants to start adding some new code to it, written in something called rust.:)

You better make that thousands of people...

AI-programmer.png
 
blackbird9 said:
Oh dear... I been bad... I knows I bin bad...
Click to expand...
Let me tell you a story. Once upon a time I was running Linux on a 68030 based machine. There was a tool to defrag a file system, it contained inline assembler - but the endian is different. So it simply shredded a file system. Horay for cool factor.

But your digression is not big enough to warrant public whipping. Two hours of reading Knuth and Wirth for penance should do it.
 
Crivens said:
Nope. Inline assembler is extremely frowned upon. Not all the world is a VAX.
Click to expand...
Well it should be. Even the BBC Micro's BASIC supported inline assembler, albeit for a not-a-Vax.

Actually I was trying to make a case for the Vax, not inline assembler, which is horrid.
 
athan said:
Instead of needlessly spending man-hours on adopting new languages I would suggest that FreeBSD developers finally do some serious and organized work on kernel hardware support so that we are not forced to use Linux because of the weakness of our otherwise beloved FreeBSD.

Just my humble opinion, though...
Click to expand...
to me Debian is good. Better? in instances like when an aplication does not compile in FreeBSD. Other times it is too strict. Nobody can say this is better than that. In that case Gates is president.
 
I also recently corrupted memory by doing incorrect arithmetic for a buffer's size, an operator precedence problem
Click to expand...
That is hard, but I always use parentheses for arithmetic or logical operations to enforce explicit behavior, and
predictability. :)
 
You must log in or register to reply here.
Back
Top