<br><br><div class="gmail_quote">On Sat, Feb 14, 2009 at 9:29 PM, Tim Watson <span dir="ltr"><<a href="mailto:watson.timothy@gmail.com">watson.timothy@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="Ih2E3d">><br>
> I am using sinan/faxien exclusively, and have installed and maintained four<br>
> Erlang production systems with them. There were some teething issues, some<br>
<br>
</div>This is interesting - I also started out with good feelings about<br>
sinan/faxien, but they appear to redistribute the core OTP libraries<br>
which is anathema where I work. </blockquote><div><br>Martin & Eric can speak for themselves, but my point of view is that, well, they don't really redistribute them <i>as such</i>. They are forced to build them using their own tools and put them in their WebDAV repository because (a) The OTP team doesn't support such a repository, and (b) they have to make minor tweaks to the add their metadata, which is necessary for the distribution mechanism. The metadata doesn't exist - or, in the case of .app files, sometimes doesn't quite fit in - in the OTP distribution. I am pretty (99%) sure there is no fiddling with the source code at all, it's just an alternative way to build it, no more suspicious than building OTP from the tarball. If there was a way to build OTP with their (Erlware) tools in a 100% automated way, then anyone could do it, but they are not quite there yet (as far as I know). So that is indeed a sticking point, I can see.<br>
<br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">We're simply not allowed (by law) to<br>
run code on "some version" of kernel/stdlib/etc that didn't come from<br>
a verified (official) sources, even if it did in reality (if you see<br>
what I mean). This is an issue of regulatory compliance, so we're<br>
stuck and can't use the tools, which are (I agree) very nice bar some<br>
minor usability issues. I suspect this puts a lot of people off - it's<br>
not as maven downloads and installs the JDK for you is it, and for<br>
good reason - I'd be surprised if that many people actually wanted<br>
this.<br>
<br>
Clearly there are mixed opinions about whether a repository for<br>
publishing applications and a distributed build system that can<br>
consume code from public/private repos, is a good approach. That's to<br>
be expected, but this idea of redistributing "Erlang itself" is<br>
another thing altogether. It seems like trying to force too many new<br>
ideas at once, and I suspect this is a big part of the problem.</blockquote><div> </div><div>Again, I believe they don't WANT to redistribute Erlang. It's a huge pain in the butt to have to tweak new Erlang releases to build with their toolset, and it's not really the fault of their toolset, it's just minor inconsistencies here and there that cause issues. If they could get it right that anyone could build Erlang itself using Sinan, and then put it in their own private Erlware repo with Faxien, these objections would largely go away.<br>
</div></div><br>If you look at what Ruby has managed to achieve with Gems, and (I think) Python with "eggs", it is quite reasonable to expect that we should be able to distribute our own Erlang apps in a pre-built form in a way that makes it really easy to update. I use this mechanism to update production servers in a number of different countries, and the previous way I did it was just horrible. It's so much easier for me just to log into the remote server, type in "faxien upgrade-release myapp", maybe tweak the sys.config, and then restart the application (I don't need hot code update yet). The sad thing is that Erlware is *so* close to being really great, and is held back mostly because the authors are so busy actually earning a living that they don't have enough time to devote to ironing out the wrinkles.<br>
<br>My great hope is that the Erlang/OTP team will see enough merit in this approach to make this a standard distribution mechanism, but I don't hold out much hope (not because the team is unreasonable or anything, but because of the overhead of supporting builds across many hardware platforms and version within the platforms.) An easier and even better thing would be if they actually used Erlware to build the Erlang source code; then we could all build it with Erlware and the main objection would be solved. Also, they could put some resources on it to help with the wrinkles.<br>
<br>Just dreaming ;)<br><br>