New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
What language is rakudo written in? #599
Comments
|
I want to see full path of building rakudo. I. e. to build rakudo you need such and such compilers and interpreters. And to build them you need such and such etc, etc. Then we will eventually get to perl 5 and what next? What language perl 5 written in? Do we need in any point in this path to run some untrusted binary or some unreadable generated text file? Is this possible to build rakudo using only human-written non-generated text files and C and C++ compilers and nothing more? |
|
For example, we have C and C++ compilers, human-written perl 5 and perl 6 sources without any untrusted generated files (both binary and text). Is this possible to build trusted rakudo binary from this? Not vulnerable to trusting trust ( http://www.ece.cmu.edu/~ganger/712.fall02/papers/p761-thompson.pdf ) attack in perl? (Of course, perl will still be vulnerable to trusting trust attack coming from C and C++ compilers, but is it vulnerable to perl trusting trust attack?) |
|
The details of the compiler called Rakudo are an implementation detail and should be explained at the compilers homepage. The docs document the language Perl 6 and will cover implementations only briefly. It's reference point is roast not Rakudo. |
|
I don't think exact compile time requirements belong in either the faq or Most users are expected to compile using Rakudo Star and this information Maybe some top level details about rakudo implementation could be a new There is a binary blob used to bootstrap at one of the levels (either NQP On 16 June 2016 at 04:05, Wenzel P. P. Peppmeyer notifications@github.com
4096R/EA75174B Steve Mynott steve.mynott@gmail.com |
Also, the git history can, I believe, be used to trace all the source that led to those blobs (and reproduce them), should anyone want to do that. |
|
In any case, I think we should have an answer for that question in FAQ (because it is a frequently asked question). It's fine if the answer is just a link to rakudo.org or whatever. |
"I believe"? Eh? Did anyone really tried to reproduce this? Some reproducing instructions should be published. So that anyone can perform security audit of human-readable sources and then build them |
|
If I knew somebody had, I wouldn't have had to qualify it with "I believe". :-) I'd be happy to point anyone who wants to work on reproducing it and documenting the process in the right direction. |
And this is bad. Whole GNU/Linux should be boostrappable from C and C++ |
|
I'm confused, Perl 6 is nothing to do with GNU/Linux. |
|
Out of curiosity, can you cite a published reference for "Whole GNU/Linux should be bootstrappable from C and C++"? Is this personal opinion, or is it a widely adopted philosophy that is itself documented somewhere and that I've been largely unaware of? |
|
These are technical issues not political/licence issues. https://en.wikipedia.org/wiki/Bootstrapping_(compilers)#The_chicken_and_egg_problem explains some of the issues of self hosting compilers. As for UNIX-type systems (of which Linux is one) a small % of kernel code On 16 June 2016 at 23:53, Askar Safin notifications@github.com wrote:
4096R/EA75174B Steve Mynott steve.mynott@gmail.com |
|
To return to the original poster's request for a FAQ entry, here's a short blurb about Rakudo Perl 6's source code: Q: What language is Rakudo written in? A2: The more detailed answer is that Rakudo is written as a mixture of Perl 6 and NQP ("Not Quite Perl"). NQP is a lightweight Perl 6-like environment for virtual machines; it's designed to be a high-level way to create compilers and libraries for virtual machines (such as MoarVM and JVM) using Perl 6 syntax. Thus programs written for NQP are also (theoretically) valid Perl 6. Then the question naturally becomes "What language is NQP written in?" NQP source is a mixture of (1) NQP code, (2) whatever language the underlying virtual machine is using, (3) some third-party C and Java libraries, and (4) some bootstrapping files created by earlier runs of the build process. |
|
Does anybody want to improve http://doc.perl6.org/language/faq#What_language_is_Rakudo_written_in%3F or we can say that it's OK? |
Well, yes, but it is used on GNU/Linux.
First of all, this is my opinion. :) Also, I will provide some references. The page https://wiki.debian.org/UpstreamGuide#Bootstrapping.2FCrossbuilding_Language_Compilers.2FInterpreters from Debian wiki says:
Please, read whole this section. Then (bold is mine):
It seems page authors mean Perl 5 here, and this is bad for Perl 5. Then that wiki page says "There are a number of ways to achieve above requirements" and presents 3 options. They imply that current Perl 6 situation (i. e. we need some bootstrapping files from previous builds) is not acceptable. One of this options is the following:
Do you see? "Identify". You should not just say "we have some snapshots, I believe this is possible to bootstrap Perl 6 from them". You should identify what snapshots one can use to build trust path. Also, let me point to "Reflections on Trusting Trust" ( http://www.ece.cmu.edu/~ganger/712.fall02/papers/p761-thompson.pdf ) and @david-a-wheeler's "Fully Countering Trusting Trust through Diverse Double-Compiling" ( http://www.dwheeler.com/trusting-trust/ ), which broadly discusses trusting trust attack. (I was not able to find "everything should be bootstrappable from C and C++" guideline in this texts, through.) |
|
Thanks for the mention. Sadly, it is possible to slip malicious code into compilers and make the problem self-perpetuating. The good news is that there is a countermeasure, as explained in my paper "Fully Countering Trusting Trust through Diverse Double-Compiling" ( http://www.dwheeler.com/trusting-trust/ ). However, the counter measure requires a second compiler that you have reason to believe is unlikely to be subverted the same way the first compiler might be. It doesn't require C or C++ specifically, but it does require a second compiler that is relatively independent. The good news is that the second compiler does not have to be fast or have lots of extra functionality, it just has to be good enough to provide a check on the other compiler. Take a look at my paper for details. |
|
I think I that Rakudo most likely fits the second of the 3 options presented, namely:
This is exactly what NQP is -- a mini version of the Perl 6 language that Rakudo is written in. NQP is a "mini" version of Perl 6; more notably, it's explicitly designed to enable cross-compilation and facilitate porting to other platforms/backends. The MoarVM and JVM flavors of NQP and Rakudo were created by cross-compiling from the Parrot one. So while there will likely be a few pedantic nits, I think there's a good case to be made that Rakudo already meets much of Debian's guide here -- both by taking the mini version path and by supporting (and having repeatedly demonstrated) a viable form of cross-compilation for Rakudo. Also, to follow-on to David Wheeler's comment: This is an excellent example of a reason to avoid labeling Rakudo as the "official" or "only" Perl 6 compiler. We explicitly recognize that it's valuable, useful, and important to have multiple independent implementations of Perl 6 (e.g., Niecza). |
|
Good to hear about NQP. I would urge you to include bootstrapping and the "compiler bootstrap test" as part of your automated test suite. It's not at all unusual to forget to test it, and over time the compiler loses its ability to be bootstrapped by anything else. If you go that far, it would be great if you would also do the diverse double compiling test... it requires that the compiler be deterministic, but you want that anyway, since non-deterministic compilers are a pain to debug. If you decide to apply diverse double compiling and have problems, or complete it, let me know. |
|
This is an interesting conversation, but the take away for the docs is @pmichaud's Q/A at #599 (comment) I think we can close this ticket if that's added to the faq - and I think A1 is a reasonable level of detail for the docs site. |
|
I think A1 is not enough as it opens more questions than it answers. But we can start with A1 and see how it goes. |
|
This question is already answered with a minimal amount of detail in the FAQ, and has been since 2776b19 (though it's been updated since then.) Closing this ticket. |
I've seen this question many times. I think that we need an answer in our FAQ.
The text was updated successfully, but these errors were encountered: