Order-sorted feature (OSF) terms generalize first-order rational terms: functors become partially ordered sorts, arity is unconstrained, and subterms are unordered, indicated by explicit feature symbols rather than implicit positions. Thus, OSF terms provide a handy data structure to represent objects in symbolic programming languages. LIFE is such an experimental language extending Prolog by replacing its term data structure and unification operation with OSF term and unification. In this paper, we present an abstract machine design for OSF term unification. This compiling scheme consists of an alteration of recent refinements of WAM technology for compiling Prolog's unification. Our modifications account for order-sortedness, symbolic features, and absence of arity. Then, we improve that design by incorporating several immediate optimizations.

This paper reports on skeleton-based parallel programming in the context of the Caml functional language. An experimental implementation, based on TCP sockets and marshaling of function closures, is described and assessed.

In the mainstream adoption of free and open source software (FOSS), distribution editors play a crucial role: they package, integrate and distribute a wide variety of software, written in a variety of languages, for a variety of purposes of unprecedented breadth. Ensuring the quality of a FOSS distribution is a technical and engineering challenge, owing to the size and complexity of these distributions (tens of thousands of software packages). A number of original topics for research arise from this challenge. This paper is a gentle introduction to this new research area, and strives to clearly and formally identify many of the desirable properties that must be enjoyed by these distributions to ensure an acceptable quality level.

Tarski asked whether the arithmetic identities taught in high school are complete for showing all arithmetic equations valid for the natural numbers. The answer to this question for the language of arithmetic expressions using a constant for the number one and the operations of product and exponentiation is affirmative, and the complete equational theory also characterises isomorphism in the typed lambda calculus, where the constant for one and the operations of product and exponentiation respectively correspond to the unit type and the product and arrow type constructors. This paper studies isomorphisms in typed lambda calculi with empty and sum types from this viewpoint. Our main contribution is to show that a family of so-called Wilkie-Gurevic identities, that plays a pivotal role in the study of Tarski's high school algebra problem, arises from type-theoretic isomorphisms. We thus close an open problem by establishing that the theory of type isomorphisms in the presence of product, arrow, and sum types (with or without the unit type) is not finitely axiomatisable. Further, we observe that for type theories with arrow, empty and sum types the correspondence between isomorphism and arithmetic equality generally breaks down, but that it still holds in some particular cases including that of type isomorphism with the empty type and equality with zero.

The open-source software community is now comprised of a very large and growing number of contributors and users. The GNU/Linux operating system for instance has an estimated 18 million users worldwide and its contributing developers can be counted by thousands. The critical mass of contributors taking part in various opensource projects has helped to ensure high quality for open source software. However, despite the achievements of the open-source software industry, there are issues in the production of large scale open-source software (OSS) such as the GNU/Linux operating system that have to be addressed as the numbers of users, of contributors, and of available applications grow. EDOS is a European project supported by IST started October 2004 and ending in 2007, whose objective is to provide a new generation of methodologies, theoretical models, technical tools and quality models specifically tailored to OSS engineering and to software distribution over the Internet.

Determining whether two or more packages cannot be installed together is an important issue in the quality assurance process of package-based distributions. Unfortunately, the sheer number of different configurations to test makes this task particularly challenging, and hundreds of such incompatibilities go undetected by the normal testing and distribution process until they are later reported by a user as bugs that we call “conflict defects”. We performed an extensive case study of conflict defects extracted from the bug tracking systems of Debian and Red Hat. According to our results, conflict defects can be grouped into five main categories. We show that with more detailed package meta-data, about 30 % of all conflict defects could be prevented relatively easily, while another 30 % could be found by targeted testing of packages that share common resources or characteristics. These results allow us to make precise suggestions on how to prevent and detect conflict defects in the future.

Modern software systems, like GNU/Linux distributions or Eclipse-based development environment, are often deployed by selecting components out of large component repositories. Maintaining such software systems by performing component upgrades is a complex task, and the users need to have an expressive preferences language at their disposal to specify the kind of upgrades they are interested in. Recent research has shown that it is possible to develop solvers that handle preferences expressed as a combination of a few basic criteria used in the MISC competition, ranging from the number of new components to the freshness of the final configuration. In this work we introduce a set of new criteria that allow the users to specify their preferences for solutions with components aligned to the same upstream sources, provide an efficient encoding and report on the experimental results that prove that optimising these alignment criteria is a tractable problem in practice.

