Is there a way to rank programming languages in terms of how "security oriented" they are?
- Inicie sesión o regístrese para enviar comentarios
But the "You may not charge for the software" explicitly applies to software distributed on mozilla.org, according to the policy:
" You may distribute unaltered copies of Mozilla Firefox and other Mozilla software from Mozilla.org without express permission from Mozilla as long as you comply with the following rules:
You may not charge for the software."
Rust isn't distributed on mozilla.org.
That is true. To know for sure, I have just sent that email to trademark [at] rust-lang.org:
Good evening,
https://www.rust-lang.org/policies/media-guide#rust-trademarks says "This document supplements the official Mozilla trademark policy which governs use of all Mozilla trademarks" with a link to https://www.mozilla.org/foundation/trademarks/policy/
It is however unclear whether https://www.mozilla.org/en-US/foundation/trademarks/distribution-policy/ applies, in particular whether that applies:
"You may distribute unaltered copies of Mozilla Firefox and other Mozilla software from Mozilla.org without express permission from Mozilla as long as you comply with the following rules:
* You may not charge for the software."
Rust not being "Mozilla software from Mozilla.org", at least not anymore, I tend to believe Rust's trademark does not restrict the freedom to distribute exact copies, including commercially. Does it?
I imagine the Rust Foundation still discusses Rust's trademark policy. If so, please do not misuse the trademark law to restrict the freedom to distribute exact copies, a copyright matter that effectively turns the software nonfree.
"Amazon Web Services uses it. [...] Facebook has started using Rust, as have Apple, Google, Dropbox and Cloudflare."
One Rust to rule them all. Even Cthulhu would shy away.
From mostly everything i've seen about non-free bloated rust in my honest opinion seems like it's all based on misleading lies and half truths resulting in some red flags, for me?
"Over the past year or so, we've been working on "Arti", a project to rewrite Tor in Rust. Thanks to funding from Zcash Open Major Grants (ZOMG), we can finally put the Arti project up in our priorities list, and devote more time to it."
https://blog.torproject.org/announcing-arti
^ About 700 thousand US dollars or whatever from some cryptocurrency company makes it easier?
https://tube.cadence.moe/watch?v=drfXNB6p6nI
^ Non-free damage control, one of the examples whatsapp is in erlang, according to wikipedia, which is technically memory safer?
"Using C and C++ is bad for society, bad for your reputation, and it’s bad for your customers."
https://alexgaynor.net/2019/aug/12/introduction-to-memory-unsafety-for-vps-of-engineering/
^ Using any language for a non-free program is bad for society?
https://www.theregister.com/2020/01/21/rust_actix_web_framework_maintainer_quits/
^ Microsoft mocking the rust "community"?
" Some users have correctly mentioned that many other software packages have trademarks, do we plan to remove them all? No. We are not against all trademarks, only those which explicitly prohibit normal use, patching, and modification.
As an example, neither Python PSF nor Perl Trademarks currently prohibit patching the code without prior approval. They do prohibit abuse of their trademarks, e.g. you cannot create a company called “Python”, but this does not affect your ability to modify their free software and/or apply patches. "
https://wiki.hyperbola.info/doku.php?id=en:main:rusts_freedom_flaws
"Warning: Running curl some-url | sh, as the Rust documentation suggests, is considered as a security risk, because it executes unknown code, that might even be corrupted during the download. Therefore it is recommended to manually download the script and check it, before executing it."
https://wiki.archlinux.org/title/Rust
https://github.com/sharkdp/bat/issues/1751
^ lol was promoted as a replacement on one of rusts social control medias. I guess the lack of prompt bug fixes would be less draining on the network issue of dealing with hefty rust nonsense.
https://github.com/sharkdp/bat/issues/1658
^ sounds like slowdow's findstr
And yes there appears to be contradictions in the story, and the whole "unsafe" "safe" may not be the silver bullet that some claim.
"since Linux developers seem to forecast benefits in adopting Rust, I guess it is the same."
Did they say something similar when they sold out with the non-free firmware? Perhaps it benefits someone's wallet?
"Again, Red Hat does not take part in the governance of Rust. Sorry about that: I know there somehow needs to be Red Hat involved for the conspiracy theory to be valid."
Red Hat/Ibm is just one of many shady branches sponsoring some "security" research group pushing bloated non-free rust, the group has stuff on https/ca-certs, which is flawed, if you look into it. And I never said that Red Hat is officially "part in the governance of Rust". Lmao, CONspiracy what? I just went a bit off topic mentioning how I am suspicious of organizations that signed or made statements to defame rms with that hate letter, and resorting to name-calling to try to make me look stupid serves what purpose for you?
"Those two sentences come with six links pointing to exploited vulnerabilities, with terrible consequences, attributed to memory unsafety in C and C++ code. They make the author's points. The links you provide do not make yours."
All of those links were for proprietary garbage. Windows ransomware, crapple, Android, non-free wifi, etc.. Non-free "security" is a joke, and not one good point in his absurd and toxic statement for me. You and neither that "author" can fool me to think that non-free can be good for society if just the language is changed.
"That is a list of CVE records. Would you take any of them and comment on it, so that we can see how much (or little) you understand about the technical issues you apparently have a strong opinion about?"
A video on "you"tube entitled "Why I hate Rust programming language?" said that "Rust is plagued with memory safety CVEs" and those guarantees of memory safety aren't looking so convincing since stuff like "buffer overflow" and "use-after-free" is mentioned multiple times for rust.
https://github.com/sharkdp/bat/issues/1751
^ lol was promoted as a replacement on one of rusts social control medias.
Is "a cat(1) clone with syntax highlighting and Git integration" (the description of bat) for "social control medias"? That makes no sense at all.
I guess the lack of prompt bug fixes would be less draining on the network issue of dealing with hefty rust nonsense.
The "issue serves as a forum for discussion and as a summary of tasks that can be worked on" and was opened less than three months ago.
https://github.com/sharkdp/bat/issues/1658
Despite the title of the issue, bat does not freeze, as the subsequent comments clearly show. The algorithm only takes far too much time to achieve its work on some inputs ("extreme long lines"). That has absolutely nothing to do with memory unsafety. That has absolutely nothing to do with the choice of the programming language either. In fact, https://github.com/sharkdp/bat/issues/1658#issuecomment-860876578 affirms the problem comes from "Sublime syntax files for highlighting" and Sublime Text is written in C++ and Python (but, again, the programming language has nothing to do with the issue).
And yes there appears to be contradictions in the story, and the whole "unsafe" "safe" may not be the silver bullet that some claim.
There is no contradiction if you would know what memory safety and time complexity are. They are completely unrelated topics.
As with systemd, we have here people (the same people) who pick random links to issues that they do not even read and post them as "proofs" that a technology they have no clue about is evil. Spreading FUD. I am done wasting my time with your nonsense.
> "I am done wasting my time with your nonsense."
[Magic Banana] - writes multiple posts the size of Tolstoy's War and Peace on [checks notes] memory safety and time complexity in the Rust programming language, which [checks notes] MB has never programmed in
[also Magic Banana] - complains that others are wasting MB's time
Someone has clearly wasted MB's time. I'm not sure it's the person MB is accusing of doing it though. Possibly a peek in the mirror would shed some light on the subject.
Mandatory XKCD link: https://xkcd.com/386/
You don't need to program in Rust to read and see that the bug in bat has absolutely nothing to do with memory safety but rather a slow syntax highlighting algorithm. I could find numerous slow programs written in any language, it doesn't say anything about the quality of the language. If you want to have an actual discussion on memory safety, let's focus on that. Otherwise, this discussion is pointless: https://en.wikipedia.org/wiki/Gish_gallop
Maybe the topic just isn't that interesting to you? I'd describe it as being open minded and checking out some stuff that's in rust to see if there is or isn't some real benefits and couldn't find any. Anyways, I think I will just stick with the regular cat. Rust being fast = "their" argument. This is a forum, not like a website where maybe could be more ideal and one could organize it more concisely?
I find the topic of Rust interesting, but there's no way to have an actual discussion with you, because of your gish galloping strategy: "During a Gish gallop, a debater confronts an opponent with a rapid series of many specious arguments, half-truths, and misrepresentations in a short space of time, which makes it impossible for the opponent to refute all of them within the format of a formal debate"
We were discussing the memory safety of Rust, and in response you brought up some random Rust program and pointed out some bugs that have nothing to do with memory safety, which is clearly a specious argument. If you want to discuss speed, let's discuss that. But if you keep coming up with new unrelated arguments against the use of Rust, there's no way I can respond to any of them. Also please stop downvoting people who disagree with you. I am open minded but most of your arguments don't make any sense.
> We were discussing the memory safety of Rust
> I can't really comment on the security part
I fully admit that I don't know how Rust's memory safety works, but the people here claiming that it's unsafe don't know how it works either. I do know quite a bit about the lack of memory safety in C and C++, and I can say for sure that that bug that the gaseousness guy pointed out has nothing to do with memory safety.
Did you discuss bloat? You should talk about bloat. Rust binaries are bloated compared to comparable C binaries. I would cite a source, but there are literally thousands of them to choose from.
And what about the slow compile times. And what about the higher use of electricity and natural resources caused by slower compile times and larger package sizes? Doesn't seem like it's friendly to the environment.
"Up until this point, our application was using the Rust standard library, libstd. libstd provides many convenient, well tested cross platform APIs and data types. But if a user wants to reduce binary size to an equivalent C program size, it is possible to depend only on libc.
It's important to understand that there are many drawbacks to this approach. For one, you'll likely need to write a lot of unsafe code and lose access to a majority of Rust crates that depend on libstd. Nevertheless, it is one (albeit extreme) option to reducing binary size."
This is a legitimate point. I suppose most people in most situations nowadays don't care about binary size, but if you're in a situation where it matters, don't use Rust (or any other language that compiles to large binaries).
Okay, these are actual drawbacks of Rust. But they have nothing to do with memory safety or speed, and certainly don't indicate any nefarious intent behind Rust. All I see here is a language that, like any other language, has its advantages and disadvantages. C++ has slow compile times. Go has large, statically linked binaries.
It would be interesting to measure the overall global electricity usage of compiling software, but I would guess overall it's pretty negligible. How many people actually compile software from source?
About running the software, here is "a study of the runtime, memory usage and energy consumption of twenty seven well-known software languages": https://greenlab.di.uminho.pt/wp-content/uploads/2017/10/sleFinal.pdf
In the "Normalized global results" (Table 4), Rust is second in energy consumption (3% more than C, 23% less than C++, which is third), second in runtime (4% slower than C, 33% faster than C++, which is third) and seventh in memory consumption (32% more than C, 15% more than C++).
From which we can conclude that Rust is no faster than C, and only marginally better than C++ at those benchmark tests. How exactly did we get from this to calling everyone to rush to adopt the whole Rust ecosystem at once?
I'll quote kernel Linus again: "If the Rust compiler ends up doing hidden allocations, and they then cause panics, then one of the main *points* of Rustification is entirely broken. That's 100% the opposite of being memory-safe at build time." And this is from someone who is not categorically opposed to adding Rust to Linux. He seemed to suggest caution.
Since the benchmark paper is the one I referenced at the very beginning of this thread, I fear we might be caught in a Groundhog Day situation. You are now the one quoting it, though, so we might be reaching some sort of common ground, if not common sense.
I don't think that everyone should adopt Rust. I'm just not opposed to the language, and I don't think there is anything nefarious about it. Another user in this thread were saying that Rust is very slow, by pointing to a bug in a specific Rust program that is slow. But that bug had nothing to do with the Rust language itself, and this paper indicates that Rust isn't actually slow.
As for Linus's comment, you missed some valuable context. Here is the email: https:name at domain/. Now, for an explanation of what this means:
Linux is a kernel, so it runs on bare metal and cannot use the full Rust (or C) standard library ("std"), which relies on various OS functionalities. The relevant patch however uses the "alloc" crate to handle memory allocations, which relies on some helper functions that the user (of the crate) has to provide. One of these helper functions is __rust_alloc_error_handler, which is called when there is a failure to allocate memory. In the patch, the implementation of this helper function just triggers a kernel panic. Linus's comment is stating that if a driver is written in Rust, this would cause the kernel to panic, which is bad. However, this is due to the patch's handling of memory allocation errors by just panicking, rather than any feature of Rust (which expects the user to implement error handling). Indeed, in the next email Miguel Ojeda states that they will be customizing alloc to do various things, including fallible allocations.
From which we can conclude that Rust is no faster than C
4% slower. If that is your problem with Rust, it would make more sense to direct your criticisms towards Python, which is significantly more used and 7090% slower than C (6813% slower than Rust), according to those same benchmarks. Or towards C++, for a more similar language: C++ is reported to be 50% slower than Rust.
Rust is fast, but that doesn't mean that if you implement a slow algorithm in Rust it will magically become fast! If that's your bar then no language will satisfy it.
"It is important to keep in mind that just because a program is marked as "Done" doesn't mean that all of the tests are passing or that the utility is as performant or memory-efficient as the GNU version. For example, there are open issues to improve the performance of factor (roughly 5x slower) and sort (between 1.5x to 6x slower). In some other cases, the uutils versions are faster than their GNU equivalents. An example is the cp utility in which a measurable performance improvement has been reported, primarily due to the use of the sendfile() and copy_file_range() system calls, which are not being used in the GNU version despite several proposals to do so. "
https://lwn.net/Articles/857599/
?
Cross compilation will be helpful for more community support? Everyone is super rich and can buy a computer just to compile rust software in less time? Sounding like with IOS how one would need to use macos to author an application for the app store? If you're such an experienced C and C++ programmer as you mentioned earlier, why feel the need to use ridiculous false accusations, because personally I find that very unconvincing?
Okay so they're rewriting some programs in Rust, and some of the reimplementations are faster while others are slower. That hardly says anything about the speed of the Rust language.
I don't understand your point about cross compilation or iOS. Yes, I am experienced in C and C++. False accusations of what? The lack of memory safety in C and C++? That is well known to anyone who programs in those languages.
"I don't understand your point about cross compilation or iOS."
Seems like we'd lose a bragging point with widespread rust adoption. In order to make an "app" on app store (crap store) one needs macos. Needing a superfast computer to try and cutdown the excessive rust compile times would contradict a selling point with free software.
"False accusations of what?"
You mentioned, https://en.wikipedia.org/wiki/Gish_gallop , but these forums are quite different than a debate with a time limit, and I'm not trying to be deceptive.
Long line issues like slowdows findstr wasn't the only performance bug in the rust version of cat downgrade, was just kinda amusing to me.
https://github.com/sharkdp/bat/issues/1751
^ There are multiple issues for performance apparently, looking too complicated bugs adding up not getting fixed fast. It was just one of many promoted on barely social "media" reddit as like rust replacements. I can just run less on a file.
"This is a legitimate point. I suppose most people in most situations nowadays don't care about binary size, but if you're in a situation where it matters, don't use Rust (or any other language that compiles to large binaries)."
I disagree, perhaps some people prefer "stable" distributions, prefer just smaller security updates, and not be overwhelmed with feature updates, or more "cry wolf" updates, and it's easier/faster to backup if smaller overall.
"How many people actually compile software from source?"
Someone has to? And maybe is nice to know if you're on a binary distribution that you can still get the source code. apt source maybe beats microsoft's github or an option that's not making it worse? Source code that's in rust, just to tainted with loopholes it sounds like, perhaps legal issues, unstable, way too bloated.
https://guix.gnu.org/blog/2018/bootstrapping-rust/
"The lack of memory safety in C and C++? That is well known to anyone who programs in those languages."
But doesn't seem to matter that much in the grand scheme of things? Java isn't memory "unsafe" and has/had not the greatest reputation security-wise?
"What separates Rust from C and C++ is its strong safety guarantees. Unless explicitly opted-out of through usage of the “unsafe” keyword, Rust is completely memory safe, meaning that the issues we illustrated in the previous post are impossible to express. In a future post, we’ll revisit those examples to see how Rust prevents those issues usually without adding any runtime overhead. As we’ve seen, roughly 70% of the security issues that the MSRC assigns a CVE to are memory safety issues. This means that if that software had been written in Rust, 70% of these security issues would most likely have been eliminated. And we’re not the only company to have reported such findings. "
https://msrc-blog.microsoft.com/2019/07/22/why-rust-for-safe-systems-programming/
^ I should take Microsoft's damage control seriously, or trust Mozilla propaganda blogs these days?
"However, there are classes of bugs that Rust explicitly does not address—particularly correctness bugs. In fact, during the Quantum CSS rewrite, engineers accidentally reintroduced a critical security bug that had previously been patched in the C++ code, regressing the fix for bug 641731. This allowed global history leakage via SVG image documents, resulting in bug 1420001. As a trivial history-stealing bug, this is rated security-high. The original fix was an additional check to see if the SVG document was being used as an image. Unfortunately, this check was overlooked during the rewrite."
https://hacks.mozilla.org/2019/02/rewriting-a-browser-component-in-rust/
^ Rewriting causing issues who would have suspected (sarcasm). If you visit the links that the Mozilla site has for the bug, severity is normal and not "high" as was claimed.
There's a pref "svg.disabled" in the about:config, if anyone's curious.
later on in the blog it states "Overall, bugs related to memory, bounds, null/uninitialized variables, or integer overflow would be prevented by default in Rust. The miscellaneous bug I referenced above would not have been prevented—it was a crash due to a failed allocation."
^ Quite the plot twist?
> Needing a superfast computer to try and cutdown the excessive rust compile times would contradict a selling point with free software.
Other languages have long compile times, e.g. C++, but I don't see as many complaints about them here. I wonder why.
> ^ There are multiple issues for performance apparently, looking too complicated bugs adding up not getting fixed fast. It was just one of many promoted on barely social "media" reddit as like rust replacements. I can just run less on a file.
Once again, bat's performance issues have nothing to do with Rust, but rather the implementation of bat. If you rewrote the whole thing in C using the same algorithms, that wouldn't make it fast.
> I disagree, perhaps some people prefer "stable" distributions, prefer just smaller security updates, and not be overwhelmed with feature updates, or more "cry wolf" updates, and it's easier/faster to backup if smaller overall.
You prefer software with a smaller download size. But the developers who program in Rust feel that the increased binary size is an acceptable tradeoff for the benefit of increased memory safety. Any language will have its advantages and disadvantages, that's just how it is. And by the way, large binary size is also a problem with other languages like Go and Haskell.
> "How many people actually compile software from source?" Someone has to?
I realize that, but I said this in response to the claim that Rust is more energy-intensive because of its high compilation time. The amount of energy used for compiling software is miniscule compared to total energy consumption, because the vast majority of users (even on GNU/Linux) rarely compile from source.
> Source code that's in rust, just to tainted with loopholes it sounds like, perhaps legal issues, unstable, way too bloated.
Citations, please.
> Rewriting causing issues who would have suspected (sarcasm). If you visit the links that the Mozilla site has for the bug, severity is normal and not "high" as was claimed.
Yes, rewriting code tends to cause issues, regardless of the programming language that you use. Rust is not magic, it will not fix all bugs.
"You prefer software with a smaller download size. But the developers who program in Rust feel that the increased binary size is an acceptable tradeoff for the benefit of increased memory safety."
The alleged memory safety improvements aren't always the reasons why someone wrote something in the more sluggish and non-free rust from what I've heard and seen.
https://tube.cadence.moe/watch?v=qHOdYO3WUTk
^ For example, looks like the command line is just garbage for apple, similarly to slowdows. mate-terminal works well enough for me, even with its many features. I could just install stterm, on trisquel, much less features but so fast, as well, and security is much better with free software than non-free. Also, kitty (in python if I remember right) wasn't that much slower than Alacritty (I posted a link to a "you"tube video, before somewhere on this forum topic). Qutebrowser ain't that much slower, maybe even faster than the usual options? So non-free rust is just more bloated to me. And just because C can be more dangerous, doesn't mean it can't be safe, well tested, and fast?
"If you rewrote the whole thing in C using the same algorithms, that wouldn't make it fast."
No need to, the GNU coreutils are working well and are fast, so are the busybox ones on my gnu/linux laptop and router, respectively. I Don't see some sort of doomsday scenario security wise like the troll Alex Gaynor is pushing.
https://security-tracker.debian.org/tracker/source-package/coreutils
^ Not a fan of the amount of cve's argument, but looks not that bad Debian\Trisquel's if you check out the notes section for previous issues which have been resolved, but even if they did, I'm not that concerned if there happened to be a bug or two, because I have faith a security update would be available promptly, and it's much been so much better than apple, slowdows, android, etc.
"And by the way, large binary size is also a problem with other languages like Go and Haskell."
"C is far from the perfect language - it has many flaws. However, its replacement will be simpler - not more complex. Consider Go, which has had a lot of success in supplanting C for many problems. It does this by specializing on certain classes of programs and addressing them with the simplest solution possible. It hasn’t completely replaced C, but it has made a substantial dent in its problem space - more than I can really say for Rust (which has made similar strides for C++, but definitely not for C)."
https://drewdevault.com/2019/03/25/Rust-is-not-a-good-C-replacement.html
"Citations, please."
There was a nice blog I read from a gentoo dev, claiming that rust used to call "compatibility notes" as "breaking changes" and more, but it has some profanity in it, and posting the link could be against the community guidelines for these forums? I usually do cite, but that part was mostly just my personal opinions and concerns but at least will give a link from time to time. I could see how the toxic rust "community" could make someone less willing to speculate on potential issues, but look what happened to centos (killed off way too early by IBM?), ubuntu (snap being pushed too hard, wasn't so bad before, and basically trash nowadays?), rasberry pi (compromised repositories and censored forums?), audacity (musegroup cla, spyware?), etc., I'm not some sort of an international legal expert or RMS, but... some recent events and uncommon sense shoudln't be taken into consideration?
But here's an example of ridiculousness https://tube.cadence.moe/watch?v=Y6lvbiqaSn8
http://www.kroah.com/log/blog/2020/09/18/fast-kernel-builds/
^ Looks like his laptop is fast enough, and just a few minutes.
"One such case is this disgusting video: "Why I hate Rust programming language?" Why I hate Rust programming language? - YouTube which is so full of misinformation and misunderstanding that it's impossible to comment on it."
https://users.rust-lang.org/t/rust-cves-should-i-worry/59904
^The "you"tube video wasn't "full" of "misinformation", in my honest opinion. It was just someone's opinion and he cited sources nicely for much of it.
"because the vast majority of users (even on GNU/Linux) rarely compile from source."
It's a nice option to know that you have at the end of the day, even if one prefers the faster binary installation? Users can report bugs, but you really think that the more sluggish non-free rusts excessive compile times won't reduce the number of people who will be willing to contribute potential fixes for bugs?
"It was established on February 8, 2021, with five founding corporate members (Amazon Web Services, Huawei, Google, Microsoft, and Mozilla)."
https://en.wikipedia.org/wiki/Rust_(programming_language)
"They"
https://teddit.net/r/rust/comments/p0bu4a/microsoft_rust_intro_says_rust_is_known_to_leak/
^ Microsoft revising its propaganda slogans for their non-free bloatware? Some call it marketing?
"A downgrade to Windows 10 deleted surveillance-detection applications. Then another downgrade inserted a general spying program. Users noticed this and complained, so Microsoft renamed it to give users the impression it was gone.
To use proprietary software is to invite such treatment."
https://www.gnu.org/proprietary/malware-microsoft.html
^ Looking like a one of tricks up good ole Microsoft's sleeve?
"Rust packages are not reproducible"
https://issues.guix.gnu.org/50015
"The motivation behind the Reproducible Builds project is therefore to allow verification that no vulnerabilities or backdoors have been introduced during this compilation process. By promising identical results are always generated from a given source, this allows multiple third parties to come to a consensus on a “correct” result, highlighting any deviations as suspect and worthy of scrutiny."
https://reproducible-builds.org/
That gnu guix link I sent earlier from 2018 suggested non-free bloated rust had the same issues? Hopefully, rust will become better, but should I get my hopes up? Because the more one looks into it, the more it's looking to be built on empty promises and just some fake security ensuring non-free planned obsolesce?
Surely there are many reasons to exercise caution about the Rust hype.
All the info is freely available to anyone who wants to make their own mind about it instead of blindly following some vague promises or cult-like propaganda.
I now stick to one language, because it is both decently fast and mature enough to minimize bad surprises, and it is structured in a way that makes me happy. Maybe Rust also makes some people happy and relaxed.
Non-free rust is more bloated speed wise and disk usage wise? It can't do dynamic linking with librarys which is nice for like desktop usage with a package manager, although static can be a good way to do it in more a of a suckless set up? The bugs adding up for months and a seemingly skilled dev asking for help making rust look not as good as "they" presented it, in my opinion. Nano opened the json file with syntax highlighting for me fast, and the regular cat was fast as well, bet vi would work well too.
https://teddit.net/r/rust/comments/oygrp1/your_favorite_rust_cli_utility_i_have_my_top_10/
^ "social media", centralized, censored, and propaganda pushed hard, privacy issues with the common big tech ones i bet.
"As with systemd, we have here people (the same people) who pick random links to issues that they do not even read and post them as "proofs" that a technology they have no clue about is evil. Spreading FUD."
Systemd is a program, rust is a programming language. Obviously, someone can write malware or garbage in any language, so don't get the point? And lmao, I didn't bring up systemd, you did, and it's off topic, whether a non-free more bloated unstable programming language is better for paranoia/security is different than whether a program is evil. If you're concerned that someone is deliberately trying to spread misinformation about systemd, why not start a new topic and be specific, "people" is a bit too vague, and why would someone even want to do that, kind weird? And what's funny is that if you're gonna side with Alex Gaynor, then you're basically spreading FUD about free software "open source" because I'm not seeing a doomsday security situation with free software like with the ridiculous non-free. Hearing about silly slowdows ransomware over and over again, is getting old, and at least we can backup nicely and conveniently mount the backup read only, and I don't care about the non-free delineate security issues. Like his non-free crapple "sandbox", I'm not aware of being able to go all out with it in garbage like windows\android, like you can with apparmor and firejail with free software. I guess bloated non-free rust solves some "problem" the way Ubuntu's snap crapstore solved some "problem"?
https://discussions.apple.com/thread/4992565
Here's a "random" link I've personally seen with crapple malware, and have heard people tell me about how crapple deleted their music, etc.
"As for the FSF's own systems, we are upgrading them as we speak. We'd like to thank the Trisquel‡ and Debian distributions of GNU/Linux for quickly releasing updates with fixed packages."
https://www.fsf.org/news/free-software-foundation-statement-on-heartbleed-vulnerability
apt show ca-certificates
in the terminal shows
"Please note that Debian can neither confirm nor deny whether the certificate authorities whose certificates are included in this package have in any way been audited for trustworthiness"
Here's another "random" link that contradicts Alex Gaynor's openssl example. We get updates fast if we want them and his argument in regards with free software "open source" only makes it look better.
"I am done wasting my time with your nonsense."
Okay, if that's how you'd like to twist it :)
https://www.tiobe.com/tiobe-index/
https://www.jetbrains.com/lp/devecosystem-2021/
Appears there are other websites that claim to rank programing languages based on popularity like stackoverflow, but different results. According to TIOBE, C is the most famous right now, but JetBrains says JavaScript.
https://tube.cadence.moe/watch?v=tRlVk2nkXzs
^ Did they seem scared of the propaganda from just a few years ago?
"Lines 428 - 434. "We found 4990 unsafe usages in our studied applications in Table 1, including 3665 unsafe code regions, 1302 unsafe functions, and 23 unsafe traits. In Rust’s standard library (Rust std for short), we found 1581 unsafe code regions, 861 unsafe functions, and 12 unsafe traits." The detailed numbers are in tab "section-4-stat". They can be generated by executing the following commands in the VM:"
https://github.com/system-pclub/rust-study
^Perhaps something like that, or external crates, libs, or whatever you download may want to be careful with as well? One of many potential issues.
" You can write insecure software in any language. For example, vulnerabilities to SQL injection are another common weakness, and this can occur in practically every language (including C, Java, and many others). However, most languages provide mechanisms (like prepared statements in a built-in or external library) that are easy to use and completely avoid common problems like SQL injections. Yes, you have to be careful to use these mechanisms... but that is true for C, Java, and most other languages.
Selecting safer languages does not avoid all problems that can occur in unsafe languages. Safer languages are typically implemented on top of infrastructures and libraries that are themselves written in unsafe languages like C, C++, or Objective-C. The run-time libraries of most language implementations today are written in C, many libraries are written in C, most applications eventually call down to the C run-time library, and practically all operating system kernels in wide use today are written in C. Still, it is a matter of degree; vulnerabilities specific to C, C++, or Objective-C can only occur in the parts written in those languages, so selecting safer languages can reducing overall risk. (I knew of this long before, but my thanks to David Ramos at Stanford University for encouraging me to add this information.) "
https://dwheeler.com/essays/heartbleed.html
Side note, rust's bloat could discourage the potential enabling of some future mitigation, which may cost a little performance wise? lack of dynamic linking support, freedom flaws, not reproducible (unless reproducible builds has a trick with it?) are probably the main reasons I'd question if rust might actually be less secure?
- Inicie sesión o regístrese para enviar comentarios