From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Original-To: caml-list@sympa.inria.fr Delivered-To: caml-list@sympa.inria.fr Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) by sympa.inria.fr (Postfix) with ESMTPS id F08EB81799 for ; Wed, 24 Jul 2013 09:03:53 +0200 (CEST) Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of fabrissimo@gmail.com) identity=pra; client-ip=209.85.220.48; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="fabrissimo@gmail.com"; x-sender="fabrissimo@gmail.com"; x-conformance=sidf_compatible Received-SPF: Pass (mail3-smtp-sop.national.inria.fr: domain of fabrissimo@gmail.com designates 209.85.220.48 as permitted sender) identity=mailfrom; client-ip=209.85.220.48; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="fabrissimo@gmail.com"; x-sender="fabrissimo@gmail.com"; x-conformance=sidf_compatible; x-record-type="v=spf1" Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of postmaster@mail-pa0-f48.google.com) identity=helo; client-ip=209.85.220.48; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="fabrissimo@gmail.com"; x-sender="postmaster@mail-pa0-f48.google.com"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag8DAAR871HRVdwwlWdsb2JhbABbhAvCCggWDgEBAQEHDQkJEiqCJAEBBAFAASgBDwEDAQsBBQULDS4iEgEFARwGEwgMh2oDCQaaeo9OhGcnDYhYAQUMk3UDl1+PaBYpgV2CXzo X-IPAS-Result: Ag8DAAR871HRVdwwlWdsb2JhbABbhAvCCggWDgEBAQEHDQkJEiqCJAEBBAFAASgBDwEDAQsBBQULDS4iEgEFARwGEwgMh2oDCQaaeo9OhGcnDYhYAQUMk3UDl1+PaBYpgV2CXzo X-IronPort-AV: E=Sophos;i="4.89,733,1367964000"; d="scan'208";a="22081333" Received: from mail-pa0-f48.google.com ([209.85.220.48]) by mail3-smtp-sop.national.inria.fr with ESMTP/TLS/RC4-SHA; 24 Jul 2013 09:03:48 +0200 Received: by mail-pa0-f48.google.com with SMTP id kp1so304996pab.35 for ; Wed, 24 Jul 2013 00:03:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=z95Jd5mGP4yaWKxxbSFGaWly/iHpTqOHeBE07ybDE3c=; b=UJt6HS/7lJy8JllMP8xAzc2rUHpiDW5lXOXxpxZHmvBNcRawkDoddmpLNvRxdxHCPy MbIKjkFRrGrPbccnmz7QAcnTzCEX5p6Y4pLThZZ1+hQWROZ1te9YcERhZwirE7FOhcsR X8h51ABqJSv3fk4/Ktholsq9Ec0m+TjjaXjvd4PmTZU/oP88DN2kOBKxUAHzGnbxJA4c AGaMwW74i+6bGNkUBUnrX/TY08BcbulbrKVu6v3t8Wru41XTrVuFs14o7+V49tAg9ysE tuSVYaGRKgHH47RhILgjK/R1SL7ECp7bZ9dyYlj6qn4lllDSlCe4MjjwVZA3ZtyJzhXu PPFQ== MIME-Version: 1.0 X-Received: by 10.68.252.137 with SMTP id zs9mr40573393pbc.60.1374649426419; Wed, 24 Jul 2013 00:03:46 -0700 (PDT) Sender: fabrissimo@gmail.com Received: by 10.68.109.227 with HTTP; Wed, 24 Jul 2013 00:03:46 -0700 (PDT) In-Reply-To: <51EF33FE.2060407@riken.jp> References: <1e141e2803d9dec6a8231dd4f16dd173.squirrel@gps.dynxs.de> <20130723090713.GA9274@notk.org> <51EF33FE.2060407@riken.jp> Date: Wed, 24 Jul 2013 09:03:46 +0200 X-Google-Sender-Auth: qaMyQafVjgTPETo4auyC3W5Ubbs Message-ID: From: Fabrice Le Fessant To: Francois Berenger Cc: Ocaml Mailing List Content-Type: multipart/alternative; boundary=047d7b2e4228c0a64704e23c8237 Subject: Re: [Caml-list] GODI is shutting down --047d7b2e4228c0a64704e23c8237 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Jul 24, 2013 at 3:55 AM, Francois Berenger wrote: > On 07/23/2013 06:07 PM, Adrien Nader wrote: > >> Hi, >> > > [...] > > To be honest, I've never understood why opam was "started". >> > > Contracted development, I guess. Yes, mostly. OCamlPro have had a contract with Jane Street since its creation, on improving the OCaml environment, to the benefits of both Jane Street and the whole OCaml community. The creation of a new package manager was identified very early as a strategic element, to improve the usability of OCaml, and increase its popularity. Thus, we started working on Opam, in a collaboration between OCamlPro and INRIA (within the DORM european project), with deep inputs from the Mancoosi team at University Paris 7/IRILL (working at improving Debian package management), and later joined by OCamllabs as soon as it was created. Of course, Opam would not have been the same without GODI: in its design, Opam directly benefited from the experience of GODI, as we tried to keep GODI's strengths and to find better alternatives to avoid its weaknesses. We also studied some other package managers, for OCaml (odb, yypkg, etc.) and for other languages/systems (Cabal, CPAN, ArchLinux, etc.). Finally, we made sure we would be able to easily port GODI's packages to Opam, as the number of available packages from the beginning is an important criteria for adoption of a package management tool by end users. Clearly, both GODI and Opam are technically challenging software, but they are not focusing on solving the same technical challenges (as explained by Thomas), although the functionalities they provide are globally similar. As a side story, 15 years ago, I wrote one of the first open-source video players for Divx files on Linux, in C++ with optimized MMX/SSE assembly routines for zooming and so on. I was particularly proud of it, as it was a domain in which I had little experience (but great interest ;-) ). I got a few hundred users, when mplayer was released and all my users progressively switched to it. Mplayer had support for some more video formats (but nothing I could not implement), and some of my assembly routines were much more efficient. Nonetheless, since then, I have been a happy user of mplayer, and it is now much better technically than whatever I could have done with my own player. This is typical of the software world, older projects are superseded by new projects, not always better on all technical grounds, but providing a different user experience or pushed by a larger team of developers. --Fabrice --047d7b2e4228c0a64704e23c8237 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Wed, Jul 24, 2013 at 3:55 AM, Francois Berenger <beren= ger@riken.jp> wrote:
On 07/23/2013 06:07 PM, Adrien Nader wrote:<= br>
Hi,
> [...]