Context The success of modern software distributions in the Free and Open Source world can be explained, among other factors, by the availability of a large collection of software packages and the possibility to easily install and remove those components using state-of-the-art package managers. However, package managers are often built using a monolithic architecture and hard-wired and ad-hoc dependency solvers implementing some customized heuristics. Objective We aim at laying the foundation for improving on existing package managers. Package managers should be complete, that is find a solution whenever there exists one, and allow the user to specify complex criteria that define how to pick the best solution according to the user s preferences. Method In this paper we propose a modular architecture relying on precise interface formalisms that allows the system administrator to choose from a variety of dependency solvers and backends. Results We have built a working prototype, called MPM, following the design advocated in this paper, and we show how it largely outperforms a variety of current package managers. Conclusion We argue that a modular architecture, allowing for delegating the task of constraint solving to external solvers, is the path that leads to the next generation of package managers that will deliver better results, offer more expressive preference languages, and be easily adaptable to new platforms.

This paper describes in detail an attack on multiple-choice voting schemas, that has gone largely unnoticed in the literature. Written in 2006, to complement my original Wikipedia article dating back to January 2005, it is still unpublished up to now: I did not find yet the necessary energy to go through the process of getting it accepted in the scholar community working on security, which is not my research domain. And yet, it is probably my most referenced and more influential article to date (just Google it around a bit).

Software is a fundamental pillar of modern scientific research, across all fields and disciplines. However, there is a lack of adequate means to cite and reference software due to the complexity of the problem in terms of authorship, roles, and credits. This complexity is further increased when it is considered over the lifetime of a software that can span up to several decades. Building upon the internal experience of Inria, the French research institute for digital sciences, we provide in this article a contribution to the ongoing efforts in order to develop proper guidelines and recommendations for software citation and reference. Namely, we recommend: first, a richer taxonomy for software contributions with a qualitative scale; second, to put humans at the heart of the evaluation; and third, to distinguish citation from reference.

Among the entities involved in software citation, software source code requires special attention, due to the role it plays in ensuring scientific reproducibility. To reference source code we need identifiers that are not only unique and persistent, but also support integrity checking intrinsically. Suitable iden- tifiers must guarantee that denoted objects will always stay the same, without relying on external third parties and administrative processes. We analyze the role of identifiers for digital objects (IDOs), whose properties are different from, and complementary to, those of the various digital identifiers of objects (DIOs) that are today popular building blocks of software and data citation toolchains. We argue that both kinds of identifiers are needed and detail the syntax, semantics, and practical implementation of the persistent identifiers (PIDs) adopted by the Software Heritage project to reference billions of software source code artifacts such as source code files, directories, and commits.

This article provides a full report on the effort to reproduce the work described in the article “Parallel Functional Programming with Skeletons: the OCamlP3L experiment”, written in 1998. It presented OCamlP3L, a parallel programming system written in the OCaml programming language. It turns out that we found the source code of the OCamlP3L system only in Software Heritage: since it was saved with all its development history, we could perform this reproduction experiment.

La première forge logicielle, appelée SourceForge, a été lancée en 1999 et a été conçue pour aider les développeurs de logiciels libres à créer leurs logiciels en collaboration et à les distribuer à leurs utilisateurs. Depuis lors, les forges logicielles sont devenues des outils essentiels pour tous les développeurs de logiciels. Elles disposent d'outils de développement collaboratif (suivi des modifications du code, gestion des tickets utilisateurs, des contributions et des projets) et industrialisent le processus de création de logiciels à partir de leurs codes sources (compilation, tests automatisés, assurance qualité et distribution des livrables) et d'outils de communication tels que les forums. Les forges logicielles agissent également comme des réseaux sociaux pour les développeurs. Lorsque les développeurs souhaitent encourager les gens à utiliser les logiciels et à y contribuer, ils doivent décider de la forge à choisir en fonction du public cible et du réseau. Cibler les développeurs de l'enseignement supérieur et de la recherche en France ou à l'étranger est une option potentielle. Il existe un certain nombre de fédérations d'identité telles que RENATER ou eduGAIN qui ont apporté un soutien à long terme à ces collaborations. Un certain nombre de forges de l'enseignement supérieur et de la recherche donnent accès à ces réseaux de collaboration. Si un développeur souhaite ouvrir et partager les codes sources issus de la recherche avec la société dans son ensemble, deux solutions s'offrent à lui : les forges communautaires à source ouverte ou les forges commerciales. Les forges communautaires à code source ouvert peuvent être utilisées pour distribuer des logiciels à code source ouvert au sein d'une communauté qui a coopéré avec les autres membres de la communauté.

