HyperWiki

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
Next revision 		Previous revision
en:philosophy:rust_issues [2025/04/14 22:11]
throgh [About Rebranding] 		en:philosophy:rust_issues [2025/04/19 02:32] (current)
throgh [Further details, relations and connections]
Line 24: Line 24:
  
 **Rust** is fully controlled by companies / corporations, was developed also under those circumstances. From here with those details we can surely start. Last short note: But why do we write then that much text for this analysis here? Why do we have that amount of problems with companies / corporations? Because free, libre software and culture surely needs support, financial and also with helping hands, but this should be done from the motivation of people, because they really appreciate the software and the values ​​behind it. Not just stating to support free, libre software but afterwards only because the software is being delivered "gratis for their own egocentric imagination of freedom". **Rust** is fully controlled by companies / corporations, was developed also under those circumstances. From here with those details we can surely start. Last short note: But why do we write then that much text for this analysis here? Why do we have that amount of problems with companies / corporations? Because free, libre software and culture surely needs support, financial and also with helping hands, but this should be done from the motivation of people, because they really appreciate the software and the values ​​behind it. Not just stating to support free, libre software but afterwards only because the software is being delivered "gratis for their own egocentric imagination of freedom".
 +
 ===== What are the issues? ===== ===== What are the issues? =====
  
Line 35: Line 36:
 </code> </code>
  
