{W,R}ewrite Toys SuperScaleSystems in Rust

SuperScaleSystems

URL at http://superscalesystems.ftp.sh

1. Pls read through and thorough understandably.

2. We call ourselves Toys because we write the rewrite of not-so-serious Toys utilities which are cross OS capable of running which is not seen in the market. Maybe due to different OS path differences. Though we try to redo/relearn the old stuff to make it new and renew. Thus try everything from every level of programmers around the world. And try to make up a new cross OS instead of making a new OS from ground up.

3. Toys try to leverage different OS capabilities and availability. Which means people may find one OS is more familiar to them or one OS is more available to patches or updates which could complete their compliance or requirements need.

4. Everyone can have a life while do their work in their OS level programming while everyone can co-joint the development of Toys so many lives can be sustained on top of raw OS into a more general cross OS. People live on people while nobody loses.

5. While hard problems like concurrency or multi-threading can leave to the backend kernel on top any-OS, the easier upper problem can be handled sequentially by Toys-level programs. It would be pleasurable if Toys could be concurrent and multi-threading as well anyway.

6. Toys could be inexpensive while valuable to sysadmins, since sysadmins may need to work cross OS within the same problem domain idea. While lacking the not-so-perfect utils across. Hopefully toys could fit in this.

7. Toys could be for newbies and experts. Some may try to hack the utilities to get admin rights while others may try to pipe some results through.

8. Toys could be for kids and adults. Some may try to (re)write while others try to (re)use all or some of the Toys for their systems.

9. Toys is To Operate Your Super Scale Systems. For example, linux, mswindows, macos, wasm.

10. Toys usually are basic cmdline utilities. {W,R}ewrite in Rust and try to be as cross OS as possible like Rust does, i.e. mswindows, linux, macos, iOS, Android, wasm.

11. Toys may not honor path-related handling, e.g. /mnt in linux/macos, C:\mnt in windows. Thus users may need to move/copy the output binary file from Toys to the designated destination before running anything.

12. Toys sometimes are GUI but maintain cross OS runnable. Maybe wasm as well.

13. Toys don't include or depend on other crates as crates are of unknown qualities and unknown support life. Dependencies clutter is most of the time resultant. Thus, un-update-able programs resulted which is not wanted in Toys.

14. Toys MAY include other Rust-written programs but which MUST NOT depend on any-other named dependencies crates within it. Use of Rust-included batteries is recommended, thus encouraged. Dependencies free is one of the goals of Toys. As long as your dependencies list is clear, you are cleared.

15. Toys most of the time may not be including any other Rust-written programs due to heavy crates.io dependencies.

16. {W,R}e-accept any levels of programming as long as no dependencies is concern about. Anything from real toys to real Toys sysadmins. It's not a problem if your first submission is rejected due to dependencies, just try to rewrite/redo it in your code. You will gain knowledge and clean up dependencies afterwards and would be accepted anyway. We expect re-submission which is acceptable and proper anyway anyhow.

17. {W,R}e-naming any Toys may subject to case by case (re)consideration at times, due to usage, habits, etc. Whatever factors/reasons we may find! Some may call discrete decision.

18. Toys are basic hello world at first like default Rust project does. The first thing to do should be a written test case for the hello world output.

19. If 3 months passed and non hello world contribution is not seen, that toys will be archived. Developers and contributors may try to find the treasure in the archive if any named binary or folder feels interesting to you, you may ask for unarchive of the respective toys.

20. Toys try to have a 6-month release cycle. Release format will be usually linux, mswindows binary and original source code on github.

21. Toys development git origin is github.

22. Toys are MIT or Apache-2.0 licensed.

23. Toys contributors and contributions are expected to be MIT or Apache-2.0 licensed as well. This is to be understood when you commit your code the very first time. As long as you are granted commit right, you agree with the terms and conditions in the mentioned license terms and thus abide by that or them.

24. Toys love y'all! Comments are welcome!