Go- and Rust-based packages
"There are some packages where Debian cannot promise to provide minimal backports for security issues. These are covered in the following subsections.
[...]
5.2.1.2. Go- and Rust-based packages
The Debian infrastructure currently has problems with rebuilding packages of types that systematically use static linking. With the growth of the Go and Rust ecosystems it means that these packages will be covered by limited security support until the infrastructure is improved to deal with them maintainably.
In most cases if updates are warranted for Go or Rust development libraries, they will only be released via regular point releases."
More work to do is fair price to pay for security of Rust, even governments state C, C++ and other insecure languages need abolished in favor of Rust.
https://www.infoworld.com/article/2336216/white-house-urges-developers-to-dump-c-and-c.html
Oh, I see. You and the White House will pay that extra price and do that extra work. Problem solved.
I am a translator!
I recently wanted to try using https://github.com/mrusme/neonmodem (discourse client).
I did git clone it, went offline and tried compiling it. The compilation failed quickly as it was trying to fetch something from an external repository. Searching further, I found a file discourse.go with signatures for 319 things that I assume need to be fetched.
Does that mean that, to make a package of this, and ensure that source are available, one would have to fetch the sources for these 319 things, possibly make a package of each of them, and, possibly of any other thing that these 319 things might need? Possibly, this would mean providing as package all of what is in the go repository, which looks like a very heavy task. Is it what is actually needed?
Then, is the problem of maintenance raised by the Debian team about static linking related to this? Does static linking mean that all the dependencies are included in every binary, so that any update in one dependency requires to regenerate all the binaries? Is there no way with go to make dynamic linking?
I am not asking about rust because I have not had to deal with anything written in rust yet.
> Does static linking mean that all the dependencies are included in every binary, so that any update in one dependency requires to regenerate all the binaries?
Yes, you need to compile everything again whenever a linked library has been modified, or if you want to link to a different library. It is not an impossible task, but it is easier said than done, and it means that bugs may take longer to be fixed downstream, let alone backported. This is precisely what the Debian release notes are saying, specifically about security updates.
Isn't the reason people developed rust to prevent certain mistakes from being made that you can easily make in programming C language?
If so, it sounds like training wheels for developers.
Wouldn't it just be better to get developers who are experts at c programming instead?
You can disagree if you want, but I don't understand that to be a problem of C and C++.
I think that is a problem of people not being good enough at coding.
Just my twocents prospero and others.
Isn't the reason people invented lighters to ease the making of fire?
If so, it looks like training wheels for fire makers.
Wouldn't it just be better to get people who are experts at rubbing two sticks together?
You can disagree if you want, but I don't understand that to be a problem with stick rubbing.
I think that is a problem of people not being good enough at rubbing.
That is a fair point. I still don't think C and C++ are anymore insecure than rust.
The only difference is that the guardrails on rust are more obvious personally.
But yeah, lighters were made to ease fire making.
I think replacing debian package mantainers with an AI programmed in rust would be the simplest solution.
Amazon makes Rust safe
https://www.techzine.eu/news/devops/126463/aws-is-paying-to-make-rust-safe/
I don't think that rust is a silver bullet. There will always be newer programming languages coming out. Some will have promises like memory safeness, but that doesn't mean you should necessarily write all previous code in that language.
What is your favorite programming language?
To be honest, I like programming languages that are fast and efficient but non-bloated like C and C++.
But not because I know much of any, but because I can trust they won't be overly bloated.
My belief is that bloated programming languages are a time bomb for stability and security.
Some will of course disagree with this thinking, but that is how I think. Its the same reason I try to use GNU/Linux distros that are less bloated like Hyperbola. Devuan is another one I use as a next best thing, but I disable all proprietary repos if I intend to use it as a computer where I desire privacy/security which is just about all of them, except maybe one.
Its not the systemd thing that some care about, it goes well beyond that. Java is also huge as well and I don't trust it even more than rust by like 10000% and also because it has been hacked before due to the Log2shell for example and possibly other vulnerabilities.
But yeah, you could say some of it is definitely paranoia. That's also why some jumped the ship of proprietary operating systems. Although, there is reasonable evidence for the insecurities of proprietary operating systems in general.
Long winded answer done
C is bloated? What is not bloated then?
As far as I understand, Zoma says the opposite: that C is "non-bloated". So his surprising statement is that C++ is "non-bloated". That said, it has never been clear to me what people mean by "bloated". For the past 18 years, I have been mostly writing code in C++. It is definitely a complicated language. To the procedural subset (C), it first added object orientation, then generic programming, functional programming, etc.
Don't get me wrong: I am neither saying that it is good nor that it is bad. There are positives and negatives. Among the positives, a "no naked pointer policy" is now possible with C++. It helps avoiding C's dangling pointers, its memory leaks (that may eventually force the kernel to kill a process), its buffer overflows (and the related security issues), etc. Zoma considering "that bloated programming languages are a time bomb for stability and security", C may actually be bloated for him.
Code size was what I meant and complexity too. Also, you can make many compilers for C and C++, but you don't see many for Java or Rust.
At least that I know of.
Bloated I think means it has a lot of complexity and has some stuff that doesn't serve much more than flashiness rather than functionality. But yeah, clang is supposedly lighter than gcc. I know some BSDs compile clang without gcc. Which I find peculiar but its interesting.
Perhaps what I more find problematic given all of this, is the that there are few compilers for Rust and Java which means you need to accept their compiler or your out of luck. That's my understanding anyhow, but if you know of others that are up to date, etc... please tell me and I will see if they are worthy.
Btw, I appreciate the response, it was very rational and non-heated. I appreciate that much
Code size was what I meant and complexity too.
Those metrics go in opposite directions. A C program tend to be large because there are not many ways to achieve something. On the contrary, because C++ is complex, there are usually ways to write the same thing more succinctly. So, C would be bloated with respect to the code size but not to the complexity of the language and C++ would be bloated with respect to the complexity of the language but not to the code size.
The complexity of the language makes it harder to write a compiler, but most significant factors are the age of the language and its popularity.
Hmm.. maybe you could be right about C++. Although I don't think its true of regular C though.
But anywho, multiple compilers should be allowed is my main irk about Rust and java. Also it does take a very long time to build rust.
I have tried before. On my ivy bridge stuff, it takes like 2 hours just building a privacy friendly palemoon. I cannot imagine how much rust would take on this.
Last time I tried to build firefox itself on an OpenBSD, it took that long and it wasn't even done compiling.
Maybe this would speed up compiling times?
Firefox is mostly written in C++. Firefox's code even includes more C (12.1%) than Rust (10.6%): https://openhub.net/p/firefox/analyses/latest/languages_summary
That is interesting, I hadn't known this.
I thought they had changed it more drastically than that to move towards their servo version.
Mozilla has not been moving to Servo since the whole Servo team was laid off, more than four years ago: https://www.zdnet.com/article/mozilla-lays-off-250-employees-while-it-refocuses-on-commercial-products/