dataesr/scientific-paragraphs-categorization huggingface dataset:
The Edos and Mancoosi Research Projects Edos and Mancoosi  [1]  are two research projects funded by the European Commission, that run respectively from 2004 to 2007 and from 2008 to 2011. They focused on the new research problems posed by the maintenance of free software distributions, and brought together industries and top research laboratories from over 10 countries. Besides publishing research articles, these projects produced several tools that significantly improved the state of the art, and that are now part of the Dose3 library, which has outlived the research projects and became over time a collection of all the algorithms and tools developed over more than a decade. Unlike what seems to often happen in these research areas  [19] , most of the tools that were developed have now been adopted, in particular in the Debian distribution, even if with varying degrees of delay and effort.
Distcheck and Buildcheck The distcheck tool is a command line tool, capable of verifying the installability of all (or a selection of) components contained in a given repository. Internally, distcheck is designed as a pipeline, as shown in Fig. 2. The front-end on the left is a multiplexer parser that supports several formats for component metadata (Debian Packages files, RPM's synthesis or hdlist files, Eclipse OSGI metadata, etc. ). After metadata parsing, component inter-relationships are converted in a data representation called CUDF (Common Upgradability Description Format), an extensible format, with rigorous semantics  [22] , designed to describe installability scenarios coming from diverse environments without making assumptions on specific component models, version schemas, or dependency formalisms.
For instance, checking installability of all packages of the Debian main repository of the unstable suite (for 53696 packages 2 ) takes just 30 s on a commodity 64 bit CPU laptop. The final component of the pipeline takes the result from the solver and presents it in a variety of human and machine readable formats to the final user. An important feature of distcheck is its ability, in case a package is found not installable, to produce a concise human-readable explanation that points to the reasons of the issue in a machine-readable format. The buildcheck tool follows the same pipeline philosophy of distcheck but it is aimed at source packages. It takes a list of source and binary packages and checks if the build dependencies of each source package can be satisfied with the given binary list.
From their first release into the Debian repository, packages evolve over time following a well defined process. When a new version of a source package S is available, it is fist introduced in unstable (the only point of entry into the distribution), where the corresponding binary packages are gradually built. When a binary package is rebuilt, it replaces the previous version (if any), and when all binary packages associated to S are rebuilt, the old version of S is dropped. Building binary packages can be a long process because of compilation errors and broken dependencies. Moreover, because of the iterative nature of this process, it is sometimes possible to find in unstable several versions of the same source package, and a mixture of binary packages coming from these different versions of the same source.
Buildd, sbuildd, Dose-Tools The Debian autobuilder network is a management system that allows Debian developers to easily add new source packages to the repository and compile all associated binary package for all architectures currently supported by Debian. This network is made up of several machines and uses a specific software package called buildd whose main function is to automatically build all binary packages, according to its metadata and multi-architecture annotations. The build daemon, consists of a set of scripts (written in Perl and Python) that have evolved to help porters with various tasks. Over time, these scripts have become an integrated system that is able to keep Debian distributions up-to-date nearly automatically. The build infrastructure is composed of three main components, first wanna-build is a tool to collect and keep track of all package metadata.
The buildd is the multiplexer that selects which builder for each architecture must be invoked for each package, and finally sbuild is the actual builder to automatically recompile the package. buildcheck and distcheck are integrated in different components of the Debian build daemon. buildcheck is used in the wanna-build daemon to check if a all the build dependencies of a given source package are available. This step allows one to catch dependency problems before even allowing the package to enter the build queue, hence saving considerable resources and space. buildcheck is fed with the metadata of the current source package, and the metadata of all available packages in the archive at one moment in time. By using different options, buildcheck is able to check, for each architecture, if the all dependencies are available and if this is not the case, to provide a human readable explanation for the package maintainer.
This tool is also available to the package maintainer and it can be run independently on a personal machine. distcheck is used in sbuildd to provide better explanations to the package maintainer in case of failure. Depending on the solver (by default aspcud  [11] ), the dose3 explainer might report a dependency situation as satisfiable even if the apt-get found it to be unsatisfiable. This is a consequence of the fact that the default Debian resolver (apt-get) employs an algorithm that is, albeit very fast, incomplete. Having a sound and complete dependency solver for Debian helped developers in many occasions. The same solver is also available to the final user via apt-get, where the user can choose to select an external solver while installing a binary package on their machine. Before the introduction of distcheck packages where tested for broken dependencies using apt, that because of its nature, it was less adapted to this task.
Botch Botch is a set of tools designed to help porters to refine and complete this selection in a semi-automatic way and to build the rest of the distribution on top of it  [5]. Botch is based on the Dose3 library and re-uses many of its components. The main contribution of botch is the ability of providing a compilation order of source packages to gradually rebuild the entire archive. The goal is to break compilation loops by pruning build dependencies according to special metadata describing compilation stages. At each iteration/stage, new binary packages are added to the repository that in turn will allow new source packages to be build. The development of botch started with an academic collaboration with Johannes Schauer, a student that participated in a Google Summer of Code co-organised with Debian in 2012  [23].
Slowly, from prototype and thanks for the personal investment of the main developer of botch, it evolved from an academic project into an industry-strength tool. Adoption. Before botch, porting Debian to a new architecture was a long manual process based on the and personal experience. Because of the complex dependency network and inherent recursive nature of the problem (in order to compile a package we need to compile first all the source packages that will generate its build dependencies), it was also particularly error prone. Hence it came as no surprise to see that it was adopted pretty swiftly: it was not just a matter of improving quality of a distribution, but of saving weeks of hard work. Botch is now referenced in the Debian official page on bootstrapping https://wiki. debian. org/DebianBootstrap and is used regularly.
The Communication Gap While approaching the Debian community, we faced issues that were sometimes technical in nature, sometimes political, and sometimes even personal. Moreover, after realizing the communication gap between our academic approach and the FOSS communities, we had to learn to speak a new language, and engage the community on their own ground. Researchers often focus exclusively on the effectiveness and correctness on their approach, while forgetting the cost in terms of integration time and learning curve. The FOSS community is large and diverse. And while everybody has some technical knowledge, adopting a lingo that is too complex to understand can be counter productive. Hackers are more concerned about the results than the mathematics behind a tool, they are concerned about the ease of use, more than the expressive power of a new language.
Providing something the community can readily understand, use and modify, in terms of programming language used, development tools, following de-facto standards, can greatly speed up the time of adoption of a new solution. In our experience, bridging the academia-community gap has been possible only by actively engaging with the community. This involved, on one side, a significant effort to participate in online forums and live conferences: during the years covered in this article, we presented our work in a major European Developer conference (FOSDEM), and invited lead developers to work with us. We greatly benefit from having few members of our research team personally involved in the Community. While this is not always possible and largely dependent on the personal motivation of each team member, having deep ties within Debian helped us greatly to gain trust and respect.
Acknowledgements. The work described in this article has been performed over a very long span of time, in collaboration with many researchers, that contributed in different periods, and to varying degrees, to some or all of the tools that we mention. Roberto Di Cosmo ,  Fabio Mancinelli ,  Ralf Treinen  and  Jerôme Vouillon  were actively involved in the EDOS project, with  Fabio Mancinelli  leaving after that period. In the  MANCOOSI  project, that was set up and coordinated by  Roberto Di Cosmo ,  Ralf Treinen Jerôme Vouillon  were joined by  Pietro Abate ,  Jaap Boender  and  Stefano Zacchiroli.
To address those challenges, we designed ORBITS (ORchestration for Beyond InTercloud Security), an overlay intercloud architecture providing simultaneously flexible application provisioning across multiple providers with a homogeneous service abstraction across multiple clouds enforced at the IaaS level  [10]. ORBITS conciliates:  (1)  flexible provisioning requirements of microservice-based applications, handling placement, elasticity and availability; and (2) infrastructure homogeneity over generic CSPs through the Infrastructure as Code (IaC) paradigm  [11]. IaC enables to develop and manage infrastructure configurations, notably for cloud infrastructures, automating resource provisioning in addition to software deployment. However IaC-based deployment and management of a generic IaaS multi-cloud requires to overcome a number of roadblocks.
C. The TOSCA Manipulation Language (TML) TML scripts enable to modify a TOSCA graph, composed by the resources specified in the node templates fields. This graph is formed of a set V of vertices, capturing the set of resources with their attributes (e. g. , properties, interfaces with annex artifacts), and of a set E of edges, capturing the set of requirements for interconnection. The structure of a TML script is the following: • Filters They enable to navigate within the graph, and to specify "anchor" resources (i. e. , point-cut) from which rules in the advice will be triggered. A filter is composed of a name, a root field which identifies the type of resource to be used as anchor, and a rule which defines the condition to be verified to select the node when exploring the graph. The operators used to build a rule are is presented in table ??.
It defines an iterator (R) (line 12) to specify the set of new resources and to complete the other resource parameters (net name). For every matching resource, it will create and connect a new floating IP resource, through the "floatable" capability defined in the type definition of orbits. nodes. network. Port. Weaving the TML script to the template shown in Section III-A (listing 1) yields the result shown in figure  4. When run, the TML advice will create and connect a new floating IP resource for the unique port connected to the Internet, control port. It is worth noticing that the TML aspect is completely decorrelated from the base template, and may be applied to any TOSCA ServiceTemplate. Moreover, if the ServiceTemplate has more than one port connected to an external network, multiple resources will be injected without requiring more generated code.
IV. IMPLEMENTATION We now present a prototype of the MANTUS multi-cloud builder, focusing on the TML weaver component. A MANTUS implementation workflow includes the following phases, also used for weaver benchmarking: • Matching A ServiceTemplate is created, composed of concrete nodes starting from an abstract specification. We adopted the standard TOSCA plug-in matching developed by Brogi et al. [19]. • Fusion The matched file is generated, reconnecting different branches of matching. • Weaving Non-functional services are injected by applying TML scripts against the TOSCA ServiceTemplate as described in the previous section. • Translation Finally, the resulting TOSCA templates are translated to the Heat Orchestration Language (HOT) to be deployed on an OpenStack CSP on an OpenStack CSP as a target example of CSP.
In addition, complexity may also be captured by increasing the number of rules in the filters and checks sections (Filter-Rules curve, F * A). The benchmarks were performed with T = 1, S = 1. Each curve is characterized by a different configuration of S w. r. t. R, E, F , we obtain crafting ad hoc TML scripts. As shown in figure  5 -a, weaving time increases but remains linear with the amount of actions and resources injected, which gives a good indication of scalability avoiding combinatorial explosion. Those results indicates that look-up operations in graph scales well and and should encourage TML scripts developers to add extra-rules condition (e. g. ; to verify semantic properties after the weaving process). B. Dynamicity 1) Incremental Weaving Efficiency: In figure  5 -b, we analyze the weaving marginal cost, also showing standard deviation of samples.
Starting from a base template (T = 1), we performed incremental weaving (W i), iteratively adding one additional TML script to a growing template T i = W (T i-1 , S) with T 0 = T ; A = 1; R = 3; E = 3; S = 1. This benchmark suggests that the possibility weaving incrementally new scripts may be affordable even with bigger "previouslyweaved" templates, enabling the possibility to weave new resources as reaction to specific events (e. g. ; intrusion detection) validating the "dynamicity" property of DR1.
C. Performance 1) Relative Overhead of Weaving in Workflow: We first studied the impact of the weaving phase in the overall MAN-TUS workflow, to validate the performance of AOP-weaved approach. We performed a full deployment workflow, weaving 10 independent TML scripts of size (A = 1, E = 3, R = 3, S = 10), for an increasing number of starting OverCloud nodes(T → [0 -100]). The TML script simply injects one resource per compute node, with conditions which are always verified and therefore each per-script iteration weaved. Results are shown in figure  5c  (log scale): for all phases, the execution time is linear (logarithmic in log scale) w. r. t. the graph size, the weaving phase overhead being less than that of matching. Therefore, we can consider that the weaving operation remains acceptable even with bigger templates.
2) Weaver Efficiency vs. Aspect Complexity: In figure  5-d , to identify a valuable strategy to conceive and develop TML scripts, we compared weaving overheads of multiple weaving ((W (T, S * A) with S[R; E; F ]) injecting a single resource and of a single script injecting multiple resources((W (T, A) with S[R * A, A * E, F ]), according to the number of resources. Due to the cost of YAML parsing and graph reconstruction, the single-script approach show more efficiency compared to using multiple scripts. This trend may lead to an interesting direction for further work, somehow also overlapping the conflict detection issue discussed in section III-C: detecting and avoiding conflicts between TML scripts opens the door to weaving performance optimizations, resulting in script size increase, but reducing the number to be weaved.
VI. RELATED WORK An increasingly popular way to deploy infrastructure in traditional mono-cloud settings is to rely on Infrastructureas-Code (IaC) paradigms. For instance, in the context of the OpenStack project, several approaches use IaC to simplify the life-cycle management of a cloud infrastructure. Library-based (e. g. ; jclouds,libcloud) approaches provide the best flexibility, supporting many different provider APIs. Libraries are useful to express resource-oriented workloads requirements, communicating with different APIs with a driver mechanism. However, they fail to provide a global transparent vision of the multi-cloud, and do not allow to easily control resources (e. g. , networking )  [1]. Extending and simplifying TOSCA templates writing, Elastic-TOSCA  [23]  introduces support for dynamic scaling for TOSCA templates.
VII. CONCLUSION AND FUTURE WORK In this paper, we presented MANTUS, an aspectoriented multi-cloud builder, designed to generate an overlay infrastructure-oriented multi-cloud. MANTUS flexibly weaves non-functional services, translating the outcome to a providerspecific language. At a cost of an acceptable overhead, aspectoriented weaving separates cross-cutting concerns, fostering reuse of extra code and infrastructure life-cycle automation. We validated the suitability of aspect-oriented approach for non-functional service injection evaluating scalability, dynamicity and performance. Future work will be oriented in three main directions. First, we will explore idempotence and conflicts when weaving multiple scripts. This axe of work is particularly interesting due to the result of 5-d, where the weaver showed better performance with few huge scripts compared to a multitude of tiny scripts.
The LHC@Home BOINC project has provided computing capacity for numerical simulations to researchers at CERN since 2004, and has since 2011 been expanded with a wider range of applications. The traditional CERN accelerator physics simulation code SixTrack enjoys continuing volunteers support, and thanks to virtualisation a number of applications from the LHC experiment collaborations and particle theory groups have joined the consolidated LHC@Home BOINC project. This paper addresses the challenges related to traditional and virtualized applications in the BOINC environment, and how volunteer computing has been integrated into the overall computing strategy of the laboratory through the consolidated LHC@Home service. Thanks to the computing power provided by volunteers joining LHC@Home, numerous accelerator beam physics studies have been carried out, yielding an improved understanding of charged particle dynamics in the CERN Large Hadron Collider (LHC) and its future upgrades.
Virtualisation with BOINC Thanks to developments started at CERN, and later brought into the BOINC distribution, such Linux programs can now run on a Virtual Machine (VM) distributed to the volunteer computers via BOINC and running on volunteer PCs within the Oracle VirtualBox hypervisor. This use of virtualisation under BOINC was pioneered by the Test4Theory LHC@Home project during 2008-2011  [7] [8] [9] 11]. This development has allowed the LHC experiment collaborations to run their simulations also under BOINC, in the CernVM virtual machine  [24]. The CernVM project provides virtual images tailored for the LHC experiments' software and these images can run seamlessly inside the virtualisation layer provided by BOINC. CernVM is a compact Linux virtual machine based on Scienti c Linux 6 combined with a kernel adapted for virtualisation.
CernVM does not include a physical disk, and the current Micro-CernVM only contains core libraries, compilers and handlers for an http le system  [25]. In this way, the core image size is of only ∼20MB, and hence suitable to download for volunteer computing applications. Application-speci c software is downloaded via a networked http le system, CernVMFs. Several experimental groups have been running pilot BOINC projects for their collaborators to contribute simulations via BOINC and virtualisation. Following the experience with Test4Theory, ATLAS@Home and other pilot projects, with a view to include volunteer computing into the production computing infrastructure for HEP  [12] , a major e ort has been undertaken to consolidate the original LHC@Home and host additional applications utilising virtualisation.
The accounts and BOINC credit of volunteers who had been contributing to the pilot projects Test4Theory/vLHC@home and ATLAS@Home were migrated to the consolidated LHC@Home project by means of a set of SQL scripts, as all the information is stored in the database. The volunteer's email address was used as unique key for the data, as the user ID di ers in each project depending on when the volunteer joined the BOINC project. On the consolidated LHC@Home, users have a choice of applications that is enabled via LHC@Home project preferences. The SixTrack application, which does not require VirtualBox, is enabled by default for volunteers. Once registered, volunteers can enable e. g. ATLAS, CMS or Theory simulations via the LHC@Home project preferences. In terms of computing power provided by the volunteers to LHC@home, the average is about × simulation tasks.
The SixTrack code is mainly Fortran-based, vectorized to take advantage of vector instructions, pipelining, and hardware features such as SSE and AVX. It was ported for use with BOINC to Windows, MacOSX and Linux by incorporating calls to the BOINC application programming interface (API) library and re-compiling and re-linking the source code to produce executables for each client platform. Since 2004, the application code has undergone sev-eral updates to adapt to new BOINC versions as well as to improvements to SixTrack itself (see  [13]  for a recent account on the code state). The principal functional changes for consistent and reliable operation are outlined in  [14] , but subsequent improvements now allow the use of several Fortran compilers, at any Fortran standard compliant level of optimisation, providing identical results, i.
e. 0 Units di erence in the Last Place (ULPs), on any IEEE 754 compliant hardware (E. McIntosh, in preparation). In order to achieve this, Fortran expressions, which could be evaluated in a di erent order as allowed by the standard, were parenthesised (H. Renshall, personal communication). SixTrack can be built in many di erent con gurations, e. g. for dynamic aperture (see Sections 4. 1 and 4. 3) or collimation studies, and with or without support for checkpoint/restarting, compressed input/output, correct and consistent rounding of mathematical functions  [15] , BOINC, and more. Furthermore, it can run natively on most major platforms (Linux, MacOSX, Windows including XP, FreeBSD, NetBSD, OpenBSD, and GNU Hurd on x86 and x86_64, as well as Linux on armv6, armv7, 64bit armv8 (including Android systems), and PPC64, as long as a UNIX-like build environment is available; on Windows this is provided by MSYS2  [16].