-Exactly the phrases **relatively small** and **very clearly communicated to end-users** are parts of the problems: They are vague in their meaning and it is clear that the Rust Foundation has no real interest to have modified versions distributed. So for example to have **Cargo** removed as otherwise non-free packages could be used from projects being compiled. In fact Rust is that kind of complex with demanding dependencies that a removal of its internal package-management (**Cargo**) makes it not working and so there are [[https://docs.rs/crate/cargo-deny/latest|even plugins]] to control licenses before applying something. That violates also Hyperbolas point of minimalism and the possibility to rebuild any package with own modifications from users at any given time! We talk here about making free, libre software good to handle and learn for technical emancipation, while Rust is going even more complicated and complex.+Exactly the phrases **relatively small** and **very clearly communicated to end-users** are parts of the problems: They are vague in their meaning and it is clear that the Rust Foundation has no real interest to have modified versions distributed. So for example to have **Cargo** removed as otherwise non-free packages could be used from projects being compiled. In fact Rust is that kind of complex with demanding dependencies that a removal of its internal package-management (**Cargo**) makes it not working and so there are [[https://web.archive.org/web/20250414191623/https://docs.rs/crate/cargo-deny/latest|even plugins]] to control licenses before applying something. That violates also Hyperbolas point of minimalism and the possibility to rebuild any package with own modifications from users at any given time! We talk here about making free, libre software good to handle and learn for technical emancipation, while Rust is going even more complicated and complex.
  
 In short, the **Rust Foundation won't be happy with applying patches and modifications** to their language **without "explicit approval", so it is a freedom issue**. We should not have to ask for modifications and we do not ask for permission. In short, the **Rust Foundation won't be happy with applying patches and modifications** to their language **without "explicit approval", so it is a freedom issue**. We should not have to ask for modifications and we do not ask for permission.
Line 53: Line 54:
 ===== Further details, relations and connections  ===== ===== Further details, relations and connections  =====
  
-There are important applications integrating Rust as a first-class language. Tor is one of them, and they have [[https://web.archive.org/web/20250414175014/https://blog.torproject.org/arti_100_released/|concluded their new implementation called "arti" written in Rust]] and the [[https://lore.kernel.org/lkml/20241126022500.718070-1-ojeda@kernel.org/|Linux-kernel with its Rust-implementation is also growing]].+There are important applications integrating Rust as a first-class language. Tor is one of them, and they have [[https://web.archive.org/web/20250414175014/https://blog.torproject.org/arti_100_released/|concluded their new implementation called "arti" written in Rust]] and the [[http://web.archive.org/web/20241209130309/https://lore.kernel.org/lkml/20241126022500.718070-1-ojeda@kernel.org/|Linux-kernel with its Rust-implementation is also growing]].
  
 <note tip>As an alternative to Tor, [[https://i2pd.website/|i2pd (I2P Daemon)]] may be used. It is a full-featured C++ implementation of I2P client, **useful for building and using the anonymous I2P network**. However, **i2pd isn't compatible with the Tor network and uses .i2p rather than .onion sites** (also known as [[en:project:hidden_services|Tor Hidden Services]]).</note> <note tip>As an alternative to Tor, [[https://i2pd.website/|i2pd (I2P Daemon)]] may be used. It is a full-featured C++ implementation of I2P client, **useful for building and using the anonymous I2P network**. However, **i2pd isn't compatible with the Tor network and uses .i2p rather than .onion sites** (also known as [[en:project:hidden_services|Tor Hidden Services]]).</note>
Line 59: Line 60:
 Also many other projects are changing their approach or get a complete rewrite in Rust as first-class language, some further examples: Also many other projects are changing their approach or get a complete rewrite in Rust as first-class language, some further examples:
  
-  * [[https://github.com/signalapp/libsignal|implementation for libsignal]] as [[https://github.com/signalapp/libsignal-protocol-c|libsignal-protocol-c is no longer active maintained]] +  * [[https://web.archive.org/web/20250418230113/https://github.com/signalapp/libsignal|implementation for libsignal]] as [[https://web.archive.org/web/20250418230142/https://github.com/signalapp/libsignal-protocol-c|libsignal-protocol-c is no longer active maintained]] 
-  * [[https://github.com/neovim/neovim/releases/tag/v0.7.0|neovim adding tree-sitter as mandatory dependency since v0.7.0]], as [[https://github.com/tree-sitter/tree-sitter|tree-sitter is a full Rust-depending project]] +  * [[https://web.archive.org/web/20250418232923/https://github.com/neovim/neovim/releases/tag/v0.7.0|neovim adding tree-sitter as mandatory dependency since v0.7.0]], as [[https://web.archive.org/web/20250418232931/https://github.com/tree-sitter/tree-sitter|tree-sitter is a full Rust-depending project]] 
-  * [[https://github.com/GNOME/librsvg|librsvg being completely rewritten in Rust]] +  * [[https://web.archive.org/web/20250418232422/https://github.com/GNOME/librsvg|librsvg being completely rewritten in Rust]] 
-  * [[https://blog.clamav.net/2022/05/clamav-01050-01043-01036-released.html|ClamAV is enforcing the Rust-toolchain since v0.105]] +  * [[https://web.archive.org/web/20250418232554/https://blog.clamav.net/2022/05/clamav-01050-01043-01036-released.html|ClamAV is enforcing the Rust-toolchain since v0.105]] 
-  * [[https://github.com/uutils/coreutils|GNU coreutils getting a cross-platform implementation in Rust]]+  * [[https://web.archive.org/web/20250418232608/https://github.com/uutils/coreutils|GNU coreutils getting a cross-platform implementation in Rust]]
  
 The list can be enhanced for sure and clear to say that Rust is not only some sideload toolchain. As the buzzword "memory safety" is being in usage more and more projects get on this. Yes, the rewrite of GNU coreutils is not the main project. But who says exactly that this won't be the near future? As all the other points in this article were long before described, not solved and just accepted. It is a bad and foul compromise, endangering freedom of choice, user freedom for sure and also the freedom for system-distributions and operating-systems like Hyperbola. The list can be enhanced for sure and clear to say that Rust is not only some sideload toolchain. As the buzzword "memory safety" is being in usage more and more projects get on this. Yes, the rewrite of GNU coreutils is not the main project. But who says exactly that this won't be the near future? As all the other points in this article were long before described, not solved and just accepted. It is a bad and foul compromise, endangering freedom of choice, user freedom for sure and also the freedom for system-distributions and operating-systems like Hyperbola.
  
-It should be also mentioned that the **Rust Foundation** has a comparable [[https://web.archive.org/web/20250414005935/https://rustfoundation.org/members/|members-list ]] like the [[https://www.linuxfoundation.org/about/members|Linux Foundation]]. Speaking about a "community" is therefore not fitting in any way as those members are just companies and corporations. Neither Rust nor Linux are real [[en:philosophy:community_software|community-oriented software]] and the FSF has failed to fork the kernel as GNU/Linux-libre for a long time now. That's the point for Hyperbola to become independent in a whole. You think we are wrong here within the concrete analysis? Please have a look at the "[[https://web.archive.org/web/20250414005924/https://rustfoundation.org/about/#board-of-directors|Board of Directors]]" of the **Rust Foundation**, where the majority of persons working for corporations being neither reliable nor trustworthy in regards of free, libre software.+It should be also mentioned that the **Rust Foundation** has a comparable [[https://web.archive.org/web/20250414005935/https://rustfoundation.org/members/|members-list ]] like the [[http://web.archive.org/web/20240511072507/https://www.linuxfoundation.org/about/members|Linux Foundation]]. Speaking about a "community" is therefore not fitting in any way as those members are just companies and corporations. Neither Rust nor Linux are real [[en:philosophy:community_software|community-oriented software]] and the FSF has failed to fork the kernel as GNU/Linux-libre for a long time now. That's the point for Hyperbola to become independent in a whole. You think we are wrong here within the concrete analysis? Please have a look at the "[[https://web.archive.org/web/20250414005924/https://rustfoundation.org/about/#board-of-directors|Board of Directors]]" of the **Rust Foundation**, where the majority of persons working for corporations being neither reliable nor trustworthy in regards of free, libre software.
  
 The point here is that Rust is not only a programming-language and the build-process needs essential Cargo to download further dependencies. As a current perspective there are 178.665 so-called "crates" available at **[[https://web.archive.org/web/20250410212024/https://crates.io/|crates.io]]** (//growing while we have written this article and you, dear readers, are reading here//). Every so-called **crate** is comparable to an own third-party library, possible to be downloaded and included right at build-time. In fact there is no complexity-reduction with **Rust** at any given point it is also not possible to patch any kind of simple solution back into this failed architecture. While **Rust** itself is also not a community-driven project and therefore only driven by corporations and companies throughout the Rust Foundation. The point here is that Rust is not only a programming-language and the build-process needs essential Cargo to download further dependencies. As a current perspective there are 178.665 so-called "crates" available at **[[https://web.archive.org/web/20250410212024/https://crates.io/|crates.io]]** (//growing while we have written this article and you, dear readers, are reading here//). Every so-called **crate** is comparable to an own third-party library, possible to be downloaded and included right at build-time. In fact there is no complexity-reduction with **Rust** at any given point it is also not possible to patch any kind of simple solution back into this failed architecture. While **Rust** itself is also not a community-driven project and therefore only driven by corporations and companies throughout the Rust Foundation.
Line 94: Line 95:
 ===== What about alternative compilers and implementations? ===== ===== What about alternative compilers and implementations? =====
  
-Yes, we have seen, read and heard about [[https://rust-gcc.github.io/|gccrs]] as an alternative frontend being part of the GCC-project in the future. Besides being interested in this the approach is not finalized until now and needs surely more work until being fully useful. Until this point it is also not finally clear how **Rust** itself with compilation and dependency-management is being handled throughout **gccrs** itself.+Yes, we have seen, read and heard about [[https://web.archive.org/web/20250414191255/https://rust-gcc.github.io/|gccrs]] as an alternative frontend being part of the GCC-project in the future. Besides being interested in this the approach is not finalized until now and needs surely more work until being fully useful. Until this point it is also not finally clear how **Rust** itself with compilation and dependency-management is being handled throughout **gccrs** itself.
  
 So for the moment we have the only trademarked reference-implementation onwards and this relates back to our points brought into before. The Rust Foundation has provided [[https://web.archive.org/web/20250407110031/https://blog.rust-lang.org/2024/11/07/gccrs-an-alternative-compiler-for-rust.html|an article about gccrs]] showing that the funding of this project is also not related to a community itself: **gccrs** was initially funded by the companies [[https://embecosm.com/|Embecosm]] and [[https://opensrcsec.com/|Open Source Security]]. So for the moment we have the only trademarked reference-implementation onwards and this relates back to our points brought into before. The Rust Foundation has provided [[https://web.archive.org/web/20250407110031/https://blog.rust-lang.org/2024/11/07/gccrs-an-alternative-compiler-for-rust.html|an article about gccrs]] showing that the funding of this project is also not related to a community itself: **gccrs** was initially funded by the companies [[https://embecosm.com/|Embecosm]] and [[https://opensrcsec.com/|Open Source Security]].
Line 102: Line 103:
 Some users have correctly mentioned that many other software packages have trademarks, do we plan to remove them all? No, but we see trademarks generic also not under a positive aspect when they are used that kind of harsh. Some users have correctly mentioned that many other software packages have trademarks, do we plan to remove them all? No, but we see trademarks generic also not under a positive aspect when they are used that kind of harsh.
  
-As an example, neither [[https://www.python.org/psf/trademarks/|Python PSF]] nor [[https://www.perlfoundation.org/trademarks.html|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. And to underline again: We just refer towards patching the software-packages, not towards the generic trademark.+As an example, neither [[https://web.archive.org/web/20250414193354/https://www.python.org/psf/trademarks/|Python PSF]] nor [[https://web.archive.org/web/20250414193424/https://www.perlfoundation.org/trademarks.html|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. And to underline again: We just refer towards patching the software-packages, not towards the generic trademark.
  
 Due to the very strict written modification-clause, Rust is a non-permissive trademark that violates user freedom. Due to the very strict written modification-clause, Rust is a non-permissive trademark that violates user freedom.
Line 110: Line 111:
 Both projects have a clear trademark to protect the usage of the software itself against fraud. But there is a difference as Python and Perl allow patching and modification defined within the four freedoms. Both projects have a clear trademark to protect the usage of the software itself against fraud. But there is a difference as Python and Perl allow patching and modification defined within the four freedoms.
  
-From [[https://www.python.org/psf/trademarks/|Python]]:+From [[https://web.archive.org/web/20250414193354/https://www.python.org/psf/trademarks/|Python]]:
  
 <code> <code>
Line 124: Line 125:
 </code> </code>
  
-From [[https://www.perlfoundation.org/trademarks.html|Perl]]:+From [[https://web.archive.org/web/20250414193424/https://www.perlfoundation.org/trademarks.html|Perl]]:
  
 <code> <code>
Line 180: Line 181:
  
 A free and libre oriented system cannot provide a package-manager besides its own to preserve the autonomy of the free system itself. What the users are doing is their own decision, but they should be always able to assure a consistent free and libre oriented system outside their own decisions that they are responsible for. Hyperbola decided clearly on behalf of the users: If they want to build **Rust** with its reference implementation, they can always do this. But we see our responsibility to provide just a working system with software around being clearly free and libre for users, not to grant more likewise packages with even their own package-management. That is a point of complexity we reject now and will always do. An operating-system has not the task to grant more complexity, especially when it is free and libre. It should grant insights when the users want them, at any given time. To manage and compile software should be transparent, not with growing listings of needed dependencies. **Rust** is outgrowing this and on technical and social scaling the project is for Hyperbola clearly questionable. A free and libre oriented system cannot provide a package-manager besides its own to preserve the autonomy of the free system itself. What the users are doing is their own decision, but they should be always able to assure a consistent free and libre oriented system outside their own decisions that they are responsible for. Hyperbola decided clearly on behalf of the users: If they want to build **Rust** with its reference implementation, they can always do this. But we see our responsibility to provide just a working system with software around being clearly free and libre for users, not to grant more likewise packages with even their own package-management. That is a point of complexity we reject now and will always do. An operating-system has not the task to grant more complexity, especially when it is free and libre. It should grant insights when the users want them, at any given time. To manage and compile software should be transparent, not with growing listings of needed dependencies. **Rust** is outgrowing this and on technical and social scaling the project is for Hyperbola clearly questionable.
 +
 +**Don't you spread false arguments especially when it comes to companies and corporations?**
 +
 +First and foremost the common argumentation is therefore that people think adoption of languages would be only possible with the support of companies and corporations, especially from the technology-sector. We are surely aware how this relates also to **Python** and **Perl**, besides there being also corporate sponsoring aboard. Nevertheless there is a difference we already pointed out several times: We want to preserve the autonomy of our operating-system. Whatever other projects and people think they accuse us, we never wanted anything else. Technical programming languages and implementations with their own package-manager are not trustworthy for keeping a free and libre system safe enough from problematic dependencies and therefore also under the control of their users.
 +
 +Yes, Hyperbola as project was and is accused of spreading so-called "FUD" (//Fear, Uncertainty and Doubt//). A propaganda-strategy to bring up an appointed target into discredit. So we clear up with this point here also: Sure we mention doubts and problems, but we just do this in the context of our project and why we exclude **Rust**. We said several times here in the article that others can always handle different. It is sidewise mentioned interesting how often Hyperbola is accused while just listing the issues we see. When others do not see the outgrowing complexity as an issue, please be invited doing so. We have a different approach and list just the reasoning for us doing this. But accusing Hyperbola to spread propaganda is a quite different thing and in itself not outright correct. If you read through our wiki-articles and also include the generic perspectives Hyperbola is following, we never talk about some "evil masterplans" or "nefarious motivations" when talking about companies and corporations. When you use those assumptions, then those are born within your own thoughts and you just relate them to us. We just talk about arrogance and ignorance as companies and corporations are following always only those motivations. Ask yourself what kind of motivation any company might have to be a sponsor of a project. For sure not the orientation on the community-aspects or to bring people something better just without not getting anything from it. We have and will always mention the altruism being part of the free and libre culture, including the right to distribute derivative works without asking for permission, without doing even more work to even rework a whole copy of a project. If you see all of this different under the circumstances of copyrights and trademarks, is this surely your own perspective but not fitting the point of free and libre culture being kept working, dear readers  (//read [[https://web.archive.org/web/20250418101115/https://freedomdefined.org/Definition|here more about free culture]]//).
 +
 +In the end: If people think it is worthwhile to use "argumentum ad hominem"-argumentation to accuse Hyperbola as project for example to spread FUD (as noted here), we cannot do anything about except to point out that this does not compare to our motivation and the reality of our arguments. We like to work together, even when there are different perspectives and we also invite everybody to discuss with us so we can learn from each other. So it is up to the people themselves deciding, you may go on for sure accusing us or we can learn from each other.
  
 **Okay, more or less understood, but even when not on agreeing: Do you bother other projects then?** **Okay, more or less understood, but even when not on agreeing: Do you bother other projects then?**