The first software forge, called SourceForge, was launched in 1999, and was designed to help open-source software developers build their software collaboratively and distribute it to their users. Since then, software forges have become vital tools for all software developers. They feature collaborative development tools (for monitoring code modifications, and managing user tickets, contributions and projects) and they industrialise the process of creating software from their source codes (compilation, automated tests, quality assurance and distribution of deliverables) and communications tools such as forums. Software forges also act as social networks for developers. Whenever developers want to encourage people to use and make contributions to software, they need to come to a decision about which forge to choose based on the target audience and network. Targeting Higher Education and Research developers in France or abroad is one potential option. There are a number of identity federations such as RENATER or eduGAIN which have been providing long-term support for these collaborations. A number of Higher Education and Research forges provide access to these collaboration networks. Should a developer wish to open and share source codes coming from research with the wider society, there are two alternatives available to them - open-source community or commercial forges. Open-source community forges can be used to distribute open-source software within a community which has co-opted it. The challenge here lies in finding the right community for the software under development. Commercial forges boast many features with very few constraints, and often offer a range of services when the developed software is distributed under an open-source licence. Thesecommercial forges include GitHub (owned by Microsoft), which is the most widely used, followed by BitBucket (owned by Atlassian) and GitLab (owned by GitLab Inc.). Some forges, be they community-based or commercial, such as GitLab, can be self-hosted by Higher Education and Research Institutions, some of which have their own public forge. This report lists 40 of these types of forge as well as the forges for internal use only. These self-hosted forges are often easy to install, ranging from a simple executable for solutions such as Gogs, Gitea and Forgejo to a preconfigured software package integrated into Linux distribution for GitLab, for example. GitLab is basically a commercial forge (gitlab.com) based on open-source forge software that can be installed on iipremise. GitLab Inc.’s financial model is based on selling licences for additional features to be used by online-service users or self-hosted forge administrators. In reality, installing a self-hosted forge for internal collaborative development requires few human or material resources, and offers a wide range of solutions. However, as soon as developers want take this collaborative development externally, integrate solutions to industrialise software development and implement good development practice, more substantial efforts are needed, and the choice of solution may be led by different criteria such as the platform’s popularity, its functionalities and how robust it is. In Higher Education and Research, developers of supporting software and software based on research work can choose between a number of forges to host their software. The simplest solution is when their institution has its own forge, particularly if no interaction is needed outside the institution. When wider interaction is required, communities developing research software often look to online commercial forges. This is reflected by the winners of the first french open science open-source research software award laureates, with 9 projects being hosted on GitHub and one project on SourceForge. The social network effect of “people go where most people are” and the international scope of the projects were the reasons for their selection. However, it really should be noted that commercial forges can suddenly disappear, as was the case with the Google forge, Google Code, which ceased operation after nine years presence in just a matter of months. The same thing happened with the Gitorious hosting solution. In addition, these forges have terms and conditions of use which each member must agree to as an individual, rather than on behalf of their institution. Self-hosted forges are one way of mitigating this kind of problem. However, it may be the case that the solution selected is no longer being maintained, or no longer developed under an open-source licence. This is what happened with the SourceForge code, and it was maintained in a community version under the name “GForge”, which has itself changed licences to enable it to be maintained in a community version under the name “FusionForge”, to now end up now with an unmaintained software (the latest version of the software dates back to 2018). Therefore, decisions around self-hosting and which forge to use are important. Of the 40 forges listed,38 are GitLab platforms (the other two forges use Tuleap and Gogs respectively). GitLab’s domination can be explained by how easy it is to install and maintain, and the wide range of functionalities which are available. Hence the interest in having a specific Higher Education and Research forge operating at any level (institutional, national, European or international). InHigher Education and Research Forges in France iiistitutional forges are the answer when software is being developed internally within an institution and an institutional forge already exists. In this case, the functionalities available and access to data are managed, but they offer little or no scope for development between multiple institutions. Where an institutional forge does not already exist or does not allow project owners to invite contributions from outside the institution, a national or European forge would provide an alternative to using commercial forges. Throughout the mid-2000s, a french national forge, SourceSup, was set up by RENATER (which manage the national electronic communications network for technology, education and research) in order to get around these restrictions on interaction. However, this forge, which was a state-of-the-art platform when it was created, now only offers a set of tools that have fallen behind current development standards. This report provides a comprehensive picture of the existing forges and practices in Higher Education and Research in France, and posits a number of observations and points of concern as regards the current situation.

This document summarizes the evolution of scientific publication models towards providing open access to research results and makes recommendations from an academic standpoint on future action paths. This document has been endorsed by the National Informatics Associations that are members of Informatics Europe at the time of publishing it.

Software Heritage is the largest public archive of software source code and associated development history, as captured by modern version control systems. As of July 2023, it has archived more than 16 billion unique source code files coming from more than 250 million collaborative development projects. In this chapter, we describe the Software Heritage ecosystem, focusing on research and open science use cases.