Permalink
Browse files

Regenerate site.

  • Loading branch information...
1 parent dd1c937 commit 0b3af72d096c09ca73a1ccf482c0180a7ea85143 Brian Ford committed Mar 17, 2011
View
339 web/_site/2011/03/17/running-ruby-with-no-ruby/index.html
@@ -0,0 +1,339 @@
+<!DOCTYPE html>
+<html>
+ <head>
+ <title>Running Ruby With No Ruby - Rubinius</title>
+ <meta content='text/html;charset=utf-8' http-equiv='content-type'>
+ <meta content='en' http-equiv='content-language'>
+ <meta content='Rubinius is an implementation of the Ruby programming language. The Rubinius bytecode virtual machine is written in C++. The bytecode compiler is written in pure Ruby. The vast majority of the core library is also written in Ruby, with some supporting primitives that interact with the VM directly.' name='description'>
+ <meta content='Less Than Three. &lt;3. http://less.thanthree.com' name='author'>
+ <link href='/' rel='home'>
+ <link href='/' rel='start'>
+
+
+ <link href='/feed/atom.xml' rel='alternate' type='application/atom+xml' title='Rubinius Blog' />
+ <!--[if IE]><script src="http://html5shiv.googlecode.com/svn/trunk/html5.js" type="text/javascript"></script><![endif]-->
+ <script src="/javascripts/jquery-1.3.2.js" type="text/javascript"></script>
+ <script src="/javascripts/paging_keys.js" type="text/javascript"></script>
+
+ <script src="/javascripts/application.js" type="text/javascript"></script>
+ <style>article, aside, dialog, figure, footer, header, hgroup, menu, nav, section { display: block; }</style>
+
+ <link href="/stylesheets/blueprint/screen.css" media="screen" rel="stylesheet" type="text/css" />
+ <link href="/stylesheets/application.css" media="screen" rel="stylesheet" type="text/css" />
+ <link href="/stylesheets/blueprint/print.css" media="print" rel="stylesheet" type="text/css" />
+ <!--[if IE]><link href="/stylesheets/blueprint/ie.css" media="screen" rel="stylesheet" type="text/css" /><![endif]-->
+ <!--[if IE]><link href="/stylesheets/ie.css" media="screen" rel="stylesheet" type="text/css" /><![endif]-->
+ <link href="/stylesheets/pygments.css" media="screen" rel="stylesheet" type="text/css" />
+ </head>
+ <body>
+ <div class='container'>
+ <div class='span-21 blog_menu'>
+ <header>
+ <nav>
+ <ul>
+ <li><a href="/">Home</a></li>
+ <li><a id="blog" href="/blog/">Blog</a></li>
+ <li><a id="documentation" href="/doc/en/">Documentation</a></li>
+ <li><a href="/projects/">Projects</a></li>
+ <li><a href="/roadmap/">Roadmap</a></li>
+ <li><a href="/releases/">Releases</a></li>
+ </ul>
+ </nav>
+
+ </header>
+ </div>
+ <div class='span-3 last'>
+ <div id='version'>
+ <a href="/releases/1.2.3">1.2.3</a>
+ </div>
+ </div>
+
+ </div>
+
+ <div class="container posts_nav">
+ <nav>
+ <a href="/blog/posts_index/">Index of Posts</a>
+ <a id="feed_icon" href="/feed/atom.xml"><img alt="subscribe" src="/images/feed-icon16x16.png" /></a>
+ </nav>
+ </div>
+
+
+ <div class="container blog_posts">
+ <h2 class="post_title">Running Ruby With No Ruby</h2>
+
+ <div class="by_line">
+ <p><span class="author">Brian Ford</span>
+ <span class="date">17 March 2011</span>
+
+ </p>
+ </div>
+
+ <p>Humans have come a long way since our cave-dwelling days. No, that&rsquo;s not a
+metaphor for primitive software. I mean literally since we lived in caves. One
+of the big inventions is the lock. There are birds that bury food and will
+move it later if they notice they were watched burying it. But they have no
+access control. Any bird may come along and dig up the food.</p>
+
+<p>Humans, though, are smarter than the average bird.</p>
+
+<p>We have numerous systems that implement the analog of a lock, namely, some
+sort of access control. For every one of these systems, we have other systems
+that attempt to circumvent or defeat the access control. Two sides of the
+ubiquitous coin of life.</p>
+
+<p>In software, attempts to implement access control typically involve
+distinguishing between source code and some form of executable code. Direct
+access to the source code is not permitted. Further, the format of the
+executable code resists attempts to derive the source code. There are several
+reasons for this:</p>
+
+<ol>
+ <li><strong>Licenses:</strong> If a vendor licenses individual copies of the software, they
+want to prevent unrestricted copying of the software without paying for a
+license.</li>
+ <li><strong>Intellectual Property:</strong> A vendor may have trade secrets or other
+proprietary information that is disclosed by the source code.</li>
+ <li><strong>Security:</strong> Full access to the source code may reveal vulnerabilities in
+the software or related systems. This is sometimes called <em>Security Through
+Obscurity</em> and is generally disparaged, but things are not so black and
+white and there may be valid security concerns in the source code.</li>
+</ol>
+
+<p>The process that separates the source code from the executable program is
+typically a compilation step. However, Ruby code is not typically associated
+with any sort of compilation. That&rsquo;s one of the great things about Ruby,
+right? There is no <em>edit-compile-link-load</em> cycle to wait on. Just edit and run. But
+if there is no compilation step, how do we separate the source code from the
+executable code?</p>
+
+<p>You may recall from my <a href="http://rubini.us/2011/03/11/making-rubinius-rbc-files-disappear/">last
+post</a> that
+Rubinius does compile Ruby code to a bytecode format that the virtual machine
+executes. I also promised to explain how you could run the bytecode directly.</p>
+
+<p>But first, let me very clearly state that there are a number of caveats. In
+fact, I&rsquo;ve included a whole section on them below. Please read them. We will
+assume that you have and that you understand them. If you have any questions,
+please ask.</p>
+
+<h3 id="application-distribution-scenario">Application Distribution Scenario</h3>
+
+<p>Let&rsquo;s review what we would like to accomplish. We&rsquo;ll assume affable Abe is a
+developer writing an application for customer Cain.</p>
+
+<ol>
+ <li>Abe writes some Ruby code.</li>
+ <li>Abe compiles the code to a set of files.</li>
+ <li>Abe packages the files up into an application with no Ruby source.</li>
+ <li>Abe sends the application to Cain.</li>
+ <li>Cain installs the application.</li>
+ <li>Cain runs the application.</li>
+</ol>
+
+<p>In this scenario, I&rsquo;m assuming a very vague definition of application. In
+other words, the process below will fit in with a broad spectrum of bundling
+and distribution schemes.</p>
+
+<h3 id="application-layout">Application Layout</h3>
+
+<p>Let&rsquo;s assume that you have the following application layout. This mirrors what
+you would expect to see in a gem. You could also consider this as a subtree in
+your larger project.</p>
+
+<pre><code>widget
+|- lib
+|- widget.rb
+\- widget
+ |- red.rb
+ |- blue.rb
+ \- green.rb
+</code></pre>
+
+<div class="highlight"><pre><code class="ruby"><span class="lineno">1</span> <span class="c1"># widget.rb</span>
+<span class="lineno">2</span> <span class="nb">require</span> <span class="s1">&#39;widget/red&#39;</span>
+<span class="lineno">3</span> <span class="nb">require</span> <span class="s1">&#39;widget/blue&#39;</span>
+<span class="lineno">4</span> <span class="nb">require</span> <span class="s1">&#39;widget/gree&#39;</span>
+</code></pre>
+</div>
+
+<div class="highlight"><pre><code class="ruby"><span class="lineno">1</span> <span class="c1"># widget/red.rb</span>
+<span class="lineno">2</span> <span class="nb">puts</span> <span class="s2">&quot;I am red&quot;</span>
+</code></pre>
+</div>
+
+<div class="highlight"><pre><code class="ruby"><span class="lineno">1</span> <span class="c1"># widget/blue.rb</span>
+<span class="lineno">2</span> <span class="nb">puts</span> <span class="s2">&quot;I am blue&quot;</span>
+</code></pre>
+</div>
+
+<div class="highlight"><pre><code class="ruby"><span class="lineno">1</span> <span class="c1"># widget/green.rb</span>
+<span class="lineno">2</span> <span class="nb">puts</span> <span class="s2">&quot;I am green&quot;</span>
+</code></pre>
+</div>
+
+<h3 id="compiling-ruby-files">Compiling Ruby Files</h3>
+
+<p>The Rubinius bytecode compiler is accessible through a command-line script.
+See <code>rbx compile -h</code> for all options. We will only need one simple option in
+our case to easily create a separate tree containing one compiled file for
+every Ruby source file in our source tree.</p>
+
+<pre><code>rbx compile -s '^widget:widget-compiled' widget/
+</code></pre>
+
+<p>Let&rsquo;s dissect this command. The <code>-s</code> option defines a transformation to apply
+to every filename. The transformation has the form <code>&lt;source&gt;:&lt;destination&gt;</code>
+where <code>&lt;source&gt;</code> can be a Regexp. In our case, we would like to change any
+path starting with <code>widget</code> to start with <code>widget-compiled</code>. This way, we
+create a separate tree of our compiled files. The final option is the
+<code>widget/</code> directory. The <code>rbx compile</code> command will happily compile a single
+file or a directory of files. Note that if we did not pass the <code>-s</code> option,
+<code>rbx compile</code> would have created the compiled files alongside the source
+files.</p>
+
+<p>If we now look at <code>widget-compiled</code>, we should see the following:</p>
+
+<pre><code>widget-compiled
+|- lib
+|- widget.rbc
+\- widget
+ |- red.rbc
+ |- blue.rbc
+ \- green.rbc
+</code></pre>
+
+<h3 id="loading-pre-compiled-files">Loading Pre-compiled Files</h3>
+
+<p>Now that we have a separate tree of only compiled files, how do we load them?
+Well, first, let&rsquo;s load our source files so we know what to expect. Note that
+the technique used in this post should not substitute for a robust test suite.</p>
+
+<pre><code>$ rbx -Iwidget/lib -e "require 'widget/lib/widget'"
+I am red
+I am blue
+I am green
+</code></pre>
+
+<p>Ok, that is what I would expect. Now, to load the compiled files:</p>
+
+<pre><code>$ rbx -Iwidget-compiled/lib -e "Rubinius::CodeLoader.require_compiled 'widget/lib/widget'"
+I am red
+I am blue
+I am green
+</code></pre>
+
+<p><em>The crowed erupts with applause and hooting</em>.</p>
+
+<p>Golly gee, you guys&hellip; <em>Blush</em></p>
+
+<p>Let&rsquo;s review. Our goal is to take a tree of Ruby source files and create a
+tree of compiled files that can be sent to a customer and loaded to perform
+exactly as the Ruby source would if loaded directly. The most direct and
+simple way to accomplish this is to use the Rubinius compiler command-line
+script to compile the tree of Ruby source files to a separate tree. Then, load
+the root of that tree with <code>Rubinius::CodeLoader.require_compiled "root"</code>.</p>
+
+<h3 id="caveats">Caveats</h3>
+
+<p>I will admit, I have resisted fiercely against encouraging or even permitting
+Rubinius users from using what I showed above in their code. Not because I am
+an ogre who is trying to steal your fun, but because there are serious issues
+with allowing this. So, please read the following carefully.</p>
+
+<ol>
+ <li>We, Rubinius, absolutely reserve the right to change any part of the
+underlying compiled file mechanism. Since we are publishing the
+<code>Rubinius::CodeLoader.require_compiled(name)</code> method, we will respect that
+contract. What it says is, given a name, we will load a representation of
+that name. <em>DO NOT assume that <code>"some_file"</code> is actually referencing
+<code>"some_file.rbc"</code></em>. We may change the way compiled files are stored and may
+change the format of the compiled output.</li>
+ <li>We have created this facility to meet a need we had in Rubinius. Since our
+compiler is written in Ruby, we have to run Ruby to run the compiler. But
+since we need to compile Ruby to run it, we need to compile the compiler.
+But since&hellip; To handle this, we build the compiler using a bootstrapping
+version of Ruby. Then we load the pre-compiled compiler files as shown
+above. The approach is quite general, as demonstrated. However, a better
+approach may be appropriate for a particular application. In that case,
+talk to us about how you think it should work and we can point you in a
+direction to try implementing what you need.</li>
+ <li><strong>We assume no responsibility for any security breaches resulting from your
+incorrect assumption that .rbc files provides any meaningful security
+mechanism.</strong> I cannot stress this enough. The compiled file mechanism is a
+cache. It is a way to avoid recompiling Ruby source code that has not
+changed. The compiled format is simple. We reserve the right to provide
+disassemblers for our compiled code. We are happy to assist you with
+direction for implementing a more secure system for your needs.</li>
+ <li>There is no mechanism that is completely safe from cracking when it comes
+to software access control. Witness how often Microsoft&rsquo;s products have
+their security features defeated. Also witness how often attempts at DRM
+are circumvented. The most secure system I have seen uses a special
+compiler and a hardware dongle. The compiler takes critical parts of the
+application logic and breaks them up so that part of the computation is
+performed on the dongle. This is significantly harder to defeat than binary
+editing an executable to turn a license key check into a no-op. The folks
+you most want to keep from accessing your information are the ones most
+capable of doing so. Security and access control are very hard problems.</li>
+</ol>
+
+<h3 id="conclusion">Conclusion</h3>
+
+<p>Rubinius compiles Ruby code to bytecode before running it. It is possible to
+save the bytecode representation and reload it later. Using this mechanism, it
+is possible to avoid providing the Ruby source code and run an application
+directly from the compiled bytecode. The mechanism we use to do this was
+created to solve our problem of bootstrapping the Rubinius bytecode compiler,
+which is written in Ruby. The mechanism is not intended to be used for
+security.</p>
+
+<p>It is possible to extend the Rubinius code loading mechanism to support custom
+formats for on-disk compiled bytecode and to load those formats. This can be
+done entirely in Ruby code. If this interests you, please talk with us about
+it.</p>
+
+
+ <div id="disqus_thread"></div>
+<script type="text/javascript">
+ var disqus_shortname = 'rubinius';
+ var disqus_identifier = '/2011/03/17/running-ruby-with-no-ruby/';
+ var disqus_url = 'http://rubini.us/2011/03/17/running-ruby-with-no-ruby/';
+
+ (function() {
+ var dsq = document.createElement('script'); dsq.type = 'text/javascript'; dsq.async = true;
+ dsq.src = 'http://' + disqus_shortname + '.disqus.com/embed.js';
+ (document.getElementsByTagName('head')[0] || document.getElementsByTagName('body')[0]).appendChild(dsq);
+ })();
+</script>
+<noscript>Please enable JavaScript to view the <a href="http://disqus.com/?ref_noscript">comments powered by Disqus.</a></noscript>
+
+ </div>
+ <footer>
+ <div class='container'>
+ <nav>
+ <ul>
+ <li><a href="http://twitter.com/rubinius">Follow Rubinius on Twitter</a></li>
+ <li><a href="http://github.com/evanphx/rubinius">Fork Rubinius on github</a></li>
+ <li><a href="http://engineyard.com">An Engine Yard project</a></li>
+
+ <li id='credit'>
+ Site design by
+ <a href="http://less.thanthree.com">Less Than Three</a>
+ </li>
+ </ul>
+ </nav>
+ </div>
+ </footer>
+ <script type="text/javascript">
+ var gaJsHost = (("https:" == document.location.protocol) ? "https://ssl." : "http://www.");
+ document.write(unescape("%3Cscript src='" + gaJsHost + "google-analytics.com/ga.js' type='text/javascript'%3E%3C/script%3E"));
+ </script>
+
+ <script type="text/javascript">
+ try {
+ var pageTracker = _gat._getTracker("UA-12328521-1");
+ pageTracker._trackPageview();
+ } catch(err) {}</script>
+
+ </body>
+
+</html>
View
242 web/_site/blog/index.html
@@ -62,6 +62,248 @@
<div class="post">
<h2 class="post_title">
+ <a href="/2011/03/17/running-ruby-with-no-ruby/" title="Running Ruby With No Ruby" class="post_title">
+ Running Ruby With No Ruby
+ </a>
+ </h2>
+ <div class="by_line">
+ <p><span class="author">Brian Ford</span>
+ <span class="date">17 March 2011</span>
+
+ <a href="http://rubini.us/2011/03/17/running-ruby-with-no-ruby/#disqus_thread"
+ data-disqus-identifier="/2011/03/17/running-ruby-with-no-ruby/"></a>
+
+
+ </p>
+ </div>
+
+ <p>Humans have come a long way since our cave-dwelling days. No, that&rsquo;s not a
+metaphor for primitive software. I mean literally since we lived in caves. One
+of the big inventions is the lock. There are birds that bury food and will
+move it later if they notice they were watched burying it. But they have no
+access control. Any bird may come along and dig up the food.</p>
+
+<p>Humans, though, are smarter than the average bird.</p>
+
+<p>We have numerous systems that implement the analog of a lock, namely, some
+sort of access control. For every one of these systems, we have other systems
+that attempt to circumvent or defeat the access control. Two sides of the
+ubiquitous coin of life.</p>
+
+<p>In software, attempts to implement access control typically involve
+distinguishing between source code and some form of executable code. Direct
+access to the source code is not permitted. Further, the format of the
+executable code resists attempts to derive the source code. There are several
+reasons for this:</p>
+
+<ol>
+ <li><strong>Licenses:</strong> If a vendor licenses individual copies of the software, they
+want to prevent unrestricted copying of the software without paying for a
+license.</li>
+ <li><strong>Intellectual Property:</strong> A vendor may have trade secrets or other
+proprietary information that is disclosed by the source code.</li>
+ <li><strong>Security:</strong> Full access to the source code may reveal vulnerabilities in
+the software or related systems. This is sometimes called <em>Security Through
+Obscurity</em> and is generally disparaged, but things are not so black and
+white and there may be valid security concerns in the source code.</li>
+</ol>
+
+<p>The process that separates the source code from the executable program is
+typically a compilation step. However, Ruby code is not typically associated
+with any sort of compilation. That&rsquo;s one of the great things about Ruby,
+right? There is no <em>edit-compile-link-load</em> cycle to wait on. Just edit and run. But
+if there is no compilation step, how do we separate the source code from the
+executable code?</p>
+
+<p>You may recall from my <a href="http://rubini.us/2011/03/11/making-rubinius-rbc-files-disappear/">last
+post</a> that
+Rubinius does compile Ruby code to a bytecode format that the virtual machine
+executes. I also promised to explain how you could run the bytecode directly.</p>
+
+<p>But first, let me very clearly state that there are a number of caveats. In
+fact, I&rsquo;ve included a whole section on them below. Please read them. We will
+assume that you have and that you understand them. If you have any questions,
+please ask.</p>
+
+<h3 id="application-distribution-scenario">Application Distribution Scenario</h3>
+
+<p>Let&rsquo;s review what we would like to accomplish. We&rsquo;ll assume affable Abe is a
+developer writing an application for customer Cain.</p>
+
+<ol>
+ <li>Abe writes some Ruby code.</li>
+ <li>Abe compiles the code to a set of files.</li>
+ <li>Abe packages the files up into an application with no Ruby source.</li>
+ <li>Abe sends the application to Cain.</li>
+ <li>Cain installs the application.</li>
+ <li>Cain runs the application.</li>
+</ol>
+
+<p>In this scenario, I&rsquo;m assuming a very vague definition of application. In
+other words, the process below will fit in with a broad spectrum of bundling
+and distribution schemes.</p>
+
+<h3 id="application-layout">Application Layout</h3>
+
+<p>Let&rsquo;s assume that you have the following application layout. This mirrors what
+you would expect to see in a gem. You could also consider this as a subtree in
+your larger project.</p>
+
+<pre><code>widget
+|- lib
+|- widget.rb
+\- widget
+ |- red.rb
+ |- blue.rb
+ \- green.rb
+</code></pre>
+
+<div class="highlight"><pre><code class="ruby"><span class="lineno">1</span> <span class="c1"># widget.rb</span>
+<span class="lineno">2</span> <span class="nb">require</span> <span class="s1">&#39;widget/red&#39;</span>
+<span class="lineno">3</span> <span class="nb">require</span> <span class="s1">&#39;widget/blue&#39;</span>
+<span class="lineno">4</span> <span class="nb">require</span> <span class="s1">&#39;widget/gree&#39;</span>
+</code></pre>
+</div>
+
+<div class="highlight"><pre><code class="ruby"><span class="lineno">1</span> <span class="c1"># widget/red.rb</span>
+<span class="lineno">2</span> <span class="nb">puts</span> <span class="s2">&quot;I am red&quot;</span>
+</code></pre>
+</div>
+
+<div class="highlight"><pre><code class="ruby"><span class="lineno">1</span> <span class="c1"># widget/blue.rb</span>
+<span class="lineno">2</span> <span class="nb">puts</span> <span class="s2">&quot;I am blue&quot;</span>
+</code></pre>
+</div>
+
+<div class="highlight"><pre><code class="ruby"><span class="lineno">1</span> <span class="c1"># widget/green.rb</span>
+<span class="lineno">2</span> <span class="nb">puts</span> <span class="s2">&quot;I am green&quot;</span>
+</code></pre>
+</div>
+
+<h3 id="compiling-ruby-files">Compiling Ruby Files</h3>
+
+<p>The Rubinius bytecode compiler is accessible through a command-line script.
+See <code>rbx compile -h</code> for all options. We will only need one simple option in
+our case to easily create a separate tree containing one compiled file for
+every Ruby source file in our source tree.</p>
+
+<pre><code>rbx compile -s '^widget:widget-compiled' widget/
+</code></pre>
+
+<p>Let&rsquo;s dissect this command. The <code>-s</code> option defines a transformation to apply
+to every filename. The transformation has the form <code>&lt;source&gt;:&lt;destination&gt;</code>
+where <code>&lt;source&gt;</code> can be a Regexp. In our case, we would like to change any
+path starting with <code>widget</code> to start with <code>widget-compiled</code>. This way, we
+create a separate tree of our compiled files. The final option is the
+<code>widget/</code> directory. The <code>rbx compile</code> command will happily compile a single
+file or a directory of files. Note that if we did not pass the <code>-s</code> option,
+<code>rbx compile</code> would have created the compiled files alongside the source
+files.</p>
+
+<p>If we now look at <code>widget-compiled</code>, we should see the following:</p>
+
+<pre><code>widget-compiled
+|- lib
+|- widget.rbc
+\- widget
+ |- red.rbc
+ |- blue.rbc
+ \- green.rbc
+</code></pre>
+
+<h3 id="loading-pre-compiled-files">Loading Pre-compiled Files</h3>
+
+<p>Now that we have a separate tree of only compiled files, how do we load them?
+Well, first, let&rsquo;s load our source files so we know what to expect. Note that
+the technique used in this post should not substitute for a robust test suite.</p>
+
+<pre><code>$ rbx -Iwidget/lib -e "require 'widget/lib/widget'"
+I am red
+I am blue
+I am green
+</code></pre>
+
+<p>Ok, that is what I would expect. Now, to load the compiled files:</p>
+
+<pre><code>$ rbx -Iwidget-compiled/lib -e "Rubinius::CodeLoader.require_compiled 'widget/lib/widget'"
+I am red
+I am blue
+I am green
+</code></pre>
+
+<p><em>The crowed erupts with applause and hooting</em>.</p>
+
+<p>Golly gee, you guys&hellip; <em>Blush</em></p>
+
+<p>Let&rsquo;s review. Our goal is to take a tree of Ruby source files and create a
+tree of compiled files that can be sent to a customer and loaded to perform
+exactly as the Ruby source would if loaded directly. The most direct and
+simple way to accomplish this is to use the Rubinius compiler command-line
+script to compile the tree of Ruby source files to a separate tree. Then, load
+the root of that tree with <code>Rubinius::CodeLoader.require_compiled "root"</code>.</p>
+
+<h3 id="caveats">Caveats</h3>
+
+<p>I will admit, I have resisted fiercely against encouraging or even permitting
+Rubinius users from using what I showed above in their code. Not because I am
+an ogre who is trying to steal your fun, but because there are serious issues
+with allowing this. So, please read the following carefully.</p>
+
+<ol>
+ <li>We, Rubinius, absolutely reserve the right to change any part of the
+underlying compiled file mechanism. Since we are publishing the
+<code>Rubinius::CodeLoader.require_compiled(name)</code> method, we will respect that
+contract. What it says is, given a name, we will load a representation of
+that name. <em>DO NOT assume that <code>"some_file"</code> is actually referencing
+<code>"some_file.rbc"</code></em>. We may change the way compiled files are stored and may
+change the format of the compiled output.</li>
+ <li>We have created this facility to meet a need we had in Rubinius. Since our
+compiler is written in Ruby, we have to run Ruby to run the compiler. But
+since we need to compile Ruby to run it, we need to compile the compiler.
+But since&hellip; To handle this, we build the compiler using a bootstrapping
+version of Ruby. Then we load the pre-compiled compiler files as shown
+above. The approach is quite general, as demonstrated. However, a better
+approach may be appropriate for a particular application. In that case,
+talk to us about how you think it should work and we can point you in a
+direction to try implementing what you need.</li>
+ <li><strong>We assume no responsibility for any security breaches resulting from your
+incorrect assumption that .rbc files provides any meaningful security
+mechanism.</strong> I cannot stress this enough. The compiled file mechanism is a
+cache. It is a way to avoid recompiling Ruby source code that has not
+changed. The compiled format is simple. We reserve the right to provide
+disassemblers for our compiled code. We are happy to assist you with
+direction for implementing a more secure system for your needs.</li>
+ <li>There is no mechanism that is completely safe from cracking when it comes
+to software access control. Witness how often Microsoft&rsquo;s products have
+their security features defeated. Also witness how often attempts at DRM
+are circumvented. The most secure system I have seen uses a special
+compiler and a hardware dongle. The compiler takes critical parts of the
+application logic and breaks them up so that part of the computation is
+performed on the dongle. This is significantly harder to defeat than binary
+editing an executable to turn a license key check into a no-op. The folks
+you most want to keep from accessing your information are the ones most
+capable of doing so. Security and access control are very hard problems.</li>
+</ol>
+
+<h3 id="conclusion">Conclusion</h3>
+
+<p>Rubinius compiles Ruby code to bytecode before running it. It is possible to
+save the bytecode representation and reload it later. Using this mechanism, it
+is possible to avoid providing the Ruby source code and run an application
+directly from the compiled bytecode. The mechanism we use to do this was
+created to solve our problem of bootstrapping the Rubinius bytecode compiler,
+which is written in Ruby. The mechanism is not intended to be used for
+security.</p>
+
+<p>It is possible to extend the Rubinius code loading mechanism to support custom
+formats for on-disk compiled bytecode and to load those formats. This can be
+done entirely in Ruby code. If this interests you, please talk with us about
+it.</p>
+
+ </div>
+
+ <div class="post">
+ <h2 class="post_title">
<a href="/2011/03/11/making-rubinius-rbc-files-disappear/" title="Making Rubinius .rbc Files Disappear" class="post_title">
Making Rubinius .rbc Files Disappear
</a>
View
9 web/_site/blog/posts_index/index.html
@@ -55,6 +55,15 @@
<ul>
<li>
+ <a href="/2011/03/17/running-ruby-with-no-ruby/" title="Running Ruby With No Ruby" class="post_title"> Running Ruby With No Ruby </a>
+ <span class="author">Brian Ford</span>
+ <span class="date">17 March 2011</span>
+ <a href="http://rubini.us/2011/03/17/running-ruby-with-no-ruby/#disqus_thread"
+ data-disqus-identifier="/2011/03/17/running-ruby-with-no-ruby/"></a>
+
+ </li>
+
+ <li>
<a href="/2011/03/11/making-rubinius-rbc-files-disappear/" title="Making Rubinius .rbc Files Disappear" class="post_title"> Making Rubinius .rbc Files Disappear </a>
<span class="author">Brian Ford</span>
<span class="date">11 March 2011</span>
View
207 web/_site/doc/en/how-to/write-benchmarks/index.html
@@ -0,0 +1,207 @@
+<!DOCTYPE html>
+<html>
+ <head>
+ <title>How-To - Write Benchmarks - Rubinius</title>
+ <meta content='text/html;charset=utf-8' http-equiv='content-type'>
+ <meta content='en' http-equiv='content-language'>
+ <meta content='Rubinius is an implementation of the Ruby programming language. The Rubinius bytecode virtual machine is written in C++. The bytecode compiler is written in pure Ruby. The vast majority of the core library is also written in Ruby, with some supporting primitives that interact with the VM directly.' name='description'>
+ <meta content='Less Than Three. &lt;3. http://less.thanthree.com' name='author'>
+ <link href='/' rel='home'>
+ <link href='/' rel='start'>
+ <link href='/doc/en/how-to/fix-a-failing-spec' rel='prev' title='Fix a Failing Spec'>
+ <link href='/doc/en/how-to/write-a-blog-post' rel='next' title='Write a Blog Post'>
+
+ <!--[if IE]><script src="http://html5shiv.googlecode.com/svn/trunk/html5.js" type="text/javascript"></script><![endif]-->
+ <script src="/javascripts/jquery-1.3.2.js" type="text/javascript"></script>
+ <script src="/javascripts/paging_keys.js" type="text/javascript"></script>
+
+ <script src="/javascripts/application.js" type="text/javascript"></script>
+ <style>article, aside, dialog, figure, footer, header, hgroup, menu, nav, section { display: block; }</style>
+
+ <link href="/stylesheets/blueprint/screen.css" media="screen" rel="stylesheet" type="text/css" />
+ <link href="/stylesheets/application.css" media="screen" rel="stylesheet" type="text/css" />
+ <link href="/stylesheets/blueprint/print.css" media="print" rel="stylesheet" type="text/css" />
+ <!--[if IE]><link href="/stylesheets/blueprint/ie.css" media="screen" rel="stylesheet" type="text/css" /><![endif]-->
+ <!--[if IE]><link href="/stylesheets/ie.css" media="screen" rel="stylesheet" type="text/css" /><![endif]-->
+ <link href="/stylesheets/pygments.css" media="screen" rel="stylesheet" type="text/css" />
+ </head>
+ <body>
+ <div class='container'>
+ <div class='span-21 doc_menu'>
+ <header>
+ <nav>
+ <ul>
+ <li><a href="/">Home</a></li>
+ <li><a id="blog" href="/blog/">Blog</a></li>
+ <li><a id="documentation" href="/doc/en/">Documentation</a></li>
+ <li><a href="/projects/">Projects</a></li>
+ <li><a href="/roadmap/">Roadmap</a></li>
+ <li><a href="/releases/">Releases</a></li>
+ </ul>
+ </nav>
+
+ </header>
+ </div>
+ <div class='span-3 last'>
+ <div id='version'>
+ <a href="/releases/1.2.3">1.2.3</a>
+ </div>
+ </div>
+
+ </div>
+
+
+ <div class="container languages">
+ <nav>
+ <span class="label">Languages:</span>
+ <ul>
+
+ <li><a href="/doc/de/"
+
+ >de</a></li>
+
+ <li><a href="/doc/en/"
+
+ class="current"
+
+ >en</a></li>
+
+ <li><a href="/doc/es/"
+
+ >es</a></li>
+
+ <li><a href="/doc/ja/"
+
+ >ja</a></li>
+
+ <li><a href="/doc/pl/"
+
+ >pl</a></li>
+
+ <li><a href="/doc/ru/"
+
+ >ru</a></li>
+
+ </ul>
+ </nav>
+ </div>
+
+
+ <div class="container doc_page_nav">
+
+
+ <span class="label">Previous:</span>
+ <a href="/doc/en/how-to/fix-a-failing-spec">Fix a Failing Spec</a>
+
+
+ <span class="label">Up:</span>
+ <a href="/doc/en/">Table of Contents</a>
+
+
+ <span class="label">Next:</span>
+ <a href="/doc/en/how-to/write-a-blog-post">Write a Blog Post</a>
+
+
+ </div>
+
+
+ <div class="container documentation">
+ <h2>How-To - Write Benchmarks</h2>
+
+
+
+
+
+ <p>Why benchmarks?</p>
+
+<p>Benchmarks are a great tool for comparing Rubinius with the rest of the Ruby
+runtimes, i.e. MRI, JRuby, IronRuby and other implementations. It is not so
+much intended to measure Rubinius itself so if you want to contribute writing
+benchmarks make sure to follow these steps:</p>
+
+<ol>
+ <li>Find existing benchmarks in rubinius/benchmarks and study their layout.</li>
+ <li>Each benchmark file should measure one specific aspect of Ruby. For
+example different ways of deleting keys/values from a Hash.</li>
+ <li>Use the benchmark framework.</li>
+ <li>Keep the benchmarks short and simple.</li>
+ <li>The benchmarks are not meant to measure Rubinius. So if you&rsquo;re writing a
+benchmark for a class with bang and no-bang methods you will want to use
+a duplicate of a variable in the bang method but you don&rsquo;t need to dup
+in the no-bang method. </li>
+</ol>
+
+<p>If you want to test a benchmark you can run it file or even directory wise:</p>
+
+<pre><code>bin/benchmark benchmark/core/string/bench_case.rb
+bin/benchmark benchmark/core
+</code></pre>
+
+
+ </div>
+
+ <div class="container doc_page_nav">
+
+
+ <span class="label">Previous:</span>
+ <a href="/doc/en/how-to/fix-a-failing-spec">Fix a Failing Spec</a>
+
+
+ <span class="label">Up:</span>
+ <a href="/doc/en/">Table of Contents</a>
+
+
+ <span class="label">Next:</span>
+ <a href="/doc/en/how-to/write-a-blog-post">Write a Blog Post</a>
+
+
+ </div>
+
+
+ <div class="container">
+ <div id="disqus_thread"></div>
+<script type="text/javascript">
+ var disqus_shortname = 'rubinius';
+ var disqus_identifier = '/doc/en/how-to/write-benchmarks/';
+ var disqus_url = 'http://rubini.us/doc/en/how-to/write-benchmarks/';
+
+ (function() {
+ var dsq = document.createElement('script'); dsq.type = 'text/javascript'; dsq.async = true;
+ dsq.src = 'http://' + disqus_shortname + '.disqus.com/embed.js';
+ (document.getElementsByTagName('head')[0] || document.getElementsByTagName('body')[0]).appendChild(dsq);
+ })();
+</script>
+<noscript>Please enable JavaScript to view the <a href="http://disqus.com/?ref_noscript">comments powered by Disqus.</a></noscript>
+
+ </div>
+
+ <footer>
+ <div class='container'>
+ <nav>
+ <ul>
+ <li><a href="http://twitter.com/rubinius">Follow Rubinius on Twitter</a></li>
+ <li><a href="http://github.com/evanphx/rubinius">Fork Rubinius on github</a></li>
+ <li><a href="http://engineyard.com">An Engine Yard project</a></li>
+
+ <li id='credit'>
+ Site design by
+ <a href="http://less.thanthree.com">Less Than Three</a>
+ </li>
+ </ul>
+ </nav>
+ </div>
+ </footer>
+ <script type="text/javascript">
+ var gaJsHost = (("https:" == document.location.protocol) ? "https://ssl." : "http://www.");
+ document.write(unescape("%3Cscript src='" + gaJsHost + "google-analytics.com/ga.js' type='text/javascript'%3E%3C/script%3E"));
+ </script>
+
+ <script type="text/javascript">
+ try {
+ var pageTracker = _gat._getTracker("UA-12328521-1");
+ pageTracker._trackPageview();
+ } catch(err) {}</script>
+
+ </body>
+
+</html>
View
234 web/_site/feed/atom.xml
@@ -9,6 +9,240 @@
<entry>
+ <title>Running Ruby With No Ruby</title>
+ <id>http://rubini.us/2011/03/17/running-ruby-with-no-ruby/</id>
+ <link rel="alternate" type="text/html" href="http://rubini.us/2011/03/17/running-ruby-with-no-ruby/" />
+ <updated>2011-03-17T00:00:00+00:00</updated>
+ <author>
+ <name>Brian Ford</name>
+ </author>
+
+ <content type="html">&lt;p&gt;Humans have come a long way since our cave-dwelling days. No, that&amp;rsquo;s not a
+metaphor for primitive software. I mean literally since we lived in caves. One
+of the big inventions is the lock. There are birds that bury food and will
+move it later if they notice they were watched burying it. But they have no
+access control. Any bird may come along and dig up the food.&lt;/p&gt;
+
+&lt;p&gt;Humans, though, are smarter than the average bird.&lt;/p&gt;
+
+&lt;p&gt;We have numerous systems that implement the analog of a lock, namely, some
+sort of access control. For every one of these systems, we have other systems
+that attempt to circumvent or defeat the access control. Two sides of the
+ubiquitous coin of life.&lt;/p&gt;
+
+&lt;p&gt;In software, attempts to implement access control typically involve
+distinguishing between source code and some form of executable code. Direct
+access to the source code is not permitted. Further, the format of the
+executable code resists attempts to derive the source code. There are several
+reasons for this:&lt;/p&gt;
+
+&lt;ol&gt;
+ &lt;li&gt;&lt;strong&gt;Licenses:&lt;/strong&gt; If a vendor licenses individual copies of the software, they
+want to prevent unrestricted copying of the software without paying for a
+license.&lt;/li&gt;
+ &lt;li&gt;&lt;strong&gt;Intellectual Property:&lt;/strong&gt; A vendor may have trade secrets or other
+proprietary information that is disclosed by the source code.&lt;/li&gt;
+ &lt;li&gt;&lt;strong&gt;Security:&lt;/strong&gt; Full access to the source code may reveal vulnerabilities in
+the software or related systems. This is sometimes called &lt;em&gt;Security Through
+Obscurity&lt;/em&gt; and is generally disparaged, but things are not so black and
+white and there may be valid security concerns in the source code.&lt;/li&gt;
+&lt;/ol&gt;
+
+&lt;p&gt;The process that separates the source code from the executable program is
+typically a compilation step. However, Ruby code is not typically associated
+with any sort of compilation. That&amp;rsquo;s one of the great things about Ruby,
+right? There is no &lt;em&gt;edit-compile-link-load&lt;/em&gt; cycle to wait on. Just edit and run. But
+if there is no compilation step, how do we separate the source code from the
+executable code?&lt;/p&gt;
+
+&lt;p&gt;You may recall from my &lt;a href=&quot;http://rubini.us/2011/03/11/making-rubinius-rbc-files-disappear/&quot;&gt;last
+post&lt;/a&gt; that
+Rubinius does compile Ruby code to a bytecode format that the virtual machine
+executes. I also promised to explain how you could run the bytecode directly.&lt;/p&gt;
+
+&lt;p&gt;But first, let me very clearly state that there are a number of caveats. In
+fact, I&amp;rsquo;ve included a whole section on them below. Please read them. We will
+assume that you have and that you understand them. If you have any questions,
+please ask.&lt;/p&gt;
+
+&lt;h3 id=&quot;application-distribution-scenario&quot;&gt;Application Distribution Scenario&lt;/h3&gt;
+
+&lt;p&gt;Let&amp;rsquo;s review what we would like to accomplish. We&amp;rsquo;ll assume affable Abe is a
+developer writing an application for customer Cain.&lt;/p&gt;
+
+&lt;ol&gt;
+ &lt;li&gt;Abe writes some Ruby code.&lt;/li&gt;
+ &lt;li&gt;Abe compiles the code to a set of files.&lt;/li&gt;
+ &lt;li&gt;Abe packages the files up into an application with no Ruby source.&lt;/li&gt;
+ &lt;li&gt;Abe sends the application to Cain.&lt;/li&gt;
+ &lt;li&gt;Cain installs the application.&lt;/li&gt;
+ &lt;li&gt;Cain runs the application.&lt;/li&gt;
+&lt;/ol&gt;
+
+&lt;p&gt;In this scenario, I&amp;rsquo;m assuming a very vague definition of application. In
+other words, the process below will fit in with a broad spectrum of bundling
+and distribution schemes.&lt;/p&gt;
+
+&lt;h3 id=&quot;application-layout&quot;&gt;Application Layout&lt;/h3&gt;
+
+&lt;p&gt;Let&amp;rsquo;s assume that you have the following application layout. This mirrors what
+you would expect to see in a gem. You could also consider this as a subtree in
+your larger project.&lt;/p&gt;
+
+&lt;pre&gt;&lt;code&gt;widget
+|- lib
+|- widget.rb
+\- widget
+ |- red.rb
+ |- blue.rb
+ \- green.rb
+&lt;/code&gt;&lt;/pre&gt;
+
+&lt;div class=&quot;highlight&quot;&gt;&lt;pre&gt;&lt;code class=&quot;ruby&quot;&gt;&lt;span class=&quot;lineno&quot;&gt;1&lt;/span&gt; &lt;span class=&quot;c1&quot;&gt;# widget.rb&lt;/span&gt;
+&lt;span class=&quot;lineno&quot;&gt;2&lt;/span&gt; &lt;span class=&quot;nb&quot;&gt;require&lt;/span&gt; &lt;span class=&quot;s1&quot;&gt;&amp;#39;widget/red&amp;#39;&lt;/span&gt;
+&lt;span class=&quot;lineno&quot;&gt;3&lt;/span&gt; &lt;span class=&quot;nb&quot;&gt;require&lt;/span&gt; &lt;span class=&quot;s1&quot;&gt;&amp;#39;widget/blue&amp;#39;&lt;/span&gt;
+&lt;span class=&quot;lineno&quot;&gt;4&lt;/span&gt; &lt;span class=&quot;nb&quot;&gt;require&lt;/span&gt; &lt;span class=&quot;s1&quot;&gt;&amp;#39;widget/gree&amp;#39;&lt;/span&gt;
+&lt;/code&gt;&lt;/pre&gt;
+&lt;/div&gt;
+
+&lt;div class=&quot;highlight&quot;&gt;&lt;pre&gt;&lt;code class=&quot;ruby&quot;&gt;&lt;span class=&quot;lineno&quot;&gt;1&lt;/span&gt; &lt;span class=&quot;c1&quot;&gt;# widget/red.rb&lt;/span&gt;
+&lt;span class=&quot;lineno&quot;&gt;2&lt;/span&gt; &lt;span class=&quot;nb&quot;&gt;puts&lt;/span&gt; &lt;span class=&quot;s2&quot;&gt;&amp;quot;I am red&amp;quot;&lt;/span&gt;
+&lt;/code&gt;&lt;/pre&gt;
+&lt;/div&gt;
+
+&lt;div class=&quot;highlight&quot;&gt;&lt;pre&gt;&lt;code class=&quot;ruby&quot;&gt;&lt;span class=&quot;lineno&quot;&gt;1&lt;/span&gt; &lt;span class=&quot;c1&quot;&gt;# widget/blue.rb&lt;/span&gt;
+&lt;span class=&quot;lineno&quot;&gt;2&lt;/span&gt; &lt;span class=&quot;nb&quot;&gt;puts&lt;/span&gt; &lt;span class=&quot;s2&quot;&gt;&amp;quot;I am blue&amp;quot;&lt;/span&gt;
+&lt;/code&gt;&lt;/pre&gt;
+&lt;/div&gt;
+
+&lt;div class=&quot;highlight&quot;&gt;&lt;pre&gt;&lt;code class=&quot;ruby&quot;&gt;&lt;span class=&quot;lineno&quot;&gt;1&lt;/span&gt; &lt;span class=&quot;c1&quot;&gt;# widget/green.rb&lt;/span&gt;
+&lt;span class=&quot;lineno&quot;&gt;2&lt;/span&gt; &lt;span class=&quot;nb&quot;&gt;puts&lt;/span&gt; &lt;span class=&quot;s2&quot;&gt;&amp;quot;I am green&amp;quot;&lt;/span&gt;
+&lt;/code&gt;&lt;/pre&gt;
+&lt;/div&gt;
+
+&lt;h3 id=&quot;compiling-ruby-files&quot;&gt;Compiling Ruby Files&lt;/h3&gt;
+
+&lt;p&gt;The Rubinius bytecode compiler is accessible through a command-line script.
+See &lt;code&gt;rbx compile -h&lt;/code&gt; for all options. We will only need one simple option in
+our case to easily create a separate tree containing one compiled file for
+every Ruby source file in our source tree.&lt;/p&gt;
+
+&lt;pre&gt;&lt;code&gt;rbx compile -s '^widget:widget-compiled' widget/
+&lt;/code&gt;&lt;/pre&gt;
+
+&lt;p&gt;Let&amp;rsquo;s dissect this command. The &lt;code&gt;-s&lt;/code&gt; option defines a transformation to apply
+to every filename. The transformation has the form &lt;code&gt;&amp;lt;source&amp;gt;:&amp;lt;destination&amp;gt;&lt;/code&gt;
+where &lt;code&gt;&amp;lt;source&amp;gt;&lt;/code&gt; can be a Regexp. In our case, we would like to change any
+path starting with &lt;code&gt;widget&lt;/code&gt; to start with &lt;code&gt;widget-compiled&lt;/code&gt;. This way, we
+create a separate tree of our compiled files. The final option is the
+&lt;code&gt;widget/&lt;/code&gt; directory. The &lt;code&gt;rbx compile&lt;/code&gt; command will happily compile a single
+file or a directory of files. Note that if we did not pass the &lt;code&gt;-s&lt;/code&gt; option,
+&lt;code&gt;rbx compile&lt;/code&gt; would have created the compiled files alongside the source
+files.&lt;/p&gt;
+
+&lt;p&gt;If we now look at &lt;code&gt;widget-compiled&lt;/code&gt;, we should see the following:&lt;/p&gt;
+
+&lt;pre&gt;&lt;code&gt;widget-compiled
+|- lib
+|- widget.rbc
+\- widget
+ |- red.rbc
+ |- blue.rbc
+ \- green.rbc
+&lt;/code&gt;&lt;/pre&gt;
+
+&lt;h3 id=&quot;loading-pre-compiled-files&quot;&gt;Loading Pre-compiled Files&lt;/h3&gt;
+
+&lt;p&gt;Now that we have a separate tree of only compiled files, how do we load them?
+Well, first, let&amp;rsquo;s load our source files so we know what to expect. Note that
+the technique used in this post should not substitute for a robust test suite.&lt;/p&gt;
+
+&lt;pre&gt;&lt;code&gt;$ rbx -Iwidget/lib -e &quot;require 'widget/lib/widget'&quot;
+I am red
+I am blue
+I am green
+&lt;/code&gt;&lt;/pre&gt;
+
+&lt;p&gt;Ok, that is what I would expect. Now, to load the compiled files:&lt;/p&gt;
+
+&lt;pre&gt;&lt;code&gt;$ rbx -Iwidget-compiled/lib -e &quot;Rubinius::CodeLoader.require_compiled 'widget/lib/widget'&quot;
+I am red
+I am blue
+I am green
+&lt;/code&gt;&lt;/pre&gt;
+
+&lt;p&gt;&lt;em&gt;The crowed erupts with applause and hooting&lt;/em&gt;.&lt;/p&gt;
+
+&lt;p&gt;Golly gee, you guys&amp;hellip; &lt;em&gt;Blush&lt;/em&gt;&lt;/p&gt;
+
+&lt;p&gt;Let&amp;rsquo;s review. Our goal is to take a tree of Ruby source files and create a
+tree of compiled files that can be sent to a customer and loaded to perform
+exactly as the Ruby source would if loaded directly. The most direct and
+simple way to accomplish this is to use the Rubinius compiler command-line
+script to compile the tree of Ruby source files to a separate tree. Then, load
+the root of that tree with &lt;code&gt;Rubinius::CodeLoader.require_compiled &quot;root&quot;&lt;/code&gt;.&lt;/p&gt;
+
+&lt;h3 id=&quot;caveats&quot;&gt;Caveats&lt;/h3&gt;
+
+&lt;p&gt;I will admit, I have resisted fiercely against encouraging or even permitting
+Rubinius users from using what I showed above in their code. Not because I am
+an ogre who is trying to steal your fun, but because there are serious issues
+with allowing this. So, please read the following carefully.&lt;/p&gt;
+
+&lt;ol&gt;
+ &lt;li&gt;We, Rubinius, absolutely reserve the right to change any part of the
+underlying compiled file mechanism. Since we are publishing the
+&lt;code&gt;Rubinius::CodeLoader.require_compiled(name)&lt;/code&gt; method, we will respect that
+contract. What it says is, given a name, we will load a representation of
+that name. &lt;em&gt;DO NOT assume that &lt;code&gt;&quot;some_file&quot;&lt;/code&gt; is actually referencing
+&lt;code&gt;&quot;some_file.rbc&quot;&lt;/code&gt;&lt;/em&gt;. We may change the way compiled files are stored and may
+change the format of the compiled output.&lt;/li&gt;
+ &lt;li&gt;We have created this facility to meet a need we had in Rubinius. Since our
+compiler is written in Ruby, we have to run Ruby to run the compiler. But
+since we need to compile Ruby to run it, we need to compile the compiler.
+But since&amp;hellip; To handle this, we build the compiler using a bootstrapping
+version of Ruby. Then we load the pre-compiled compiler files as shown
+above. The approach is quite general, as demonstrated. However, a better
+approach may be appropriate for a particular application. In that case,
+talk to us about how you think it should work and we can point you in a
+direction to try implementing what you need.&lt;/li&gt;
+ &lt;li&gt;&lt;strong&gt;We assume no responsibility for any security breaches resulting from your
+incorrect assumption that .rbc files provides any meaningful security
+mechanism.&lt;/strong&gt; I cannot stress this enough. The compiled file mechanism is a
+cache. It is a way to avoid recompiling Ruby source code that has not
+changed. The compiled format is simple. We reserve the right to provide
+disassemblers for our compiled code. We are happy to assist you with
+direction for implementing a more secure system for your needs.&lt;/li&gt;
+ &lt;li&gt;There is no mechanism that is completely safe from cracking when it comes
+to software access control. Witness how often Microsoft&amp;rsquo;s products have
+their security features defeated. Also witness how often attempts at DRM
+are circumvented. The most secure system I have seen uses a special
+compiler and a hardware dongle. The compiler takes critical parts of the
+application logic and breaks them up so that part of the computation is
+performed on the dongle. This is significantly harder to defeat than binary
+editing an executable to turn a license key check into a no-op. The folks
+you most want to keep from accessing your information are the ones most
+capable of doing so. Security and access control are very hard problems.&lt;/li&gt;
+&lt;/ol&gt;
+
+&lt;h3 id=&quot;conclusion&quot;&gt;Conclusion&lt;/h3&gt;
+
+&lt;p&gt;Rubinius compiles Ruby code to bytecode before running it. It is possible to
+save the bytecode representation and reload it later. Using this mechanism, it
+is possible to avoid providing the Ruby source code and run an application
+directly from the compiled bytecode. The mechanism we use to do this was
+created to solve our problem of bootstrapping the Rubinius bytecode compiler,
+which is written in Ruby. The mechanism is not intended to be used for
+security.&lt;/p&gt;
+
+&lt;p&gt;It is possible to extend the Rubinius code loading mechanism to support custom
+formats for on-disk compiled bytecode and to load those formats. This can be
+done entirely in Ruby code. If this interests you, please talk with us about
+it.&lt;/p&gt;
+</content>
+ </entry>
+
+ <entry>
<title>Making Rubinius .rbc Files Disappear</title>
<id>http://rubini.us/2011/03/11/making-rubinius-rbc-files-disappear/</id>
<link rel="alternate" type="text/html" href="http://rubini.us/2011/03/11/making-rubinius-rbc-files-disappear/" />

0 comments on commit 0b3af72

Please sign in to comment.