To be honest, I've never understood why opam was "started".

Contracted development, I guess.

Yes, mostl= y. OCamlPro have had a contract with Jane Street since its creation, on imp= roving the OCaml environment, to the benefits of both Jane Street and the w= hole OCaml community. The creation of a new package manager was identified = very early as a strategic element, to improve the usability of OCaml, and i= ncrease its popularity. Thus, we started working on Opam, in a collaboratio= n between OCamlPro and INRIA (within the DORM european project), with deep = inputs from the Mancoosi team at University Paris 7/IRILL (working at impro= ving Debian package management), and later joined by OCamllabs as soon as i= t was created.

Of course, Opam would not have been the same without GO= DI: in its design, Opam directly benefited from the experience of GODI, as = we tried to keep GODI's strengths and to find better alternatives to av= oid its weaknesses. We also studied some other package managers, for OCaml = (odb, yypkg, etc.) and for other languages/systems (Cabal, CPAN, ArchLinux,= etc.). Finally, we made sure we would be able to easily port GODI's pa= ckages to Opam, as the number of available packages from the beginning is a= n important criteria for adoption of a package management tool by end users= .

Clearly, both GODI and Opam are technically challenging= software, but they are not focusing on solving the same technical challeng= es (as explained by Thomas), although the functionalities they provide are = globally similar.

As a side story, 15 years ago, I wrote one of the first= open-source video players for Divx files on Linux, in C++ with optimized M= MX/SSE assembly routines for zooming and so on. I was particularly proud of= it, as it was a domain in which I had little experience (but great interes= t ;-) ). I got a few hundred users, when mplayer was released and all my us= ers progressively switched to it. Mplayer had support for some more video f= ormats (but nothing I could not implement), and some of my assembly routine= s were much more efficient. Nonetheless, since then, I have been a happy us= er of mplayer, and it is now much better technically than whatever I could = have done with my own player. This is typical of the software world, older = projects are superseded by new projects, not always better on all technical= grounds, but providing a different user experience or pushed by a larger t= eam of developers.

--Fabrice
=A0
--047d7b2e4228c0a64704e23c8237--